[ツリー表示へ] [ワード検索] [Home]
タイトル ： Re^3: 文字コードを変換 投稿日 ： 2008/05/03(Sat) 14:18 投稿者 ： 魔界の仮面弁士
| > 実はよくわからないんです。 それは、調べ方が分からないという意味でしょうか? それとも、調べていないから分からないという意味でしょうか? 状況を十分に理解しないままコーディングしていくと、化けたデータをさらに化けさせ、 取り返しがつかない状態にまで破損させてしまう事もありえますよ。 > RSSを読み込むソフトを作っていて、RSSのXMLを書き出すのは RSS であれば尚のこと、System.Xml を使うべきかと思いますよ。 > 自分ではなく、別のソフトなので、どのエンコードで > 書き出しているのかすらわからないのです。 事前に分からずとも、取得した時点では分かりますよね。 XML では、文字化けが発生せぬよう、明確な規則を持っているのですから。 http://www.atmarkit.co.jp/fxml/rensai/xmlwomanabou06/learning-xml06.html XmlDocument.Load では、その規則を元に、正しい文字コードが判定され、 正しい文字列へとデコードされますので、ご自身で把握しておらずとも、 データを正確に読み込ませることができます。 > 外部（インターネットからダウンロードしたソースファイル）を使って > XMLを読み込んでいます。なので、XmlDocumentクラスは使えません。 なぜ、XmlDocument クラスを使えないのでしょうか? URL を指定して読み込むことも、XML データを文字列として読み込むことも、 ダウンロードしたファイルを指定することもできますけれども…。 > > > 文字化けしてしまいます。 > > どの文字が、どのように化けてしまうのでしょうか? > (中略) > こんな感じです。 えぇと、私が「どのように化けたか」を聞いたのではなく、 「どの文字が、どのように化けたか」を聞いていた事に注意してください。 String 自体には、文字コード情報は含まれていないので、どのような経路で 化けてしまったのかを知るために、変換前後の両方のデータをお聞きした次第です。 > では、どのようにすれば文字コードを変換できるのでしょうか。 そもそも文字コード変換というのは、文字化けしたデータを復元するために あるのではありません。一度化けた物は、その時点でデータの一部が損傷している 可能性が高いため、元の正しいデータに戻せる保証はありません。 まずは、処理手順を見直してみてください。元となるデータが、文字化けしている 破損状態の String しか無いのであれば、文字コード変換の余地は ほとんど残されていないものと思ってください。 本当に読み込ませるべきは、ダウンロードした生の XML ファイルそのもの、 すなわち、ファイルのパスや Byte() あるいは Stream といったデータであるべきです。 たとえば「あ」という文字の場合、そのバイナリは、それぞれ Shift_JIS なら、82 A0 euc-jp なら、A4 A2 UTF-16 なら、42 30 など UTF-8 なら、E3 81 82 となりますよね。 E3,81,82 というバイナリを、UTF-8 でデコードすると、「あ」になりますが、 E3,81,82 というバイナリを、Shift_JIS でデコードすると「縺?」になります。 このとき、Shift_JIS にとっての E3,81 というバイナリは「縺」に一致しますが、 Shift_JIS にとっての 82 は、全角文字の 1 バイト目というデータを意味し、 それ単独では文字となりえません。そのため、2 文字目は破損状態となります。 そして『UTF-8 → Shift_JIS への文字コード変換』を行うというのは、 「縺?」という String を、「あ」という String に変換する事ではなく(それは不可能)、 E3,81,82 というバイナリを、82,A0 というバイナリにする作業を意味する事に注意してください。 そしてこのような変換作業には、Encoding.Convert メソッドを利用できます。 |
をクリックするとツリー全体を一括表示します） - 文字コードを変換 - ゆうき 08/05/02-19:14No.7439