Hoy, utilicé un script javascript para crear una herramienta de menú en la página ASP.NET y la guardé como menuScript.js Use <script language="javascript" src="../js/MenuScript.js"></script. en la página> Llamar, y ocurrió un fenómeno extraño durante la operación: los caracteres chinos en la página se mostraban normalmente, pero los caracteres chinos en el menú se mostraban como caracteres confusos.
No es necesario preguntar, si lo piensa de rodillas, hay algún problema con la codificación. Cambie entre las codificaciones UTF-8 y GB2312 en la opción "Ver" - "Codificación" de la página. Los caracteres de la página y los caracteres chinos del menú se vuelven confusos alternativamente.
Solución: hay configuraciones de codificación en el archivo de configuración: <globalization requestEncoding="utf-8" ResponseEncoding="utf-8" />
Hay una opción de codificación al guardar el archivo menuScript.js (puede abrir este archivo con Word y guardarlo como otro, seleccionar la codificación), simplemente mantenga las dos codificaciones iguales.
Para comprender mejor el problema de codificación, encontré un artículo sobre esto en CSDN, autor: fmddlmyy. Vuelva a imprimirlo aquí como referencia:
Hablemos de codificación Hablemos de codificación #región Hablemos de codificación
/**//*
0. big endian y little endian
big endian y little endian son formas diferentes en que la CPU maneja números multibyte. Por ejemplo, la codificación Unicode del carácter "汉" es 6C49. Entonces, al escribir en un archivo, ¿se debe escribir 6C al frente o 49 al frente? Si 6C se escribe delante, es big endian. O escribe 49 delante, que es little endian.
La palabra "endian" proviene de "Los viajes de Gulliver". La guerra civil en Lilliput se originó entre romper los huevos del extremo grande (Big-Endian) o del extremo pequeño (Little-Endian). Como resultado, se produjeron seis rebeliones, uno de los emperadores perdió la vida y el otro. Otro perdió su trono.
Generalmente traducimos endian como "orden de bytes", y big endian y little endian se denominan "extremo grande" y "extremo pequeño".
1. Codificación de caracteres y código interno. Por cierto, los caracteres de codificación de caracteres chinos deben codificarse antes de que la computadora pueda procesarlos. El método de codificación predeterminado utilizado por la computadora es el código interno de la computadora. Las primeras computadoras usaban codificación ASCII de 7 bits para procesar caracteres chinos, los programadores diseñaron GB2312 para chino simplificado y big5 para chino tradicional.
GB2312 (1980) contiene un total de 7445 caracteres, incluidos 6763 caracteres chinos y otros 682 símbolos. El rango de código interno del área de caracteres chinos es de B0-F7 en el byte alto, A1-FE en el byte bajo y los bits de código ocupados son 72*94=6768. Entre ellas, 5 vacantes son D7FA-D7FE.
GB2312 admite muy pocos caracteres chinos. La especificación de expansión de caracteres chinos GBK1.0 de 1995 incluye 21.886 símbolos, que se dividen en área de caracteres chinos y área de símbolos gráficos. El área de caracteres chinos incluye 21.003 caracteres. GB18030 en 2000 es el estándar nacional oficial que reemplazó a GBK1.0. Este estándar incluye 27.484 caracteres chinos, así como tibetano, mongol, uigur y otras lenguas de minorías étnicas importantes. La plataforma de PC actual debe ser compatible con GB18030 y no existen requisitos para productos integrados. Por lo tanto, los teléfonos móviles y MP3 generalmente solo admiten GB2312.
Desde ASCII, GB2312, GBK hasta GB18030, estos métodos de codificación son compatibles con versiones anteriores, es decir, el mismo carácter siempre tiene la misma codificación en estos esquemas y los estándares posteriores admiten más caracteres. En estas codificaciones, el inglés y el chino se pueden procesar de manera uniforme. La forma de distinguir la codificación china es que el bit más alto del byte alto no es 0. Según como los llaman los programadores, GB2312, GBK a GB18030 pertenecen todos a conjuntos de caracteres de doble byte (DBCS).
El código interno predeterminado de algunos Windows chinos sigue siendo GBK, que se puede actualizar a GB18030 mediante el paquete de actualización GB18030. Sin embargo, los caracteres agregados por GB18030 en comparación con GBK son difíciles de usar para la gente común. Por lo general, todavía usamos GBK para referirnos al código interno chino de Windows.
Aquí hay algunos detalles más:
El texto original de GB2312 sigue siendo el código de área. Desde el código de área hasta el código interno, es necesario agregar A0 al byte alto y al byte bajo, respectivamente.
En DBCS, el formato de almacenamiento del código interno de GB siempre es big endian, es decir, el bit de orden superior viene primero.
Los bits más altos de los dos bytes de GB2312 son ambos 1. Pero sólo hay 128*128=16384 puntos de código que cumplen esta condición. Por lo tanto, el bit más alto del byte bajo de GBK y GB18030 puede no ser 1. Sin embargo, esto no afecta el análisis del flujo de caracteres DBCS: al leer el flujo de caracteres DBCS, siempre que se encuentre un byte con un bit alto de 1, los dos bytes siguientes se pueden codificar como un byte doble, independientemente del byte bajo. ¿Qué es la posición alta?
2. Unicode, UCS y UTF
Como se mencionó anteriormente, los métodos de codificación de ASCII, GB2312, GBK a GB18030 son compatibles con versiones anteriores. Unicode sólo es compatible con ASCII (más precisamente, compatible con ISO-8859-1) y no es compatible con el código GB. Por ejemplo, la codificación Unicode del carácter "汉" es 6C49, mientras que el código GB es BABA.
Unicode también es un método de codificación de caracteres, pero está diseñado por una organización internacional y puede acomodar esquemas de codificación para todos los idiomas del mundo. El nombre científico de Unicode es "Conjunto universal de caracteres codificados de octetos múltiples", o UCS para abreviar. UCS puede verse como la abreviatura de "Conjunto de caracteres Unicode".
Según Wikipedia ( http://zh.wikipedia.org/wiki/ ): Históricamente, ha habido dos organizaciones que intentaron diseñar Unicode de forma independiente, a saber, la Organización Internacional de Normalización (ISO) y una asociación de fabricantes de software (unicode. org). ISO desarrolló el proyecto ISO 10646 y el Consorcio Unicode desarrolló el proyecto Unicode.
Alrededor de 1991, ambas partes reconocieron que el mundo no necesitaba dos conjuntos de caracteres incompatibles. Entonces comenzaron a fusionar el trabajo de ambas partes y trabajar juntos para crear una lista de codificación única. A partir de Unicode2.0, el proyecto Unicode utiliza las mismas fuentes y fuentes que ISO 10646-1.
Ambos proyectos todavía existen y publican sus propios estándares de forma independiente. La última versión del Consorcio Unicode es Unicode 4.1.0 en 2005. La última norma ISO es 10646-3:2003.
UCS especifica cómo utilizar varios bytes para representar varios textos. La forma de transmitir estas codificaciones está estipulada por la especificación UTF (formato de transformación UCS). Las especificaciones UTF comunes incluyen UTF-8, UTF-7 y UTF-16.
RFC2781 y RFC3629 del IETF describen los métodos de codificación de UTF-16 y UTF-8 de forma clara, nítida y rigurosa en el estilo consistente de RFC. Siempre olvido que IETF es la abreviatura de Internet Engineering Task Force. Sin embargo, el RFC mantenido por el IETF es la base de todas las especificaciones en Internet.
3. UCS-2, UCS-4, BMP
UCS viene en dos formatos: UCS-2 y UCS-4. Como sugiere el nombre, UCS-2 está codificado con dos bytes y UCS-4 está codificado con 4 bytes (en realidad, solo se utilizan 31 bits, el bit más alto debe ser 0). Hagamos algunos juegos matemáticos simples:
UCS-2 tiene 2^16=65536 puntos de código y UCS-4 tiene 2^31=2147483648 puntos de código.
UCS-4 se divide en 2^7=128 grupos según el byte más alto, siendo el bit más alto 0. Cada grupo se divide en 256 planos según el siguiente byte más alto. Cada plano se divide en 256 filas según el tercer byte y cada fila contiene 256 celdas. Por supuesto, las celdas de la misma fila solo se diferencian en el último byte y el resto son iguales.
El plano 0 del grupo 0 se denomina Plano Multilingüe Básico o BMP. O en UCS-4, los bits de código cuyos dos bytes superiores son 0 se denominan BMP.
UCS-2 se obtiene eliminando los dos primeros bytes cero del BMP de UCS-4. Agregue dos bytes cero delante de los dos bytes de UCS-2 para obtener el BMP de UCS-4. No hay caracteres asignados fuera del BMP en la especificación UCS-4 actual.
4. Codificación UTF UTF-8 codifica UCS en unidades de 8 bits. La codificación de UCS-2 a UTF-8 es la siguiente:
Codificación UCS-2 (hexadecimal) Flujo de bytes UTF-8 (binario)
0000-007F 0xxxxxxx
0080-07FF 110xxxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
Por ejemplo, la codificación Unicode del carácter "chino" es 6C49 y está entre 0800-FFFF, por lo que debe utilizar una plantilla de 3 bytes: 1110xxxx 10xxxxxx 10xxxxxx. Escribir 6C49 en binario es: 0110 110001 001001. Usando este flujo de bits para reemplazar x en la plantilla, obtenemos: 11100110 10110001 10001001, que es E6 B1 89.
Los lectores pueden utilizar el Bloc de notas para comprobar si nuestra codificación es correcta.
UTF-16 codifica UCS en unidades de 16 bits. Para códigos UCS menores que 0x10000, la codificación UTF-16 es igual al entero sin signo de 16 bits correspondiente al código UCS. Para códigos UCS no inferiores a 0x10000, se define un algoritmo. Sin embargo, dado que el BMP del UCS2 o UCS4 realmente utilizado debe ser inferior a 0x10000, por ahora se puede considerar que UTF-16 y UCS-2 son básicamente lo mismo. Sin embargo, UCS-2 es solo un esquema de codificación y UTF-16 se utiliza para la transmisión real, por lo que se debe considerar la cuestión del orden de los bytes.
5. El orden de bytes UTF y BOM
UTF-8 utilizan bytes como unidad de codificación y no hay ningún problema de orden de bytes. UTF-16 utiliza dos bytes como unidad de codificación. Antes de interpretar un texto UTF-16, primero debe comprender el orden de bytes de cada unidad de codificación. Por ejemplo, la codificación Unicode de "Kui" recibida es 594E y la codificación Unicode de "B" es 4E59. Si recibimos el flujo de bytes UTF-16 "594E", ¿es "Ku" o "B"?
El método recomendado para marcar el orden de los bytes en la especificación Unicode es la BOM. BOM no es la lista de BOM de "Lista de materiales", sino la marca de orden de bytes. BOM es una idea un poco inteligente:
Hay un carácter llamado "ESPACIO SIN INTERRUPCIÓN DE ANCHO CERO" en la codificación UCS, y su codificación es FEFF. FFFE es un carácter que no existe en UCS, por lo que no debería aparecer en la transmisión real. La especificación UCS recomienda que transmitamos los caracteres "ESPACIO SIN INTERRUPCIÓN DE ANCHO CERO" antes de transmitir el flujo de bytes.
De esta manera, si el receptor recibe FEFF, indica que el flujo de bytes es Big-Endian; si recibe FFFE, indica que el flujo de bytes es Little-Endian; Por lo tanto, el carácter "ESPACIO SIN INTERRUPCIÓN DE ANCHO CERO" también se denomina BOM.
UTF-8 no requiere una BOM para indicar el orden de los bytes, pero puede usar la BOM para indicar el método de codificación. La codificación UTF-8 del carácter "ESPACIO SIN INTERRUPCIÓN DE ANCHO CERO" es EF BB BF (los lectores pueden verificarlo utilizando el método de codificación que presentamos anteriormente). Entonces, si el receptor recibe un flujo de bytes que comienza con EF BB BF, sabrá que está codificado en UTF-8.
Windows usa BOM para marcar la codificación de archivos de texto.
6. Materiales de referencia adicionales El material de referencia principal para este artículo es "Breve descripción general de ISO-IEC 10646 y Unicode" ( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html ).
También encontré dos datos que parecían buenos, pero como ya tenía las respuestas a mis preguntas iniciales, no los leí:
"Comprensión de Unicode Una introducción general al estándar Unicode" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a )
"Conceptos básicos de codificación de juegos de caracteres Comprender las codificaciones de juegos de caracteres y las codificaciones heredadas" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03 )
He escrito paquetes de software para convertir UTF-8, UCS-2 y GBK entre sí, incluidas versiones que usan la API de Windows y versiones que no usan la API de Windows. Si tengo tiempo en el futuro, lo arreglaré y lo pondré en mi página de inicio personal ( http://fmddlmyy.home4u.china.com ).
Empecé a escribir este artículo después de pensar en todos los temas y pensé que podría terminarlo en un tiempo. Inesperadamente, me tomó mucho tiempo considerar la redacción y verificar los detalles, y lo escribí entre la 1:30 y las 9:00 de la tarde. Espero que algunos lectores puedan beneficiarse de ello.
*/
#regiónfinal