ホームページ  >  記事  >  バックエンド開発  >  【XML】UTF8、GB2312エンコード変換における文字化けの解決方法

【XML】UTF8、GB2312エンコード変換における文字化けの解決方法

Y2J
Y2Jオリジナル
2017-04-22 13:53:092498ブラウズ

監査情報は XML タイプのファイルとして生成する必要があり、XML は GB2312 でエンコードする必要があります。これは、収集されたニュース Web サイトの多くが UTF8 エンコードを使用しているため、変換プロセス中に文字化けが発生するためです

最近、小さなプロジェクトを作成しました。このような問題が発生した場合は、要約として記録してください。
このプロジェクトは 2 つの部分に分かれており、1 つはニュース データの収集、もう 1 つは収集された情報のレビュー、そして最後に XML ファイルの生成です。
収集されたデータがユーザーによって編集された後、ACCESS ファイルをエクスポートして、情報レビュー システムにインポートする必要があります。 ACCESS ライブラリにニュース情報を格納するフィールド タイプは ntext タイプですが、監査システム ライブラリの対応するフィールドは varchar (max) タイプ フィールドです。インポート後、一部の空白文字が文字化けして質問として表示されることが判明しました。実際、その後のテストの結果、これは空白 (スペース) 文字ではなく、特殊文字であることがわかりました。いくつかのテストの結果、インポートされたデータにこのような問題が発生しないようにするには、varchar(max) タイプを nvarchar(max) タイプに変更する必要があることがわかりました。
しかし、その後のテストの過程で、インポートした収集情報を(.netプログラム編集機能を通じて)変更した後、調査の結果、このように記述するとデータベース内の情報が再び文字化けすることが判明しました。挿入ステートメントでは機能しません。テーブル名 (ニュース) に値 (N'"+更新値 +"") を挿入するなどの問題が発生します。なぜ N を追加するのでしょうか。Baidu にアクセスすると理解できます。この点で、ようやく安心しましたが、次の問題が人々を憂鬱にさせています...
収集されたニュース Web サイトの多くは UTF8 エンコーディングを使用しているため、レビューされた情報は XML 形式で生成され、XML は GB2312 でエンコードされている必要があります。変換プロセス中に文字化けが再び発生する(やはり「空白」特殊文字が原因)場合、インターネット上では UTF8 を GB2312 に変換することが推奨されていますが、実際にはまだ問題が発生していることがわかります。が解決できないので、この問題を解決するために、午前中はまだ方法がありませんでした。ついに、VS のデバッグ機能を使用して、この特殊な文字が何であるかを確認することを思いつきました。 、データベース内のこのフィールドの値を読み取り、文字配列に変換した後、content.ToCharArray(); でそれを 1 つずつ調べて、コード化けの原因となった文字が ' ' であることを発見しました。引用符内のスペース これはスペースではなく、GB2312 では認識できない特殊文字です。このとき、突然、この文字の値をスペースに置き換えることができるのではないかと思いました。 、文字化けの問題が解決されたので、この愚かな作業に半日を費やしてしまいました
注意、これは文字化けを引き起こす実際の特殊文字であるため、それを使用する必要があります。デバッグ時のフォーム内:

コードは次のとおりです:

content = content.Replace(" ", " ");

以上が【XML】UTF8、GB2312エンコード変換における文字化けの解決方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。