Aujourd'hui, j'ai utilisé un script javascript pour créer un outil de menu dans la page ASP.NET et je l'ai enregistré sous menuScript.js. Utilisez <script language="javascript" src="../js/MenuScript.js"></script. dans la page >Appel, et un phénomène étrange s'est produit pendant le fonctionnement : les caractères chinois sur la page étaient affichés normalement, mais les caractères chinois dans le menu étaient affichés comme des caractères tronqués.
Pas besoin de demander, si vous y réfléchissez à genoux, il y a un problème avec l'encodage. Basculez entre les encodages UTF-8 et GB2312 dans l'option "Affichage" - "Encodage" de la page. Les caractères de la page et les caractères chinois du menu deviennent alternativement tronqués.
Solution : Il existe des paramètres d'encodage dans le fichier de configuration : <globalization requestEncoding="utf-8" ResponseEncoding="utf-8" />
Il existe une option d'encodage lors de l'enregistrement du fichier menuScript.js (vous pouvez ouvrir ce fichier avec Word et l'enregistrer sous un autre, sélectionner l'encodage), gardez simplement les deux encodages identiques.
Afin de mieux comprendre le problème de codage, j'ai trouvé un article à ce sujet dans CSDN, auteur : fmddlmyy. Réimprimez-le ici pour référence :
Parlons de codage Parlons de codage #region Parlons de codage
/**//*
0. big endian et petit endian
big endian et little endian sont des méthodes différentes par lesquelles le processeur gère les nombres multi-octets. Par exemple, le codage Unicode du caractère « 汉 » est 6C49. Ainsi, lors de l'écriture dans un fichier, faut-il écrire 6C devant ou 49 devant ? Si 6C est écrit devant, c’est big endian. Ou écrivez 49 devant, ce qui est du petit endian.
Le mot « endian » vient des « Voyages de Gulliver ». La guerre civile à Lilliput est née de la question de savoir s'il fallait casser les œufs du gros bout (Big-Endian) ou du petit bout (Little-Endian). En conséquence, six rébellions ont eu lieu, l'un des empereurs a perdu la vie et le premier. l'autre a perdu son trône.
Nous traduisons généralement endian par « ordre des octets », et big endian et little endian sont appelés « big end » et « little end ».
1. Codage des caractères et code interne À propos, les caractères de codage des caractères chinois doivent être codés avant de pouvoir être traités par l'ordinateur. La méthode de codage par défaut utilisée par l'ordinateur est le code interne de l'ordinateur. Les premiers ordinateurs utilisaient le codage ASCII 7 bits Afin de traiter les caractères chinois, les programmeurs ont conçu le GB2312 pour le chinois simplifié et le big5 pour le chinois traditionnel.
GB2312 (1980) contient un total de 7 445 caractères, dont 6 763 caractères chinois et 682 autres symboles. La plage de code interne de la zone de caractères chinois s'étend de B0 à F7 dans l'octet de poids fort, A1 à FE dans l'octet de poids faible, et les bits de code occupés sont 72*94=6768. Parmi eux, 5 postes vacants sont D7FA-D7FE.
Le GB2312 prend en charge trop peu de caractères chinois. La spécification d'extension des caractères chinois GBK1.0 de 1995 comprend 21 886 symboles, divisés en zone de caractères chinois et zone de symboles graphiques. La zone des caractères chinois comprend 21 003 caractères. GB18030 en 2000 est la norme nationale officielle qui a remplacé GBK1.0. Cette norme comprend 27 484 caractères chinois, ainsi que le tibétain, le mongol, l'ouïghour et d'autres langues minoritaires ethniques majeures. La plate-forme PC actuelle doit prendre en charge le GB18030 et il n'y a aucune exigence concernant les produits intégrés. Par conséquent, les téléphones mobiles et les MP3 ne prennent généralement en charge que le GB2312.
De ASCII, GB2312, GBK à GB18030, ces méthodes de codage sont rétrocompatibles, c'est-à-dire que le même caractère a toujours le même codage dans ces schémas, et les normes ultérieures prennent en charge plus de caractères. Dans ces codages, l'anglais et le chinois peuvent être traités de manière uniforme. La façon de distinguer le codage chinois est que le bit le plus élevé de l'octet de poids fort n'est pas 0. Selon les noms des programmeurs, GB2312, GBK à GB18030 appartiennent tous à des jeux de caractères à deux octets (DBCS).
Le code interne par défaut de certains Windows chinois est toujours GBK, qui peut être mis à niveau vers GB18030 via le package de mise à niveau GB18030. Cependant, les caractères ajoutés par GB18030 par rapport à GBK sont difficiles à utiliser pour les gens ordinaires. Habituellement, nous utilisons toujours GBK pour faire référence au code interne chinois de Windows.
Voici quelques détails supplémentaires :
Le texte original du GB2312 est toujours l'indicatif régional, de l'indicatif régional au code interne, A0 doit être ajouté respectivement à l'octet de poids fort et à l'octet de poids faible.
Dans DBCS, le format de stockage du code interne du Go est toujours big endian, c'est-à-dire que le bit de poids fort vient en premier.
Les bits les plus élevés des deux octets du GB2312 sont tous deux égaux à 1. Mais il n’y a que 128*128=16384 points de code qui remplissent cette condition. Par conséquent, le bit le plus élevé de l’octet faible de GBK et GB18030 peut ne pas être 1. Cependant, cela n'affecte pas l'analyse du flux de caractères DBCS : lors de la lecture du flux de caractères DBCS, tant qu'un octet avec un bit haut de 1 est rencontré, les deux octets suivants peuvent être codés comme un double octet, quel que soit le octet faible. Qu'est-ce que la position haute.
2. Unicode, UCS et UTF
Comme mentionné précédemment, les méthodes de codage ASCII, GB2312, GBK à GB18030 sont rétrocompatibles. Unicode est uniquement compatible avec ASCII (plus précisément, compatible avec ISO-8859-1) et n'est pas compatible avec le code GB. Par exemple, le codage Unicode du caractère « 汉 » est 6C49, tandis que le code GB est BABA.
Unicode est également une méthode de codage de caractères, mais elle est conçue par une organisation internationale et peut s'adapter aux schémas de codage pour toutes les langues du monde. Le nom scientifique d'Unicode est « Jeu de caractères codés universels à plusieurs octets », ou UCS en abrégé. UCS peut être considéré comme l'abréviation de « Jeu de caractères Unicode ».
Selon Wikipédia ( http://zh.wikipedia.org/wiki/ ) : Historiquement, deux organisations ont tenté de concevoir Unicode de manière indépendante, à savoir l'Organisation internationale de normalisation (ISO) et une association de fabricants de logiciels (unicode. org). L'ISO a développé le projet ISO 10646 et le Consortium Unicode a développé le projet Unicode.
Vers 1991, les deux parties ont reconnu que le monde n’avait pas besoin de deux jeux de caractères incompatibles. Ils ont donc commencé à fusionner le travail des deux parties et à travailler ensemble pour créer une liste de codage unique. À partir d'Unicode2.0, le projet Unicode utilise les mêmes polices et polices que l'ISO 10646-1.
Les deux projets existent toujours et publient leurs propres normes de manière indépendante. La dernière version du Consortium Unicode est Unicode 4.1.0 en 2005. La dernière norme ISO est la 10646-3:2003.
UCS spécifie comment utiliser plusieurs octets pour représenter divers textes. La manière de transmettre ces codages est stipulée par la spécification UTF (UCS Transformation Format). Les spécifications UTF courantes incluent UTF-8, UTF-7 et UTF-16.
Les RFC2781 et RFC3629 de l'IETF décrivent les méthodes de codage UTF-16 et UTF-8 de manière claire, précise et rigoureuse dans le style cohérent de la RFC. J'oublie toujours que IETF est l'abréviation de Internet Engineering Task Force. Cependant, la RFC maintenue par l'IETF constitue la base de toutes les spécifications sur Internet.
3. UCS-2, UCS-4, BMP
UCS est disponible en deux formats : UCS-2 et UCS-4. Comme son nom l'indique, UCS-2 est codé sur deux octets et UCS-4 est codé sur 4 octets (en fait, seuls 31 bits sont utilisés, le bit le plus élevé doit être 0). Faisons quelques jeux mathématiques simples :
UCS-2 a 2^16=65536 points de code et UCS-4 a 2^31=2147483648 points de code.
UCS-4 est divisé en 2 ^ 7 = 128 groupes selon l'octet le plus élevé, le bit le plus élevé étant 0. Chaque groupe est divisé en 256 plans en fonction de l'octet suivant le plus élevé. Chaque plan est divisé en 256 lignes selon le troisième octet, et chaque ligne contient 256 cellules. Bien entendu, les cellules d’une même ligne ne diffèrent que par le dernier octet, et le reste est identique.
Le plan 0 du groupe 0 est appelé plan multilingue de base, ou BMP. Ou dans UCS-4, les bits de code dont les deux octets supérieurs sont 0 sont appelés BMP.
UCS-2 est obtenu en supprimant les deux premiers octets zéro du BMP d'UCS-4. Ajoutez deux octets zéro devant les deux octets de l'UCS-2 pour obtenir le BMP de l'UCS-4. Aucun caractère n'est alloué en dehors du BMP dans la spécification UCS-4 actuelle.
4. Codage UTF UTF-8 code UCS en unités de 8 bits. L'encodage d'UCS-2 vers UTF-8 est le suivant :
Encodage UCS-2 (hexadécimal) Flux d'octets UTF-8 (binaire)
0000-007F 0xxxxxxx
0080-07FF 110xxxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
Par exemple, le codage Unicode du caractère « chinois » est 6C49. 6C49 est compris entre 0800 et FFFF, vous devez donc utiliser un modèle de 3 octets : 1110xxxx 10xxxxxx 10xxxxxx. L'écriture de 6C49 en binaire est : 0110 110001 001001. En utilisant ce flux binaire pour remplacer x dans le modèle à son tour, nous obtenons : 11100110 10110001 10001001, soit E6 B1 89.
Les lecteurs peuvent utiliser le Bloc-notes pour tester si notre codage est correct.
UTF-16 code UCS en unités de 16 bits. Pour les codes UCS inférieurs à 0x10000, l'encodage UTF-16 est égal à l'entier non signé de 16 bits correspondant au code UCS. Pour les codes UCS d'au moins 0x10000, un algorithme est défini. Cependant, étant donné que le BMP de l'UCS2 ou de l'UCS4 réellement utilisé doit être inférieur à 0x10000, on peut pour l'instant considérer que UTF-16 et UCS-2 sont fondamentalement identiques. Cependant, UCS-2 n'est qu'un schéma de codage et UTF-16 est utilisé pour la transmission réelle, la question de l'ordre des octets doit donc être prise en compte.
5. Ordre des octets UTF et BOM
UTF-8 utilise les octets comme unité de codage, et il n'y a pas de problème d'ordre des octets. UTF-16 utilise deux octets comme unité de codage. Avant d'interpréter un texte UTF-16, vous devez d'abord comprendre l'ordre des octets de chaque unité de codage. Par exemple, le codage Unicode de « Kui » reçu est 594E et le codage Unicode de « B » est 4E59. Si nous recevons le flux d'octets UTF-16 « 594E », s'agit-il de « Ku » ou de « B » ?
La méthode recommandée pour marquer l'ordre des octets dans la spécification Unicode est la nomenclature. La nomenclature n'est pas la liste de nomenclature de la nomenclature, mais la marque d'ordre des octets. BOM est une petite idée astucieuse :
Il existe un caractère appelé "ZERO WIDTH NO-BREAK SPACE" dans le codage UCS, et son codage est FEFF. FFFE est un caractère qui n'existe pas dans UCS, il ne devrait donc pas apparaître dans la transmission réelle. La spécification UCS recommande de transmettre les caractères "ZERO WIDTH NO-BREAK SPACE" avant de transmettre le flux d'octets.
De cette façon, si le récepteur reçoit FEFF, cela indique que le flux d'octets est Big-Endian ; s'il reçoit FFFE, cela indique que le flux d'octets est Little-Endian. C'est pourquoi le caractère "ZERO WIDTH NO-BREAK SPACE" est également appelé BOM.
UTF-8 ne nécessite pas de nomenclature pour indiquer l'ordre des octets, mais peut utiliser la nomenclature pour indiquer la méthode de codage. Le codage UTF-8 du caractère « ZERO WIDTH NO-BREAK SPACE » est EF BB BF (les lecteurs peuvent le vérifier en utilisant la méthode de codage que nous avons présentée précédemment). Ainsi, si le récepteur reçoit un flux d'octets commençant par EF BB BF, il sait qu'il est codé en UTF-8.
Windows utilise BOM pour marquer l'encodage des fichiers texte.
6. Autres documents de référence Le principal document de référence pour cet article est le « Bref aperçu de l'ISO-IEC 10646 et d'Unicode » ( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html ).
J’ai également trouvé deux informations qui semblaient intéressantes, mais comme j’avais déjà les réponses à mes questions initiales, je ne les ai pas lu :
"Comprendre Unicode Une introduction générale au standard Unicode" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a )
"Bases du codage des jeux de caractères Comprendre les codages des jeux de caractères et les codages hérités" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03 )
J'ai écrit des progiciels pour convertir UTF-8, UCS-2 et GBK les uns vers les autres, y compris des versions utilisant l'API Windows et des versions qui n'utilisent pas l'API Windows. Si j'ai le temps à l'avenir, je ferai le tri et le mettrai sur ma page d'accueil personnelle ( http://fmddlmyy.home4u.china.com ).
J'ai commencé à écrire cet article après avoir réfléchi à tous les problèmes. Je pensais pouvoir le terminer dans un moment. De façon inattendue, il a fallu beaucoup de temps pour réfléchir au libellé et vérifier les détails, et je l'ai écrit de 13h30 à 21h00. J'espère que certains lecteurs pourront en profiter.
*/
#endregion