タイトル | : Re^3: Win32APIのFTPクライアントについて |
記事No | : 13451 |
投稿日 | : 2009/02/20(Fri) 12:13 |
投稿者 | : 魔界の仮面弁士 |
> FtpFindFirstFileで呼び出して API の宣言部分と、呼び出し部分を見せてもらえますか?
> サーバーにああ.txtがあります。 > FtpFindFirstFileで呼び出して、縺ゅ≠.txtになりました。 「ああ.txt」を、UTF-8 でエンコードすると、 E38182 E38182 2E 74 78 74 になります。
「縺ゅ≠.txt」を、Shift_JIS でエンコードしたものも、 E381 82E3 8182 2E 74 78 74 という同じバイナリになります。
つまり UTF-8 テキストが、Shift_JIS としてデコードされている状態ですね。
> 何が使って、変換できませんか。 事後変換は避けましょう。 化けたデータを元に戻すのではなく、化けずに受け取る事を考えるべきです。
ADODB.Stream 等を使えば、「縺ゅ≠.txt」→「ああ.txt」への変換は可能ですが、 それは運が良かっただけです。今回は、データの損失がありませんでしたが、 他の文字列では変換できる保証はありません。
たとえば、元ファイルが「β版.txt」だとしたら、UTF-8 エンコードでは UTF-8: CEB2 E78988 2E 74 78 74 になりますが、これを Shift_JIS でデコードする事はできません。
無理にデコードすると、 Shift_JIS: CE B2 E789 88?? 2E 74 78 74 という状態になり、4文字目以降が破損します。 おそらく、"ホイ迚・txt" のように見える事でしょう。(先頭2文字は半角カナ)
これは、Shift_JIS では 88 が「2バイト文字の先導バイト」と定義されていますが、 その後には「40〜7E, 80〜FC」しか来てはならない事になっているためです。
88?? 2E の部分が、"?." となるのか、"・"になるのか、"" に潰れるのかは 処理系依存ですが、何にせよ、データ損失がある場合、逆変換は不可能です。
ただし、結果を String "ホイ迚・txt" で受け取るのではなく、 バイト配列 {CE B2 E7 89 88 2E 74 78 74} として、過不足無く受け取れるなら、 UTF-8 文字列へ復元することも可能です。ただしそれが、FtpFindFirstFile で できるかどうかは、やってみなければ分かりませんけれども。
|