[ツリー表示へ] [ワード検索] [Home]
タイトル ： Re^3: Win32APIのFTPクライアントについて 投稿日 ： 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 で できるかどうかは、やってみなければ分かりませんけれども。 |
をクリックするとツリー全体を一括表示します） - Win32APIのFTPクライアントについて - 王鵬 09/02/20-10:39No.13448