Heute habe ich Javascript-Skript verwendet, um ein Menü-Tool auf der ASP.NET-Seite zu erstellen, und es als menuScript.js gespeichert. Verwenden Sie <script language="javascript" src="../js/MenuScript.js"></script in der Seite >Aufruf, und während des Betriebs trat ein seltsames Phänomen auf: Chinesische Zeichen auf der Seite wurden normal angezeigt, aber chinesische Zeichen im Menü wurden als verstümmelte Zeichen angezeigt.
Kein Grund zu fragen, wenn Sie auf den Knien darüber nachdenken, stimmt etwas mit der Kodierung UTF-8 und GB2312 in der Option „Ansicht“ – „Kodierung“ der Seite nicht Die Zeichen auf der Seite und die chinesischen Zeichen im Menü werden abwechselnd verstümmelt.
Lösung: In der Konfigurationsdatei gibt es Kodierungseinstellungen: <globalisierung requestEncoding="utf-8" responsEncoding="utf-8" />
Beim Speichern der Datei „menuScript.js“ gibt es eine Kodierungsoption (Sie können diese Datei mit Word öffnen und als eine andere speichern, indem Sie die Kodierung auswählen). Behalten Sie einfach die beiden Kodierungen bei.
Um das Codierungsproblem besser zu verstehen, habe ich einen Artikel dazu in CSDN gefunden, Autor: fmddlmyy. Drucken Sie es hier als Referenz noch einmal aus:
Reden wir über Codierung Reden wir über Codierung #region Reden wir über Codierung
/**//*
0. Big Endian und Little Endian
Big Endian und Little Endian sind unterschiedliche Methoden, mit denen die CPU Multibyte-Zahlen verarbeitet. Beispielsweise ist die Unicode-Kodierung des Zeichens „汉“ 6C49. Sollte beim Schreiben in eine Datei also 6C vorne oder 49 vorne geschrieben werden? Wenn 6C vorne steht, handelt es sich um Big Endian. Oder schreiben Sie 49 voran, was Little Endian ist.
Das Wort „Endian“ stammt aus „Gullivers Reisen“. Der Bürgerkrieg in Liliput entstand aus der Frage, ob die Eier vom großen Ende (Big-Endian) oder vom kleinen Ende (Little-Endian) geknackt werden sollten. Infolgedessen kam es zu sechs Aufständen, einer der Kaiser verlor sein Leben und der der andere verlor seinen Thron.
Wir übersetzen Endian im Allgemeinen als „Bytereihenfolge“, und Big Endian und Little Endian werden als „Big End“ und „Little End“ bezeichnet.
1. Zeichenkodierung und interner Code Chinesische Zeichen müssen übrigens kodiert werden, bevor sie vom Computer verarbeitet werden können. Die vom Computer verwendete Standardcodierungsmethode ist der interne Code des Computers. Frühe Computer nutzten die 7-Bit-ASCII-Kodierung, um chinesische Zeichen zu verarbeiten. Programmierer entwickelten GB2312 für vereinfachtes Chinesisch und big5 für traditionelles Chinesisch.
GB2312 (1980) enthält insgesamt 7445 Zeichen, darunter 6763 chinesische Schriftzeichen und 682 andere Symbole. Der interne Codebereich des chinesischen Zeichenbereichs reicht von B0-F7 im High-Byte, A1-FE im Low-Byte und die belegten Codebits sind 72*94=6768. Darunter sind 5 offene Stellen D7FA-D7FE.
GB2312 unterstützt zu wenige chinesische Schriftzeichen. Die Erweiterungsspezifikation für chinesische Schriftzeichen GBK1.0 aus dem Jahr 1995 umfasst 21.886 Symbole, die in den Bereich für chinesische Schriftzeichen und den Bereich für grafische Symbole unterteilt sind. Der chinesische Schriftzeichenbereich umfasst 21003 Zeichen. GB18030 im Jahr 2000 ist der offizielle nationale Standard, der GBK1.0 ersetzte. Dieser Standard umfasst 27.484 chinesische Schriftzeichen sowie Tibetisch, Mongolisch, Uigurisch und andere wichtige Sprachen ethnischer Minderheiten. Die aktuelle PC-Plattform muss GB18030 unterstützen und es gibt keine Anforderungen für eingebettete Produkte. Daher unterstützen Mobiltelefone und MP3 im Allgemeinen nur GB2312.
Von ASCII, GB2312, GBK bis GB18030 sind diese Kodierungsmethoden abwärtskompatibel, d. h. das gleiche Zeichen hat in diesen Schemata immer die gleiche Kodierung, und spätere Standards unterstützen mehr Zeichen. In diesen Kodierungen können Englisch und Chinesisch einheitlich verarbeitet werden. Die Unterscheidung zwischen chinesischer Codierung besteht darin, dass das höchste Bit des High-Bytes nicht 0 ist. Gemäß der Bezeichnung der Programmierer gehören GB2312, GBK bis GB18030 alle zu Doppelbyte-Zeichensätzen (DBCS).
Der standardmäßige interne Code einiger chinesischer Windows ist immer noch GBK, der über das GB18030-Upgrade-Paket auf GB18030 aktualisiert werden kann. Allerdings sind die von GB18030 im Vergleich zu GBK hinzugefügten Zeichen für normale Menschen schwierig zu verwenden. Normalerweise verwenden wir GBK immer noch, um auf chinesischen Windows-internen Code zu verweisen.
Hier noch ein paar Details:
Der ursprüngliche Text von GB2312 ist immer noch die Vorwahl. Von der Vorwahl bis zur inneren Vorwahl muss A0 zum High-Byte bzw. Low-Byte hinzugefügt werden.
In DBCS ist das Speicherformat des GB-internen Codes immer Big Endian, d. h. das höherwertige Bit steht an erster Stelle.
Die höchsten Bits der beiden Bytes von GB2312 sind beide 1. Es gibt jedoch nur 128*128=16384 Codepunkte, die diese Bedingung erfüllen. Daher ist das höchste Bit des Low-Bytes von GBK und GB18030 möglicherweise nicht 1. Dies hat jedoch keinen Einfluss auf das Parsen des DBCS-Zeichenstroms: Beim Lesen des DBCS-Zeichenstroms können die nächsten beiden Bytes unabhängig davon als Doppelbyte codiert werden, solange ein Byte mit einem hohen Bit von 1 angetroffen wird Low-Byte. Was ist High-Position?
2. Unicode, UCS und UTF
Wie bereits erwähnt, sind die Kodierungsmethoden von ASCII, GB2312, GBK bis GB18030 abwärtskompatibel. Unicode ist nur mit ASCII kompatibel (genauer gesagt mit ISO-8859-1) und nicht mit GB-Code. Beispielsweise ist die Unicode-Kodierung des Zeichens „汉“ 6C49, während der GB-Code BABA ist.
Unicode ist ebenfalls eine Zeichenkodierungsmethode, wurde jedoch von einer internationalen Organisation entwickelt und kann Kodierungsschemata für alle Sprachen auf der ganzen Welt unterstützen. Der wissenschaftliche Name von Unicode ist „Universal Multiple-Octet Coded Character Set“, kurz UCS. UCS kann als Abkürzung für „Unicode Character Set“ angesehen werden.
Laut Wikipedia ( http://zh.wikipedia.org/wiki/ ): Historisch gesehen gab es zwei Organisationen, die versuchten, Unicode unabhängig voneinander zu entwerfen, nämlich die International Organization for Standardization (ISO) und eine Vereinigung von Softwareherstellern (Unicode). org). ISO entwickelte das ISO 10646-Projekt und das Unicode-Konsortium entwickelte das Unicode-Projekt.
Um 1991 erkannten beide Seiten, dass die Welt keine zwei inkompatiblen Zeichensätze brauchte. Also begannen sie, die Arbeit beider Parteien zusammenzuführen und gemeinsam eine einzige Codierungsliste zu erstellen. Ab Unicode2.0 verwendet das Unicode-Projekt dieselben Schriftarten und Schriftarten wie ISO 10646-1.
Beide Projekte existieren noch und veröffentlichen unabhängig voneinander ihre eigenen Standards. Die neueste Version des Unicode-Konsortiums ist Unicode 4.1.0 aus dem Jahr 2005. Der neueste ISO-Standard ist 10646-3:2003.
UCS gibt an, wie mehrere Bytes zur Darstellung verschiedener Texte verwendet werden. Wie diese Kodierungen übertragen werden, ist in der UTF-Spezifikation (UCS Transformation Format) festgelegt. Zu den gängigen UTF-Spezifikationen gehören UTF-8, UTF-7 und UTF-16.
RFC2781 und RFC3629 der IETF beschreiben die Kodierungsmethoden von UTF-16 und UTF-8 klar, klar und präzise im einheitlichen RFC-Stil. Ich vergesse immer, dass IETF die Abkürzung für Internet Engineering Task Force ist. Der von der IETF gepflegte RFC ist jedoch die Grundlage für alle Spezifikationen im Internet.
3. UCS-2, UCS-4, BMP
UCS gibt es in zwei Formaten: UCS-2 und UCS-4. Wie der Name schon sagt, ist UCS-2 mit zwei Bytes kodiert und UCS-4 mit 4 Bytes (tatsächlich werden nur 31 Bits verwendet, das höchste Bit muss 0 sein). Lass uns ein paar einfache Mathe-Spiele machen:
UCS-2 hat 2^16=65536 Codepunkte und UCS-4 hat 2^31=2147483648 Codepunkte.
UCS-4 ist entsprechend dem höchsten Byte in 2^7=128 Gruppen unterteilt, wobei das höchste Bit 0 ist. Jede Gruppe ist basierend auf dem nächsthöheren Byte in 256 Ebenen unterteilt. Jede Ebene ist entsprechend dem dritten Byte in 256 Zeilen unterteilt, und jede Zeile enthält 256 Zellen. Natürlich unterscheiden sich Zellen in derselben Zeile nur im letzten Byte, der Rest ist gleich.
Ebene 0 der Gruppe 0 wird als Basic Multilingual Plane oder BMP bezeichnet. Oder in UCS-4 werden die Codebits, bei denen die oberen beiden Bytes 0 sind, als BMP bezeichnet.
UCS-2 wird durch Entfernen der ersten beiden Nullbytes des BMP von UCS-4 erhalten. Fügen Sie vor den beiden Bytes von UCS-2 zwei Nullbytes hinzu, um den BMP von UCS-4 zu erhalten. In der aktuellen UCS-4-Spezifikation werden keine Zeichen außerhalb des BMP zugewiesen.
4. UTF-Kodierung UTF-8 kodiert UCS in 8-Bit-Einheiten. Die Kodierung von UCS-2 nach UTF-8 ist wie folgt:
UCS-2-Kodierung (hexadezimal) UTF-8-Byte-Stream (binär)
0000-007F 0xxxxxxx
0080-07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
Die Unicode-Kodierung des Zeichens „Chinesisch“ ist beispielsweise 6C49. 6C49 liegt zwischen 0800 und FFFF, daher müssen Sie eine 3-Byte-Vorlage verwenden: 1110xxxx 10xxxxxx 10xxxxxx. Das Schreiben von 6C49 im Binärformat lautet: 0110 110001 001001. Wenn wir diesen Bitstrom verwenden, um x in der Vorlage zu ersetzen, erhalten wir: 11100110 10110001 10001001, was E6 B1 89 ist.
Leser können Notepad verwenden, um zu testen, ob unsere Codierung korrekt ist.
UTF-16 kodiert UCS in 16-Bit-Einheiten. Für UCS-Codes kleiner als 0x10000 entspricht die UTF-16-Codierung der 16-Bit-Ganzzahl ohne Vorzeichen, die dem UCS-Code entspricht. Für UCS-Codes nicht kleiner als 0x10000 ist ein Algorithmus definiert. Da jedoch der BMP des tatsächlich verwendeten UCS2 oder UCS4 kleiner als 0x10000 sein muss, kann vorerst davon ausgegangen werden, dass UTF-16 und UCS-2 grundsätzlich gleich sind. Allerdings handelt es sich bei UCS-2 nur um ein Codierungsschema, und für die eigentliche Übertragung wird UTF-16 verwendet, sodass die Frage der Bytereihenfolge berücksichtigt werden muss.
5. UTF-Bytereihenfolge und BOM
UTF-8 verwendet Bytes als Codierungseinheit, und es gibt kein Problem mit der Bytereihenfolge. UTF-16 verwendet zwei Bytes als Kodierungseinheit. Bevor Sie einen UTF-16-Text interpretieren, müssen Sie zunächst die Bytereihenfolge jeder Kodierungseinheit verstehen. Beispielsweise ist die empfangene Unicode-Kodierung von „Kui“ 594E und die Unicode-Kodierung von „B“ ist 4E59. Wenn wir den UTF-16-Byte-Stream „594E“ empfangen, ist das „Ku“ oder „B“?
Die empfohlene Methode zum Markieren der Bytereihenfolge in der Unicode-Spezifikation ist die Stückliste. Bei der Stückliste handelt es sich nicht um die Stücklistenliste der „Bill Of Material“, sondern um die Byte Order Mark. BOM ist eine kleine clevere Idee:
In der UCS-Codierung gibt es ein Zeichen namens „ZERO WIDTH NO-BREAK SPACE“, und seine Codierung ist FEFF. FFFE ist ein Zeichen, das in UCS nicht existiert und daher in der tatsächlichen Übertragung nicht erscheinen sollte. Die UCS-Spezifikation empfiehlt, dass wir vor der Übertragung des Bytestreams die Zeichen „ZERO WIDTH NO-BREAK SPACE“ übertragen.
Wenn der Empfänger FEFF empfängt, zeigt er auf diese Weise an, dass der Bytestrom Big-Endian ist. Wenn er FFFE empfängt, zeigt er an, dass der Bytestrom Little-Endian ist. Daher wird das Zeichen „ZERO WIDTH NO-BREAK SPACE“ auch BOM genannt.
UTF-8 erfordert keine BOM zur Angabe der Bytereihenfolge, kann jedoch die BOM zur Angabe der Codierungsmethode verwenden. Die UTF-8-Kodierung des Zeichens „ZERO WIDTH NO-BREAK SPACE“ ist EF BB BF (Leser können dies mit der zuvor eingeführten Kodierungsmethode überprüfen). Wenn der Empfänger also einen Bytestrom empfängt, der mit EF BB BF beginnt, weiß er, dass dieser UTF-8-codiert ist.
Windows verwendet BOM, um die Kodierung von Textdateien zu markieren.
6. Weitere Referenzmaterialien Das Hauptreferenzmaterial für diesen Artikel ist „Kurzer Überblick über ISO-IEC 10646 und Unicode“ ( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html ).
Ich habe auch zwei Informationen gefunden, die gut aussahen, aber weil ich bereits die Antworten auf meine ersten Fragen hatte, habe ich sie nicht gelesen:
„Unicode verstehen Eine allgemeine Einführung in den Unicode-Standard“ ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a )
„Grundlagen der Zeichensatzkodierung Grundlegendes zu Zeichensatzkodierungen und Legacy-Kodierungen“ ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03 )
Ich habe Softwarepakete zum Konvertieren von UTF-8, UCS-2 und GBK ineinander und voneinander geschrieben, einschließlich Versionen, die die Windows-API verwenden, und Versionen, die die Windows-API nicht verwenden. Wenn ich in Zukunft Zeit habe, werde ich es klären und auf meiner persönlichen Homepage ( http://fmddlmyy.home4u.china.com ) veröffentlichen.
Nachdem ich alle Themen durchgedacht hatte, begann ich mit dem Schreiben dieses Artikels. Ich dachte, ich könnte ihn in einer Weile fertigstellen. Unerwarteterweise dauerte es lange, über den Wortlaut nachzudenken und die Details zu überprüfen, und ich schrieb es von 13:30 bis 21:00 Uhr nachmittags. Ich hoffe, dass einige Leser davon profitieren können.
*/
#endregion