今日は、JavaScript スクリプトを使用して ASP.NET ページにメニュー ツールを作成し、それを <script language="javascript" src="../js/MenuScript.js"></script として保存しました。ページ内 >Call を実行すると、ページ内の漢字は正常に表示されるが、メニュー内の漢字が文字化けして表示されるという奇妙な現象が動作中に発生しました。
考える必要はありませんが、ページの「表示」-「エンコーディング」オプションでエンコーディングに問題があることがわかります。その結果、中国語になります。ページ上の文字化けとメニュー内の漢字が交互に文字化けします。
解決策: 構成ファイルにはエンコード設定があります: <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
menuScript.js ファイルを保存するときにエンコード オプションがあります (このファイルを Word で開き、別のファイルとして保存し、エンコードを選択できます)。2 つのエンコードを同じにしておいてください。
コーディングの問題をよりよく理解するために、CSDN でこれに関する記事 (著者: fmddlmyy) を見つけました。参考のためにここに転載します:
コーディングについて話しましょう コーディングについて話しましょう #region コーディングについて話しましょう
/**//*
0.ビッグエンディアンとリトルエンディアン
ビッグ エンディアンとリトル エンディアンは、CPU がマルチバイト数値を処理する方法が異なります。たとえば、文字「汉」の Unicode エンコードは 6C49 です。では、ファイルに書き込むときは、6C を前に書くべきでしょうか、それとも 49 を前に書くべきなのでしょうか?先頭に6Cが書かれている場合はビッグエンディアンです。または、前に 49 を書きます (リトルエンディアン)。
「エンディアン」という言葉は「ガリバー旅行記」に由来しています。リリパットの内戦は、ビッグエンド（ビッグエンディアン）の卵を割るか、スモールエンド（リトルエンディアン）のどちらから卵を割るかに端を発し、その結果、6つの反乱が起こり、皇帝の1人が命を落とし、もう一人は王位を失いました。
一般にエンディアンを「バイトオーダー」と訳し、ビッグエンディアンとリトルエンディアンを「ビッグエンド」「リトルエンド」と呼びます。
1. 文字エンコーディングと内部コード ちなみに、中国語の文字エンコーディング文字は、コンピュータで処理する前にエンコードする必要があります。コンピュータで使用されるデフォルトのエンコード方式は、コンピュータの内部コードです。初期のコンピューターでは、中国語の文字を処理するために 7 ビット ASCII エンコーディングを使用し、簡体字中国語用には GB2312 を、繁体字中国語用には big5 を設計しました。
GB2312 (1980) には、6763 個の漢字と 682 個のその他の記号を含む、合計 7445 個の文字が含まれています。漢字領域の内部コード範囲は上位バイトが B0 ～ F7、下位バイトが A1 ～ FE で、占有コードビットは 72*94=6768 です。このうち空席はD7FA～D7FEの5名です。
GB2312 がサポートする中国語の文字が少なすぎます。 1995 年の漢字拡張仕様 GBK1.0 には 21,886 個の記号が含まれており、漢字領域と図形記号領域に分かれています。漢字エリアには 21003 文字が含まれます。 2000 年の GB18030 は、GBK1.0 に代わる公式の国家規格です。この標準には、27,484 の漢字のほか、チベット語、モンゴル語、ウイグル語、その他の主要な少数民族言語が含まれています。現在の PC プラットフォームは GB18030 をサポートする必要があり、組み込み製品に対する要件はありません。したがって、携帯電話と MP3 は通常、GB2312 のみをサポートします。
ASCII、GB2312、GBK から GB18030 まで、これらのエンコード方式には下位互換性があります。つまり、これらのスキームでは同じ文字は常に同じエンコード方式であり、後の標準ではさらに多くの文字がサポートされています。これらのエンコードでは、英語と中国語を均一に処理できます。中国語のエンコードを見分ける方法は、上位バイトの最上位ビットが 0 ではないことです。プログラマがこれらを何と呼ぶかによると、GB2312、GBK から GB18030 まではすべて 2 バイト文字セット (DBCS) に属します。
一部の中国製 Windows のデフォルトの内部コードは依然として GBK ですが、GB18030 アップグレード パッケージを通じて GB18030 にアップグレードできます。ただし、GB18030 で追加された文字は、GBK に比べて一般の人にとっては使いにくいものです。通常、中国語の Windows 内部コードを参照するために GBK を使用します。
詳細は次のとおりです。
GB2312 の原文は市外局番のままであり、市外局番から内局番までは上位バイトと下位バイトにそれぞれ A0 を付加する必要があります。
DBCS では、GB 内部コードの格納形式は常にビッグ エンディアン、つまり上位ビットが最初になります。
GB2312 の 2 バイトの最上位ビットは両方とも 1 です。ただし、この条件を満たすコード ポイントは 128*128=16384 個だけです。したがって、GBKおよびGB18030の下位バイトの最上位ビットは1ではない可能性があります。ただし、これは DBCS 文字ストリームの解析には影響しません。DBCS 文字ストリームを読み取るとき、上位ビットが 1 であるバイトが見つかった限り、次の 2 バイトは、下位バイトとは何か。
2. Unicode、UCS、UTF
前述したように、ASCII、GB2312、GBK から GB18030 までのエンコード方式には下位互換性があります。 Unicode は ASCII とのみ互換性があり (より正確には、ISO-8859-1 と互換性があります)、GB コードとは互換性がありません。たとえば、文字「汉」の Unicode エンコードは 6C49 ですが、GB コードは BABA です。
Unicode も文字エンコード方式ですが、国際機関によって設計されており、世界中のすべての言語のエンコード方式に対応できます。 Unicode の学名は「Universal Multiple-Octet Coded Character Set」、略して UCS です。 UCS は、「Unicode Character Set」の略称として見ることができます。
Wikipedia ( http://zh.wikipedia.org/wiki/ ) によると: 歴史的に、Unicode を独立して設計しようとした組織が 2 つあります。それは、国際標準化機構 (ISO) とソフトウェア製造業者協会 (unicode.組織）。 ISO は ISO 10646 プロジェクトを開発し、Unicode コンソーシアムは Unicode プロジェクトを開発しました。
1991 年頃、双方は世界が 2 つの互換性のない文字セットを必要としていないことを認識しました。そこで彼らは、双方の作業を統合し、協力して単一のコーディング リストを作成し始めました。 Unicode2.0 以降、Unicode プロジェクトでは ISO 10646-1 と同じフォントが使用されます。
どちらのプロジェクトもまだ存在しており、独自の標準を個別に発行しています。 Unicode コンソーシアムの最新バージョンは、2005 年の Unicode 4.1.0 です。最新の ISO 規格は 10646-3:2003 です。
UCS は、複数のバイトを使用してさまざまなテキストを表す方法を指定します。これらのエンコーディングを送信する方法は、UTF (UCS Transformation Format) 仕様によって規定されており、一般的な UTF 仕様には UTF-8、UTF-7、UTF-16 があります。
IETF の RFC2781 および RFC3629 は、RFC の一貫したスタイルで UTF-16 および UTF-8 のエンコード方式を明確、明瞭かつ厳密に記述しています。いつも忘れてしまうのですが、IETF は Internet Engineering Task Force の略称です。ただし、IETF によって維持されている RFC は、インターネット上のすべての仕様の基礎です。
3. UCS-2、UCS-4、BMP
UCS には、UCS-2 と UCS-4 の 2 つの形式があります。名前が示すように、UCS-2 は 2 バイトでエンコードされ、UCS-4 は 4 バイトでエンコードされます (実際には 31 ビットのみが使用され、最上位ビットは 0 である必要があります)。簡単な数学ゲームをいくつかやってみましょう。
UCS-2 には 2^16=65536 コード ポイントがあり、UCS-4 には 2^31=2147483648 コード ポイントがあります。
UCS-4 は、最上位ビットに応じて 2^7=128 のグループに分割され、最上位ビットは 0 になります。各グループは、次に高いバイトに基づいて 256 プレーンに分割されます。各プレーンは 3 番目のバイトに従って 256 行に分割され、各行には 256 個のセルが含まれます。もちろん、同じ行内のセルは最後のバイトが異なるだけで、残りは同じです。
グループ 0 のプレーン 0 は、Basic Multilingual Plane (BMP) と呼ばれます。また、UCS-4 では、上位 2 バイトが 0 のコード ビットを BMP と呼びます。
UCS-2 は、UCS-4 の BMP の最初の 2 つのゼロ バイトを削除することによって取得されます。 UCS-4 の BMP を取得するには、UCS-2 の 2 バイトの前に 2 つのゼロ バイトを追加します。現在の UCS-4 仕様では、BMP の外側に割り当てられた文字はありません。
4. UTF エンコード UTF-8 は、UCS を 8 ビット単位でエンコードします。 UCS-2 から UTF-8 へのエンコードは次のとおりです。
UCS-2 エンコーディング (16 進数) UTF-8 バイト ストリーム (バイナリ)
0000-007F 0xxxxxxx
0080-07FF 110xxxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
たとえば、文字「中国語」の Unicode エンコードは 6C49 です。6C49 は 0800 ～ FFFF の間であるため、3 バイトのテンプレート: 1110xxxx 10xxxxxx 10xxxxxx を使用する必要があります。 6C49 をバイナリで書くと、0110 110001 001001 となります。このビット ストリームを使用してテンプレート内の x を順番に置き換えると、11100110 10110001 10001001、つまり E6 B1 89 が得られます。
読者はメモ帳を使用して、コーディングが正しいかどうかをテストできます。
UTF-16 は、UCS を 16 ビット単位でエンコードします。 0x10000 未満の UCS コードの場合、UTF-16 エンコードは、UCS コードに対応する 16 ビットの符号なし整数と等しくなります。 0x10000 以上の UCS コードについては、アルゴリズムが定義されています。ただし、実際に使用する UCS2 または UCS4 の BMP は 0x10000 未満である必要があるため、現時点では UTF-16 と UCS-2 は基本的に同じであると考えてください。ただし、UCS-2は単なる符号化方式であり、実際の送信にはUTF-16が使用されるため、バイトオーダーの問題を考慮する必要があります。
5. UTF バイト順序と BOM
UTF-8 はエンコード単位としてバイトを使用するため、バイト順序の問題はありません。 UTF-16 は、エンコード単位として 2 バイトを使用します。UTF-16 テキストを解釈する前に、まず各エンコード単位のバイト順序を理解する必要があります。たとえば、受信した「Kui」の Unicode エンコードは 594E で、「B」の Unicode エンコードは 4E59 です。 UTF-16 バイトストリーム「594E」を受信した場合、これは「Ku」ですか、「B」ですか?
Unicode 仕様でバイト順序をマークする推奨方法は、BOM です。 BOM は「部品表」の BOM リストではなく、バイト オーダー マークです。 BOM は少し賢いアイデアです。
UCSエンコードには「ZERO WIDTH NO-BREAK SPACE」という文字があり、そのエンコードはFEFFです。 FFFE は UCS には存在しない文字ですので、実際の送信では出現しないはずです。 UCS 仕様では、バイト ストリームを送信する前に文字「ZERO WIDTH NO-BREAK SPACE」を送信することが推奨されています。
このように、受信機が FEFF を受信した場合は、バイト ストリームがビッグ エンディアンであることを示し、FFFE を受信した場合は、バイト ストリームがリトル エンディアンであることを示します。したがって、「ZERO WIDTH NO-BREAK SPACE」という文字は BOM とも呼ばれます。
UTF-8 では、バイト順序を示すために BOM は必要ありませんが、BOM を使用してエンコード方式を示すことができます。 「ZERO WIDTH NO-BREAK SPACE」という文字の UTF-8 エンコードは EF BB BF です (読者は以前に紹介したエンコード方法を使用して確認できます)。したがって、受信側が EF BB BF で始まるバイト ストリームを受信すると、それが UTF-8 でエンコードされていることを認識します。
Windows は、BOM を使用してテキスト ファイルのエンコーディングをマークします。
6. その他の参考資料 この記事の主な参考資料は、「ISO-IEC 10646 と Unicode の概要」( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html ) です。
また、良さそうな情報を 2 つ見つけましたが、最初の質問に対する答えはすでにわかっていたため、読みませんでした。
「Unicode について Unicode 標準の概要」( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a )
「文字セット エンコードの基本 文字セット エンコードと従来のエンコードについて」 ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03 )
私は、Windows API を使用するバージョンと Windows API を使用しないバージョンを含む、UTF-8、UCS-2、および GBK を相互に変換するためのソフトウェア パッケージを作成しました。今後時間があれば整理して個人ホームページ（ http://fmddlmyy.home4u.china.com ）に載せたいと思います。
いろいろ考えた後、すぐに書き終えることができると思い、この記事を書き始めました。思いの外、文言の検討や細部の確認に時間がかかり、午後1時半から9時までかけて書きました。一部の読者がそれから恩恵を受けることを願っています。
*/
#エンドリージョン