Algumas análises detalhadas da string java

Em primeiro lugar, deixe-me explicar que isso se refere a String em Java. Embora eu tenha decidido mudar para C/C++, porque encontrei um problema hoje, ainda quero dar uma olhada. A definição de String é a seguinte:

Ao depurar, você pode ver os valores salvos da seguinte forma:

Deve-se observar que se hashCode() não tiver sido chamado, o valor do hash será 0. É fácil saber que o valor aqui é a matriz de caracteres do valor real da string salva (ou seja, o "teste de string"), e qual é o valor de cada caractere? Fácil de verificar: Unicode.
Neste ponto, todos podem adivinhar como nossa subString comumente usada é implementada: Se fôssemos implementá-la, deixaríamos a nova String usar o mesmo valor (matriz de caracteres) e modificar apenas o deslocamento e a contagem. Isso economiza espaço e é rápido (não precisa copiar), e na verdade é assim:

Já que estamos discutindo strings, qual codificação a JVM usa por padrão? Através da depuração você pode encontrar:

O valor de defaultCharset pode ser passado:
-Dfile.encoding=utf-8
Faça configurações. Claro, se quiser configurá-lo como "abc", você pode, mas será definido como UTF-8 por padrão. Você pode ver o valor específico através de System.getProperty("file.encoding"). Por que você vê defaultCharset? Como o processo de transmissão da rede deve ser composto por matrizes de bytes, as matrizes de bytes obtidas por diferentes métodos de codificação podem ser diferentes. Então, precisamos saber como é obtido o método de codificação, certo? O método específico para obter a matriz de bytes é getBytes, no qual nos concentraremos a seguir. O que ele chama é o método encode de CharsetEncoder, como segue:

Obviamente, o CharsetEncoder correspondente será selecionado primeiro de acordo com o formato de codificação necessário, e o mais importante é que diferentes CharsetEncoder implementem diferentes métodos encodeLoop. Você pode não entender por que existe um for(;;) aqui? Na verdade, você pode entendê-lo aproximadamente olhando o pacote (nio) onde CharsetEncoder está localizado e seus parâmetros: esta função pode lidar com fluxos (embora não faremos loop quando a usarmos aqui).
No método encodeLoop, tantos caracteres quanto possível serão convertidos em bytes, e a nova String é quase o processo inverso acima.
No processo de desenvolvimento real, caracteres distorcidos são frequentemente encontrados:
Obtenha o nome do arquivo ao fazer upload do arquivo;
A string passada por JS para o backend;
Primeiro tente os resultados de execução do seguinte código:

A saída está descrita nos comentários do programa:
Como 2 bytes em GBK representam um caractere chinês, existem 6 bytes;
Como 3 bytes em UTF-8 representam um caractere chinês, existem 9 bytes;
Como a matriz de bytes que não pode ser gerada pelo GBK é usada para gerar uma string de acordo com as regras UTF-8, ??? é exibido;
Esta é a razão pela qual caracteres ilegíveis são frequentemente encontrados. GBK usa o byte gerado por UTF-8 para gerar strings;
Embora o código gerado acima esteja distorcido, o computador não pensa assim, então ele ainda pode obter a matriz de bytes por meio de getBytes, e o UTF-8 nesta matriz pode ser reconhecido;
Os dois últimos 63 (?) devem ser preenchidos por encode (ou não há bytes suficientes para preencher diretamente, não olhei atentamente para este local);
Como a codificação de letras e números é a mesma entre GBK e UTF-8, não haverá caracteres distorcidos no processamento desses caracteres. No entanto, a codificação de caracteres chineses é realmente diferente. no código abaixo:
new String(new String("nós".getBytes("UTF-8"), "GBK").getBytes("GBK"), "UTF-8);
Obviamente o resultado deste código é “nós”, mas o que ele faz conosco? Primeiro notamos:
new String("nós".getBytes("UTF-8"), "GBK");
O resultado desse código é um código distorcido, e muitos códigos distorcidos são "confusos assim". Mas lembre-se: o caos aqui é para nós, e para o computador, não importa se é “bagunçado” ou “não bagunçado”. Quando quase desistimos, ele ainda pode obtê-lo a partir do código ilegível através de “getBytes(”. "GBK")” É “backbone”, e então podemos usar o “backbone” para restaurar a string original.
Parece que o código acima pode resolver o problema distorcido entre "GBK" e "UTF-8", mas esta solução é limitada apenas a um caso especial: o número de todos os caracteres chineses consecutivos é um número par! As razões foram mencionadas acima e não serão repetidas aqui.
Então, como resolver esse problema?
A primeira solução: encodeURI
Por que usar este método? A razão é muito simples: GBK e UTF-8 têm a mesma codificação de%, números e letras, então a string após a codificação pode ser 100% garantida como a mesma coisa nessas duas codificações e, em seguida, decodificar para obter os caracteres . Só espeto. De acordo com o formato String, podemos adivinhar que a eficiência de codificação e decodificação é muito, muito alta, então esta também é uma boa solução.
A segunda solução: Formato de codificação unificado <BR>Estamos usando mineração Webx aqui. Você só precisa definir defaultCharset="UTF-8" em webx.xml.