Hoje usei script javascript para fazer uma ferramenta de menu na página ASP.NET e salvei como menuScript.js Use <script language="javascript" src="../js/MenuScript.js"></script. na página >Chamar, e um fenômeno estranho ocorreu durante a operação: os caracteres chineses na página foram exibidos normalmente, mas os caracteres chineses no menu foram exibidos como caracteres ilegíveis.
Não há necessidade de perguntar, se você pensar bem, há algo errado com a codificação. Alterne entre as codificações UTF-8 e GB2312 na opção "Visualizar"-"Codificação" da página. caracteres na página e os caracteres chineses no menu ficam alternadamente ilegíveis.
Solução: Existem configurações de codificação no arquivo de configuração: <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
Existe uma opção de codificação ao salvar o arquivo menuScript.js (você pode abrir este arquivo com o Word e salvá-lo como outro, selecione a codificação), basta manter as duas codificações iguais.
Para entender melhor o problema de codificação, encontrei um artigo sobre isso na CSDN, autor: fmddlmyy. Reimprima-o aqui para referência:
Vamos falar sobre codificação Vamos falar sobre codificação #region Vamos falar sobre codificação
/**//*
0. big endian e little endian
big endian e little endian são maneiras diferentes pelas quais a CPU lida com números multibyte. Por exemplo, a codificação Unicode do caractere "汉" é 6C49. Então, ao gravar em um arquivo, 6C deve ser escrito na frente ou 49 na frente? Se 6C estiver escrito na frente, é big endian. Ou escreva 49 na frente, que é little endian.
A palavra "endian" vem de "As Viagens de Gulliver". A guerra civil em Lilliput originou-se de quebrar os ovos da ponta grande (Big-Endian) ou da ponta pequena (Little-Endian). Como resultado, ocorreram seis rebeliões, um dos imperadores perdeu a vida e o. outro perdeu seu trono.
Geralmente traduzimos endian como "ordem de bytes", e big endian e little endian são chamados de "big end" e "little end".
1. Codificação de caracteres e código interno A propósito, os caracteres de codificação de caracteres chineses devem ser codificados antes de serem processados pelo computador. O método de codificação padrão usado pelo computador é o código interno do computador. Os primeiros computadores usavam codificação ASCII de 7 bits para processar caracteres chineses, os programadores projetaram o GB2312 para chinês simplificado e big5 para chinês tradicional.
GB2312 (1980) contém um total de 7.445 caracteres, incluindo 6.763 caracteres chineses e 682 outros símbolos. O intervalo de código interno da área de caracteres chineses é de B0-F7 no byte superior, A1-FE no byte inferior e os bits de código ocupados são 72*94=6768. Dentre elas, 5 vagas são D7FA-D7FE.
GB2312 suporta poucos caracteres chineses. A especificação de expansão de caracteres chineses GBK1.0 de 1995 inclui 21.886 símbolos, que são divididos em área de caracteres chineses e área de símbolos gráficos. A área de caracteres chineses inclui 21.003 caracteres. GB18030 em 2000 é o padrão nacional oficial que substituiu GBK1.0. Este padrão inclui 27.484 caracteres chineses, bem como tibetano, mongol, uigur e outras línguas importantes de minorias étnicas. A plataforma atual de PC deve suportar GB18030 e não há requisitos para produtos incorporados. Portanto, telefones celulares e MP3 geralmente suportam apenas GB2312.
De ASCII, GB2312, GBK a GB18030, esses métodos de codificação são compatíveis com versões anteriores, ou seja, o mesmo caractere sempre tem a mesma codificação nesses esquemas, e padrões posteriores suportam mais caracteres. Nessas codificações, o inglês e o chinês podem ser processados uniformemente. A maneira de distinguir a codificação chinesa é que o bit mais alto do byte alto não é 0. De acordo com o que os programadores os chamam, GB2312, GBK a GB18030 pertencem todos a conjuntos de caracteres de byte duplo (DBCS).
O código interno padrão de alguns Windows chineses ainda é GBK, que pode ser atualizado para GB18030 por meio do pacote de atualização GB18030. No entanto, os caracteres adicionados por GB18030 em comparação com GBK são difíceis de usar para pessoas comuns. Normalmente, ainda usamos GBK para nos referirmos ao código interno do Windows chinês.
Aqui estão mais alguns detalhes:
O texto original de GB2312 ainda é o código de área. Do código de área ao código interno, A0 precisa ser adicionado ao byte alto e ao byte baixo, respectivamente.
No DBCS, o formato de armazenamento do código interno GB é sempre big endian, ou seja, o bit de ordem superior vem primeiro.
Os bits mais altos dos dois bytes do GB2312 são ambos 1. Mas existem apenas 128*128=16384 pontos de código que atendem a essa condição. Portanto, o bit mais alto do byte inferior de GBK e GB18030 pode não ser 1. No entanto, isso não afeta a análise do fluxo de caracteres DBCS: ao ler o fluxo de caracteres DBCS, desde que um byte com um bit alto de 1 seja encontrado, os próximos dois bytes podem ser codificados como um byte duplo, independentemente do byte baixo O que é posição alta.
2. Unicode, UCS e UTF
Conforme mencionado anteriormente, os métodos de codificação de ASCII, GB2312, GBK a GB18030 são compatíveis com versões anteriores. Unicode é compatível apenas com ASCII (mais precisamente, compatível com ISO-8859-1) e não é compatível com código GB. Por exemplo, a codificação Unicode do caractere "汉" é 6C49, enquanto o código GB é BABA.
Unicode também é um método de codificação de caracteres, mas foi desenvolvido por uma organização internacional e pode acomodar esquemas de codificação para todos os idiomas do mundo. O nome científico do Unicode é "Conjunto de caracteres codificados por múltiplos octetos universais" ou, abreviadamente, UCS. UCS pode ser visto como a abreviatura de "Unicode Character Set".
De acordo com a Wikipedia ( http://zh.wikipedia.org/wiki/ ): Historicamente, houve duas organizações que tentaram projetar o Unicode de forma independente, nomeadamente a Organização Internacional para Padronização (ISO) e uma associação de fabricantes de software (unicode. organização). A ISO desenvolveu o projeto ISO 10646 e o Unicode Consortium desenvolveu o projeto Unicode.
Por volta de 1991, ambos os lados reconheceram que o mundo não precisava de dois conjuntos de caracteres incompatíveis. Então eles começaram a mesclar o trabalho de ambas as partes e a trabalhar juntos para criar uma única lista de codificação. A partir do Unicode2.0, o projeto Unicode usa as mesmas fontes e fontes da ISO 10646-1.
Ambos os projetos ainda existem e publicam seus próprios padrões de forma independente. A versão mais recente do Unicode Consortium é o Unicode 4.1.0 em 2005. O padrão ISO mais recente é 10646-3:2003.
UCS especifica como usar múltiplos bytes para representar vários textos. A forma de transmitir essas codificações é estipulada pela especificação UTF (UCS Transformation Format). As especificações comuns de UTF incluem UTF-8, UTF-7 e UTF-16.
As RFC2781 e RFC3629 da IETF descrevem os métodos de codificação de UTF-16 e UTF-8 de forma clara, nítida e rigorosa no estilo consistente da RFC. Sempre esqueço que IETF é a abreviatura de Internet Engineering Task Force. Contudo, a RFC mantida pela IETF é a base para todas as especificações na Internet.
3. UCS-2, UCS-4, BMP
O UCS vem em dois formatos: UCS-2 e UCS-4. Como o nome sugere, o UCS-2 é codificado com dois bytes e o UCS-4 é codificado com 4 bytes (na verdade, apenas 31 bits são usados, o bit mais alto deve ser 0). Vamos fazer alguns jogos matemáticos simples:
UCS-2 tem 2^16=65536 pontos de código e UCS-4 tem 2^31=2147483648 pontos de código.
UCS-4 é dividido em 2 ^ 7 = 128 grupos de acordo com o byte mais alto, sendo o bit mais alto 0. Cada grupo é dividido em 256 planos com base no próximo byte mais alto. Cada plano é dividido em 256 linhas de acordo com o terceiro byte, e cada linha contém 256 células. Obviamente, as células na mesma linha diferem apenas no último byte e o restante é igual.
O plano 0 do grupo 0 é denominado Plano Multilíngue Básico, ou BMP. Ou no UCS-4, os bits de código com os dois bytes superiores sendo 0 são chamados de BMP.
O UCS-2 é obtido removendo os dois primeiros bytes zero do BMP do UCS-4. Adicione dois bytes zero na frente dos dois bytes do UCS-2 para obter o BMP do UCS-4. Não há caracteres alocados fora do BMP na especificação UCS-4 atual.
4. Codificação UTF UTF-8 codifica UCS em unidades de 8 bits. A codificação de UCS-2 para UTF-8 é a seguinte:
Codificação UCS-2 (hexadecimal) Fluxo de bytes UTF-8 (binário)
0000-007F 0xxxxxxx
0080-07FF 110xxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
Por exemplo, a codificação Unicode do caractere "chinês" é 6C49. 6C49 está entre 0800-FFFF, portanto, você deve usar um modelo de 3 bytes: 1110xxxx 10xxxxxx 10xxxxxx. Escrever 6C49 em binário é: 0110 110001 001001. Usando esse fluxo de bits para substituir x no modelo, obtemos: 11100110 10110001 10001001, que é E6 B1 89.
Os leitores podem usar o Bloco de Notas para testar se nossa codificação está correta.
UTF-16 codifica UCS em unidades de 16 bits. Para códigos UCS menores que 0x10000, a codificação UTF-16 é igual ao número inteiro não assinado de 16 bits correspondente ao código UCS. Para códigos UCS não inferiores a 0x10000, um algoritmo é definido. Porém, como o BMP do UCS2 ou UCS4 realmente utilizado deve ser menor que 0x10000, por enquanto, pode-se considerar que UTF-16 e UCS-2 são basicamente iguais. No entanto, UCS-2 é apenas um esquema de codificação e UTF-16 é usado para transmissão real, portanto a questão da ordem dos bytes deve ser considerada.
5. Ordem de bytes UTF e BOM
UTF-8 usa bytes como unidade de codificação e não há problema de ordem de bytes. UTF-16 usa dois bytes como unidade de codificação Antes de interpretar um texto UTF-16, você deve primeiro entender a ordem dos bytes de cada unidade de codificação. Por exemplo, a codificação Unicode de "Kui" recebida é 594E e a codificação Unicode de "B" é 4E59. Se recebermos o fluxo de bytes UTF-16 "594E", será "Ku" ou "B"?
O método recomendado para marcar a ordem dos bytes na especificação Unicode é o BOM. BOM não é a lista BOM da "lista de materiais", mas sim a marca de pedido de bytes. BOM é uma ideia um pouco inteligente:
Existe um caractere chamado "ZERO WIDTH NO-BREAK SPACE" na codificação UCS e sua codificação é FEFF. FFFE é um personagem que não existe no UCS, portanto não deve aparecer na transmissão real. A especificação UCS recomenda que transmitamos os caracteres "ZERO WIDTH NO-BREAK SPACE" antes de transmitir o fluxo de bytes.
Desta forma, se o receptor receber FEFF, indica que o fluxo de bytes é Big-Endian; se receber FFFE, indica que o fluxo de bytes é Little-Endian; Portanto o caractere “ZERO WIDTH NO-BREAK SPACE” também é chamado de BOM.
UTF-8 não requer uma BOM para indicar a ordem dos bytes, mas pode usar a BOM para indicar o método de codificação. A codificação UTF-8 do caractere "ZERO WIDTH NO-BREAK SPACE" é EF BB BF (os leitores podem verificá-la usando o método de codificação que apresentamos anteriormente). Portanto, se o receptor receber um fluxo de bytes começando com EF BB BF, ele saberá que está codificado em UTF-8.
O Windows usa BOM para marcar a codificação de arquivos de texto.
6. Outros materiais de referência O principal material de referência para este artigo é "Breve visão geral da ISO-IEC 10646 e Unicode" ( http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html ).
Também encontrei duas informações que pareciam boas, mas como já tinha as respostas às minhas perguntas iniciais, não as li:
"Compreendendo o Unicode Uma introdução geral ao padrão Unicode" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a )
"Noções básicas de codificação de conjunto de caracteres Noções básicas sobre codificações de conjunto de caracteres e codificações legadas" ( http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03 )
Escrevi pacotes de software para converter UTF-8, UCS-2 e GBK entre si, incluindo versões que usam a API do Windows e versões que não usam a API do Windows. Se eu tiver tempo no futuro, irei resolver isso e colocá-lo em minha página pessoal ( http://fmddlmyy.home4u.china.com ).
Comecei a escrever este artigo depois de pensar em todas as questões e pensei que poderia terminá-lo em pouco tempo. Inesperadamente, demorou muito para considerar o texto e verificar os detalhes, e escrevi das 13h30 às 21h00. Espero que alguns leitores possam se beneficiar com isso.
*/
#endregion