Winsock2 を使った CF2.5 のエクステを作ってウェブサーバとソケット接続を試みていたが、ようやく文字化けせずにサーバから日本語文字列の受信に一応成功した。
なぜ Get Object は文字化けするのか
Get Object はユニコードに対応したということだが、日本語を含めた文字列の受信はこれまで一切できなかった。
自分で実際にまずコンソールアプリとして作ってみて分かったことは、ウェブ上のドキュメントがたとえば UTF-8 で書かれていたとして、それをウィンドウズで受信した場合、ウィンドウズはシステムのロケール設定に従って「 Shift-Jis 」で文字列を表示しようとする。つまり UTF-8 が Shift-Jis で表示されるからエンコード不一致で文字が化ける。
Shift-Jis は 1 バイト で表現される英数字部分と 2 バイト で表現される日本語文字部分で成り立っているマルチバイト文字列扱いだから、UTF-8 で受信したデータをその後、システムのロケールに従った形へ適切に変換すれば良い。この場合システムのロケールは日本だと Shift-Jis であるって具合だ。ここまではコンソールアプリとして作る場合のお話になる。
エクステとして作る場合、CF2.5 が間に挟まれているのでここでちょっとややこしくなる。CF2.5 はユニコード対応してるからマルチバイト文字列を受信したらそれをワイド文字列化して CF25 へ送信すれば良い。
面倒だが一度変換処理を挟む必要性
Char で受信してるデータならワイド文字列への変換処置を適切に行えば日本語表示で文字化けしなくなる。
現行の Get Object では ANSI で受信することだけを想定していてそれをワイド文字列へ変換してるのかもしれない。
エンコードの判定が必要ならそれ用の処理を複数用意すれば全対応できると思う。
UTF-8(Char) ＞ ワイド文字列
Shift-Jis(Char) ＞ ワイド文字列
Euc-Jp(Char) ＞ ワイド文字列
ANSI(Char) > ワイド文字列
こんな具合かな…
ただし汎用的なエクステとして公開する場合はこういった対応が必要だが、あくまでも自分専用ということにするなら文字エンコードは対応の幅が少なくていい。つまり UTF-8 の文字列を受け取りたいから UTF-8(Char) ＞ ワイド文字列 のアルゴリズムだけを実装する。