UTF8からGB2312への乱雑なコード問題の解決策

最近、小さなプロジェクトをやっていて、このような問題に遭遇したので、まとめとして記録しておきたいと思います。
このプロジェクトは2つのパートに分かれており、1つはニュースのデータ収集、もう1つは収集した情報の監査、そして最後にXMLファイルを生成することです。
ユーザーがデータを収集・編集した後、ACCESSファイルをエクスポートし、このファイルを情報監査システムにインポートすることになっています。ACCESSライブラリのニュース情報を格納するフィールドタイプはntext型、監査システムライブラリの対応するフィールドはvarchar(max)型であるが、インポート後、一部の空白文字がクエスチョンマーク(?)として現れ、文字化けすることが判明した。実際には、テストの後、それは空白（スペース）文字ではなく、特殊文字である、どのように行うには？何度かテストした結果、varchar(max)型をnvarchar(max)型に変更すれば、インポートしたデータにそのような問題が発生しなくなることがわかりました。
しかし、後でテストプロセスでは、我々は、インポートされたコレクションの情報が（.netプログラムの編集機能を介して）変更された後、データベース内のこの情報は再び問題が文字化け表示されることがわかります、研究この方法で書かれた挿入文で見つかった後にそのような問題は、テーブル名（ニュース）値（N '＆quotに挿入などを持っていない、+更新値+ " あなたはBaiduに行くとあなたが理解できる、なぜN .を持って追加で見ることができます。
ここでようやく心が休まるのだが、その後に続く疑問でまた憂鬱になってしまうのだ。
と落ち込んでいたところ、ふと思いついてVSのデバッグ機能を使って、この特殊文字が何なのかを確認しました。ToCharArray();を一つずつ実行していくと、文字化けの原因となっている文字が ' '引用符の中の空白に注意、これはスペースではなく、GB2312では認識できない特殊な文字であることがわかったのです。すぐに対応したところ、案の定、コードが乱れる問題は解決した。このキモいことで1日半を無駄にした、と本当に落ち込みました。
なお、この値はデバッグ時から使用し（これが本当に文字化けの原因となる特殊文字なので）、デバッグ時には偶数フォームに貼り付ける必要があります。