Hari ini, saya menggunakan skrip javascript untuk membuat alat menu di halaman ASP.NET, dan menyimpannya sebagai menuScript.js. Gunakan <script Language="javascript" src="../js/MenuScript.js"></script di halaman >Panggilan, dan fenomena aneh terjadi selama pengoperasian: Karakter China pada halaman ditampilkan secara normal, namun karakter China di menu ditampilkan sebagai karakter kacau.
Tidak perlu bertanya, jika Anda memikirkannya, ada yang salah dengan pengkodean. Beralih antara pengkodean UTF-8 dan GB2312 di opsi "Lihat"-"Pengkodean" pada halaman karakter pada halaman dan karakter Cina pada menu bergantian menjadi kacau.
Solusi: Ada pengaturan pengkodean dalam file konfigurasi: <globalisasi requestEncoding="utf-8" responEncoding="utf-8" />
Ada opsi pengkodean saat menyimpan file menuScript.js (Anda dapat membuka file ini dengan Word dan menyimpannya sebagai yang lain, pilih pengkodean), biarkan kedua pengkodean tetap sama.
Untuk lebih memahami masalah coding, saya menemukan artikel ini di CSDN, penulis: fmddlmyy. Cetak ulang di sini untuk referensi:
Mari kita bicara tentang coding Mari kita bicara tentang coding #region Mari kita bicara tentang coding
/**//*
0. endian besar dan endian kecil
big endian dan little endian adalah cara CPU menangani angka multibyte yang berbeda. Misalnya, pengkodean Unicode untuk karakter "汉" adalah 6C49. Jadi saat menulis ke file, apakah 6C harus ditulis di depan atau 49 ditulis di depan? Jika 6C ditulis di depan, itu adalah big endian. Atau tulis 49 di depannya, yang merupakan little endian.
Kata "endian" berasal dari "Gulliver's Travels". Perang saudara di Lilliput berawal dari pecahnya telur dari pihak besar (Big-Endian) atau pihak kecil (Little-Endian). Akibatnya, terjadi enam pemberontakan, salah satu kaisar kehilangan nyawanya, dan Yang lainnya kehilangan tahtanya.
Kami biasanya menerjemahkan endian sebagai "urutan byte", dan endian besar serta endian kecil disebut "akhir besar" dan "akhir kecil".
1. Pengkodean karakter dan kode internal. Omong-omong, karakter pengkodean karakter Cina harus dikodekan sebelum dapat diproses oleh komputer. Metode pengkodean default yang digunakan oleh komputer adalah kode internal komputer. Komputer awal menggunakan pengkodean ASCII 7-bit untuk memproses karakter bahasa Mandarin, pemrogram merancang GB2312 untuk bahasa Mandarin Sederhana dan big5 untuk bahasa Mandarin Tradisional.
GB2312 (1980) berisi total 7445 karakter, termasuk 6763 karakter Cina dan 682 simbol lainnya. Rentang kode internal area karakter Cina adalah dari B0-F7 dalam byte tinggi, A1-FE dalam byte rendah, dan bit kode yang ditempati adalah 72*94=6768. Diantaranya, 5 lowongan adalah D7FA-D7FE.
GB2312 mendukung terlalu sedikit karakter Cina. Spesifikasi perluasan karakter Cina tahun 1995 GBK1.0 mencakup 21.886 simbol, yang dibagi menjadi area karakter Cina dan area simbol grafis. Area karakter Cina mencakup 21003 karakter. GB18030 pada tahun 2000 adalah standar nasional resmi yang menggantikan GBK1.0. Standar ini mencakup 27.484 karakter Tiongkok, serta bahasa Tibet, Mongolia, Uyghur, dan bahasa etnis minoritas utama lainnya. Platform PC saat ini harus mendukung GB18030, dan tidak ada persyaratan untuk produk tertanam. Oleh karena itu, ponsel dan MP3 umumnya hanya mendukung GB2312.
Dari ASCII, GB2312, GBK hingga GB18030, metode pengkodean ini kompatibel ke belakang, artinya, karakter yang sama selalu memiliki pengkodean yang sama dalam skema ini, dan standar yang lebih baru mendukung lebih banyak karakter. Dalam pengkodean ini, bahasa Inggris dan Cina dapat diproses secara seragam. Cara membedakan pengkodean Cina adalah bahwa bit tertinggi dari byte tinggi bukanlah 0. Menurut sebutan programmer, GB2312, GBK hingga GB18030 semuanya termasuk dalam kumpulan karakter byte ganda (DBCS).
Kode internal default beberapa Windows Cina masih GBK, yang dapat ditingkatkan ke GB18030 melalui paket pemutakhiran GB18030. Namun karakter yang ditambahkan oleh GB18030 dibandingkan dengan GBK sulit digunakan oleh orang awam. Biasanya kami masih menggunakan GBK untuk merujuk pada kode internal Windows berbahasa Mandarin.
Berikut beberapa detail selengkapnya:
Teks asli GB2312 masih berupa kode area. Dari kode area hingga kode bagian dalam, A0 perlu ditambahkan masing-masing ke byte tinggi dan byte rendah.
Di DBCS, format penyimpanan kode internal GB selalu big endian, artinya bit tingkat tinggi didahulukan.
Bit tertinggi dari dua byte GB2312 keduanya 1. Namun hanya ada 128*128=16384 titik kode yang memenuhi ketentuan ini. Oleh karena itu, bit tertinggi dari byte rendah GBK dan GB18030 mungkin bukan 1. Namun, hal ini tidak mempengaruhi penguraian aliran karakter DBCS: saat membaca aliran karakter DBCS, selama ditemukan byte dengan bit tinggi 1, dua byte berikutnya dapat dikodekan sebagai byte ganda, apa pun jenisnya. byte rendah. Apa itu posisi tinggi.
2. Unicode, UCS dan UTF
Seperti disebutkan sebelumnya, metode pengkodean dari ASCII, GB2312, GBK hingga GB18030 kompatibel. Unicode hanya kompatibel dengan ASCII (lebih tepatnya, kompatibel dengan ISO-8859-1) dan tidak kompatibel dengan kode GB. Misalnya, pengkodean Unicode untuk karakter "汉" adalah 6C49, sedangkan kode GB adalah BABA.
Unicode juga merupakan metode pengkodean karakter, namun dirancang oleh organisasi internasional dan dapat mengakomodasi skema pengkodean untuk semua bahasa di seluruh dunia. Nama ilmiah Unicode adalah "Universal Multiple-Octet Coded Character Set", atau disingkat UCS. UCS dapat dilihat sebagai singkatan dari "Unicode Character Set".
Menurut Wikipedia ( http://zh.wikipedia.org/wiki/ ): Secara historis, ada dua organisasi yang mencoba merancang Unicode secara mandiri, yaitu Organisasi Internasional untuk Standardisasi (ISO) dan asosiasi produsen perangkat lunak (unicode. organisasi). ISO mengembangkan proyek ISO 10646 dan Konsorsium Unicode mengembangkan proyek Unicode.
Sekitar tahun 1991, kedua belah pihak menyadari bahwa dunia tidak membutuhkan dua rangkaian karakter yang tidak kompatibel. Jadi mereka mulai menggabungkan pekerjaan kedua belah pihak dan bekerja sama untuk membuat satu daftar pengkodean. Mulai dari Unicode2.0, proyek Unicode menggunakan font dan font yang sama dengan ISO 10646-1.
Kedua proyek tersebut masih ada dan menerbitkan standarnya sendiri secara independen. Versi terbaru dari Konsorsium Unicode adalah Unicode 4.1.0 pada tahun 2005. Standar ISO terbaru adalah 10646-3:2003.
UCS menentukan cara menggunakan beberapa byte untuk mewakili berbagai teks. Cara mengirimkan pengkodean ini ditentukan oleh spesifikasi UTF (UCS Transformation Format). Spesifikasi umum UTF mencakup UTF-8, UTF-7, dan UTF-16.
RFC2781 dan RFC3629 IETF menjelaskan metode pengkodean UTF-16 dan UTF-8 dengan jelas, tajam dan teliti dalam gaya RFC yang konsisten. Saya selalu lupa bahwa IETF adalah singkatan dari Internet Engineering Task Force. Namun, RFC yang dikelola oleh IETF adalah dasar dari semua spesifikasi di Internet.
3. UCS-2, UCS-4, BMP
UCS hadir dalam dua format: UCS-2 dan UCS-4. Seperti namanya, UCS-2 dikodekan dengan dua byte, dan UCS-4 dikodekan dengan 4 byte (sebenarnya yang digunakan hanya 31 bit, bit tertinggi harus 0). Mari kita lakukan beberapa permainan matematika sederhana:
UCS-2 memiliki 2^16=65536 titik kode, dan UCS-4 memiliki 2^31=2147483648 titik kode.
UCS-4 dibagi menjadi 2^7=128 grup menurut byte tertinggi dengan bit tertinggi adalah 0. Setiap grup dibagi menjadi 256 bidang berdasarkan byte tertinggi berikutnya. Setiap bidang dibagi menjadi 256 baris menurut byte ketiga, dan setiap baris berisi 256 sel. Tentu saja, sel-sel di baris yang sama hanya berbeda pada byte terakhir, dan sisanya sama.
Bidang 0 dari grup 0 disebut Bidang Multibahasa Dasar, atau BMP. Atau di UCS-4, bit kode dengan dua byte teratas adalah 0 disebut BMP.
UCS-2 diperoleh dengan menghapus dua byte nol pertama dari BMP UCS-4. Tambahkan dua byte nol di depan dua byte UCS-2 untuk mendapatkan BMP UCS-4. Tidak ada karakter yang dialokasikan di luar BMP dalam spesifikasi UCS-4 saat ini.
4. Pengkodean UTF UTF-8 mengkodekan UCS dalam unit 8-bit. Pengkodean dari UCS-2 ke UTF-8 adalah sebagai berikut:
Pengkodean UCS-2 (heksadesimal) Aliran byte UTF-8 (biner)
0000-007F 0xxxxxxx
0080-07FF 110xxxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
Misalnya, pengkodean Unicode karakter "Cina" adalah 6C49 adalah antara 0800-FFFF, jadi Anda harus menggunakan templat 3-byte: 1110xxxx 10xxxxxx 10xxxxxx. Penulisan 6C49 dalam biner adalah: 0110 110001 001001. Dengan menggunakan aliran bit ini untuk menggantikan x pada template secara bergantian, kita mendapatkan: 11100110 10110001 10001001, yaitu E6 B1 89.
Pembaca dapat menggunakan Notepad untuk menguji apakah pengkodean kita sudah benar.
UTF-16 mengkodekan UCS dalam unit 16-bit. Untuk kode UCS kurang dari 0x10000, pengkodean UTF-16 sama dengan bilangan bulat 16-bit unsigned yang sesuai dengan kode UCS. Untuk kode UCS tidak kurang dari 0x10000, suatu algoritma ditentukan. Namun, karena BMP dari UCS2 atau UCS4 yang sebenarnya digunakan harus kurang dari 0x10000, untuk saat ini, UTF-16 dan UCS-2 pada dasarnya dapat dianggap sama. Namun, UCS-2 hanyalah skema pengkodean, dan UTF-16 digunakan untuk transmisi sebenarnya, jadi masalah urutan byte harus dipertimbangkan.
5. Urutan byte UTF dan BOM
UTF-8 menggunakan byte sebagai unit pengkodean, dan tidak ada masalah urutan byte. UTF-16 menggunakan dua byte sebagai unit pengkodean. Sebelum menafsirkan teks UTF-16, Anda harus terlebih dahulu memahami urutan byte setiap unit pengkodean. Misalnya, pengkodean Unicode "Kui" yang diterima adalah 594E, dan pengkodean Unicode "B" adalah 4E59. Jika kita menerima aliran UTF-16 byte "594E", apakah ini "Ku" atau "B"?
Metode yang disarankan untuk menandai urutan byte dalam spesifikasi Unicode adalah BOM. BOM bukanlah daftar BOM "Bill Of Material", melainkan Byte Order Mark. BOM adalah ide yang sedikit cerdas:
Ada karakter bernama "ZERO WIDTH NO-BREAK SPACE" dalam pengkodean UCS, dan pengkodeannya adalah FEFF. FFFE adalah karakter yang tidak ada di UCS, jadi seharusnya tidak muncul di transmisi sebenarnya. Spesifikasi UCS merekomendasikan agar kami mengirimkan karakter "ZERO WIDTH NO-BREAK SPACE" sebelum mengirimkan aliran byte.
Dengan cara ini, jika penerima menerima FEFF, ini menunjukkan bahwa aliran byte adalah Big-Endian; jika menerima FFFE, ini menunjukkan bahwa aliran byte adalah Little-Endian. Oleh karena itu karakter "ZERO WIDTH NO-BREAK SPACE" disebut juga BOM.
UTF-8 tidak memerlukan BOM untuk menunjukkan urutan byte, tetapi dapat menggunakan BOM untuk menunjukkan metode pengkodean. Pengkodean UTF-8 untuk karakter "ZERO WIDTH NO-BREAK SPACE" adalah EF BB BF (pembaca dapat memverifikasinya menggunakan metode pengkodean yang kami perkenalkan sebelumnya). Jadi jika penerima menerima aliran byte yang dimulai dengan EF BB BF, ia mengetahui bahwa itu dikodekan UTF-8.
Windows menggunakan BOM untuk menandai pengkodean file teks.
6. Bahan referensi lebih lanjut Bahan referensi utama untuk artikel ini adalah "Ikhtisar Singkat ISO-IEC 10646 dan Unicode" ( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html ).
Saya juga menemukan dua informasi yang kelihatannya bagus, tetapi karena saya sudah mempunyai jawaban atas pertanyaan awal saya, saya tidak membacanya:
"Memahami Unicode Pengantar umum tentang Standar Unicode" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a )
"Dasar-dasar pengkodean kumpulan karakter Memahami pengkodean kumpulan karakter dan pengkodean lama" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03 )
Saya telah menulis paket perangkat lunak untuk mengonversi UTF-8, UCS-2, dan GBK ke dan dari satu sama lain, termasuk versi yang menggunakan Windows API dan versi yang tidak menggunakan Windows API. Jika saya punya waktu di masa depan, saya akan memilahnya dan menaruhnya di beranda pribadi saya ( http://fmddlmyy.home4u.china.com ).
Saya mulai menulis artikel ini setelah memikirkan semua masalahnya. Saya pikir saya bisa menyelesaikannya dalam beberapa saat. Tanpa diduga, butuh waktu lama untuk mempertimbangkan kata-katanya dan memeriksa detailnya, dan saya menulisnya dari jam 1:30 hingga 9:00 sore. Semoga beberapa pembaca dapat mengambil manfaat darinya.
*/
#wilayah akhir