08-07-2013, 11:39 AM
QAとは異なりますが、開発者の参考になると思いますのでメモとして投稿します。
Curlは各種文字コードで開いた文字列をUnicodeで解釈しているようですが、
その解釈の仕方に齟齬があるようで、特定の文字列では内部的に文字が変わってしまうことがあります。
(※文字コードの対応付けに起因するので、Curl固有の問題と言うのは少し違います。)
例えば「\」(全角バックスラッシュ)を含むeuc-jpの文字列をread-openで開くと、
読み取った後の文字列は内部的に[\](半角¥マーク)に変換されています。
「\」がデータ内部に出てくるシステムというのはそうそう出てこないと思いますが、
システムのたびに都度このような事象を考慮するのは非常に面倒です。
余計な問題を避けるために、
読み込むストリームを全て「utf8」に統一する事が最善だと思いますが
サーバの状況によっては必ずしもそうできない場合がありますので
次善の回避策として、下記のような実装方法があります。(要特権)
1.TextInputStreamではなく、ByteInputStreamでファイルをローカルの一時フォルダに保存。
2.1のファイルをnkfなどの文字コード変換コマンドでUnicodeに変換。
3.変換済みのファイルをutf8の文字コードで開く。
この方法における最大の利点は、クライアント側で文字コードの判別を考える必要がないところです。
最近のWebサービスはutf8でほぼ統一されてきていますが、
古いWebサイトやWebサービスなどでは、
まだまだeuc-jpやshift-jisのサーバも多いですので
レガシーなサービスと連携する場合には有用かと思われます。
※nkfはLinuxのコマンドですが、Windows用にオープンソースライブラリが存在します。
Curlは各種文字コードで開いた文字列をUnicodeで解釈しているようですが、
その解釈の仕方に齟齬があるようで、特定の文字列では内部的に文字が変わってしまうことがあります。
(※文字コードの対応付けに起因するので、Curl固有の問題と言うのは少し違います。)
例えば「\」(全角バックスラッシュ)を含むeuc-jpの文字列をread-openで開くと、
読み取った後の文字列は内部的に[\](半角¥マーク)に変換されています。
「\」がデータ内部に出てくるシステムというのはそうそう出てこないと思いますが、
システムのたびに都度このような事象を考慮するのは非常に面倒です。
余計な問題を避けるために、
読み込むストリームを全て「utf8」に統一する事が最善だと思いますが
サーバの状況によっては必ずしもそうできない場合がありますので
次善の回避策として、下記のような実装方法があります。(要特権)
1.TextInputStreamではなく、ByteInputStreamでファイルをローカルの一時フォルダに保存。
2.1のファイルをnkfなどの文字コード変換コマンドでUnicodeに変換。
3.変換済みのファイルをutf8の文字コードで開く。
この方法における最大の利点は、クライアント側で文字コードの判別を考える必要がないところです。
最近のWebサービスはutf8でほぼ統一されてきていますが、
古いWebサイトやWebサービスなどでは、
まだまだeuc-jpやshift-jisのサーバも多いですので
レガシーなサービスと連携する場合には有用かと思われます。
※nkfはLinuxのコマンドですが、Windows用にオープンソースライブラリが存在します。