文字エンコーディングは、常にのpython 2.7から、永続的な問題となっていた、中国の様々な窓に文字化けして、ストレージを転送し、mysqlの中国語の文字を表示するために、すべてのプログラマは、これらのピットを通じてウェーディング必要があります。
今日では、要約として見なさ問題を、エンコード良い話文字。要約簡潔かつ長期ったらしいため、明確ではありません。
質問1：UTF-8、UTF-16、ユニコード、ASCIIはANSI、何ですか？
（stackoverflowの答えを添付して、詳細に説明し指示していない、この質問をたくさん尋ねられhttps://stackoverflow.com/questions/700187/unicode-utf-ascii-ansi-format-differences）、その後、私はそれを見直し
残念ながら、文書の多くは不正確Unicodeがデフォルトでその特定のシステムの使用をコードするいずれかを参照するためにそれを使用していますが、「Unicodeには」、エンコーディングではありません。WindowsとJavaの上で、これは多くの場合、UTF-16を意味します。他の多くの場所で、それはUTF-8を意味します。適切に、Unicodeはない、特定のエンコーディングに、抽象文字セット自体を指します。
Unicodeコードポイントと本質的に同様のそのような言葉に漢字、アルファベットの文字のような言語の最小の基本単位に論理的、各コードポイント相当にセット（コードポイント）です。これは、マッピングロジックです。コードポイント自体は、一連の数字である1,2,3 ....
UTF-16： "コード単位" ごとに2バイト。これは.NETで、一般的にWindowsとJavaで文字列のネイティブフォーマットです。基本多言語面（BMP）外の値はサロゲートペアとして符号化されます。これらは比較的まれに使用するために使用されるが、今多くのコンシューマアプリケーションはサポート絵文字ために非BMPの文字を認識する必要があります。
UTF-8：可変長符号化は、1-4コードポイントあたりのバイト数。ASCII値は、1つのバイトを使用してASCIIとしてエンコードされています。
UTF-7：通常のメールのエンコードに使用します。あなたは、あなたがそれを必要とし、あなたがしている間違って、メールをやっていないと思われる場合可能性があります。（これは、ニュースグループなどに掲示する人々のちょうど私の経験だ-外郵便、それは本当に広くすべてで使用していない。）
UTF-32：固定コードポイントごとに4つのバイトを使用してエンコードする幅。これは非常に効率的ではありませんが、BMP外の生活が容易になります。私は私のMiscUtilライブラリの一部として.NET Utf32Stringクラスを持っている、あなたはそれをしたいはずです。（それは非常に徹底的にテストされていない、あなたを気に。）
UTFシリーズは、ストレージのための本当の「コード」、すなわち、コードポイント（符号）に変換Unicodeで表される新しいバイナリコード、バイアスされた実際の物理的な表現です。例えば、UnicodeはU +のD55Cある対応さて、韓国語「한」、10進数の数値が152 534であるが、1,101,010,101,011,100バイナリを表し、これは論理です。次に応じのUTF-8でエンコードされたで、次いで、バイナリ11101101 1,001,010,110,011,100の物理的な表現となり、図の小数点これは355225バイナリ234,16 ED 95（c）にバイナリであり、これらの値は、コンピュータに格納されています実際の値は、符号化されています。
共通UTF-8/16が符号化される、UTF-8、UTF-16バイト1~4バイトの長さを有していてもよい2/4であり、2バイトの最も。
ASCII：下の7ビットを使用するだけでエンコードするシングルバイト。（Unicodeコードポイント0-127。）いいえアクセント等
ASCIIをコードする最も簡単な方法は、あまりないと言っています。
ANSIは：誰も固定ANSIエンコーディングありません - それらの多くがあります。人々は「ANSI」を言うとき通常、彼らはEncoding.Defaultを介して取得し、多くの場合、Windowsの-1252であるが、他のロケールすることができている「私のシステムのデフォルトロケール/コードページ」を意味します。
ANSIは、多くの場合、この引数を参照して、より多くのエンコーディングは、ローカルシステムを意味します。例えば、中国はGB2312です。
質問2：文字列とwstringのは何ですか？
stackoverflowの上にも非常に良い答え（https://stackoverflow.com/questions/402283/stdwstring-vs-stdstring）
、char_tを要約し、wchar_t型とUnicodeが良くなっに何も持っていないために、彼らは単にデータをの種類、char_t Linux上で通常のバイトのwchar_tの窓2バイトの4バイトです。
データのこれらの2つのタイプは、4バイト、すなわち、対応するUTF16 2~4バイトであってもよく、バイトであってもよい、char_tのUTF8用い、前述したように、より多くのUTF16のUTF8のために意図され1-2のwchar_t。
区別が重要である理由を、理論的には、それは、いくつかのwchar_tのchar_t組成物からなることができるが、wchar_t型を格納するのに使用される場合、1つの符号化UTF16などの重要な問題に対応するパケットは、ワード（グリフ）、これらの2つのバイトを表すことそれは2 UTF8に分かれている場合は、全体として、再度、おそらくさらに言葉をデコードします。
UTF8のUTF16とC ++ 11 codecvt方法で利用することができる変換。見つけることができますhttps://stackoverflow.com/questions/4804298/how-to-convert-wstring-into-string
質問3：中国は来る文字化けか？
まず外観は理由が文字化け、基本的に単語、他の符号化シンボルの作成方法を説明するために使用されるエラー符号化方式です。いわゆるトラブルがちょうどそう、それを終了する必要があります。
中国は多くの明確な中国のエンコーディングがあるか来る、文字化け、中国は、自分自身のGB2312基準のセットを開発してきた国際標準に組み込まれているが、Unicodeから、まだ異なります。GB12312自身の符号化は、互換性のないストレージを有しており、UTF-8 / UTF-16
GB2312の文字セットは、Unicode文字セットのサブセットです。GB2312で定義されたすべての文字もUnicodeで定義されていることをこれが意味。
しかし、GB2312コードとUnicodeのコードは完全に非関連しています。例えば、0xB0A1のコード値とGB2312文字0x554AのUnicodeコード値を有しています。同じ文字のUnicodeコードをGB2312コードを変換する数式はありません。
だから、UTF8エンコーディングのものは、GB2312の窓は、時間を表示するために使用されるコマンドラインコンソールをエンコードするとき、性質が文字化けします。
エンコードとどこでもプロセスをデコードする、それは、あらゆる面であることができ、コンソール（デコード）に出力することができ、それは、それがには何の対応は存在しませんであるとして、JSON文字列（デコード）、ライト・ファイル（エンコード）を解決することができます問題。
UTF-8とUTF-16は、Unicodeですが、そこchar_tがあるとwchar_t型は完全に11とUTF-バインドされていない、という追加、任意のバイトストリームがためchar_tまたはwchar_t型を表すために使用することができます。
UTFシリーズとの間の変換を行うGB2312でエンコードされたコンテンツについて、あなたは維持するためにchar_tを使用することができ、あなたにも存在するwchar_t型を使用することができますが、これに基づいてすることはあなたの権利です。