solução de problema chinês jsp (versão completa)

==================================
É muito comum que caracteres ilegíveis apareçam durante o desenvolvimento de aplicativos Java. Afinal, Unicode não é amplamente usado em um sistema que usa gb2312 (incluindo gbk simplificado e big5 tradicional),

é o requisito mais básico para implementar corretamente a exibição e o chinês. armazenamento de banco de dados.

==============================
1. Primeiro, o desenvolvedor deve entender por que ele encontra código ilegível e que tipo de código ilegível ele encontra (símbolos sem sentido, uma sequência de pontos de interrogação ou qualquer outra coisa).
Os novatos geralmente ficam perdidos quando encontram um monte de caracteres confusos. A reação mais direta é abrir o Google e pesquisar por "java chinês" (essa string é frequentemente consultada em mecanismos de pesquisa)

e, em seguida, observar os caracteres de outras pessoas, um por um. uma solução. Não há nada de errado em fazer isso, mas é difícil atingir o objetivo, pelos motivos mencionados a seguir.
Resumindo, os motivos para caracteres distorcidos são muitos e as soluções são completamente diferentes. Para resolver o problema, você deve primeiro analisar seu próprio “contexto”.

============================
2. Especificamente, quais informações são necessárias para determinar a origem do código distorcido no projeto.
a. O sistema operacional usado pelo desenvolvedor
b, o nome e a versão do contêiner j2ee
c, nome do banco de dados, versão (versão exata) e versão do driver jdbc
d. Existe um código-fonte distorcido (por exemplo, ele vem do sistema ou está em uma página jsp. Se estiver em um jsp, a declaração do cabeçalho também é muito importante)

========== === =============================================
3. Como analisar inicialmente as causas dos caracteres distorcidos.
Com as informações acima, você pode basicamente postar pedindo ajuda. Acredito que se você colocar isso em fóruns como o Javaworld, os especialistas logo encontrarão soluções eficazes para você.
É claro que nem sempre você pode contar com postagens para obter ajuda, mas também deve tentar resolver o problema sozinho. Como começar?
a. Analise qual é a codificação do seu "código distorcido". Na verdade, isso não é difícil, por exemplo
System.out.println(testString);
Há código ilegível neste parágrafo, então você também pode usar o método exaustivo para adivinhar seu formato de codificação real.
System.out.println(new String(testString.getBytes(”ISO-8859-1″),,”gb2312″));
System.out.println(new String(testString.getBytes(”UTF8″),”gb2312″));
System.out.println(new String(testString.getBytes(”GB2312″),,”gb2312″));
System.out.println(new String(testString.getBytes("GBK"),"gb2312"));
System.out.println(new String(testString.getBytes("BIG5"),"gb2312"));
Espere, o código acima significa usar o formato de codificação especificado para ler o "código ilegível" de testString e convertê-lo em gb2312 (apenas chinês é usado como exemplo aqui)
Aí você vê qual resultado convertido está ok, é isso. . .

b. Se você conseguir obter o chinês correto usando as etapas acima, significa que seus dados definitivamente estão lá, mas não são exibidos corretamente na interface. Então o segundo passo é corrigir sua parte de visualização

. O que geralmente precisa ser verificado é se a codificação correta da página está selecionada no jsp.

Gostaria de salientar algo que tem sido mal compreendido por muitas pessoas, que é a diretiva <%@ page contentType="text/html; charset=GB2312″ %> e <META http-equiv=Content-Type

content="text /html; charset= gb2312″>A diferença entre os dois. Normalmente, quando muitos artigos na Internet mencionam problemas chineses, eles dizem que a escolha do armazenamento unicode ou gb2312 no banco de dados pode ser resolvida

usando

Mas acho que essa afirmação é muito irresponsável e me fez passar muito tempo deprimido com códigos distorcidos que, para começo de conversa, nem existiam. Na verdade, o papel da página

é fornecer um método de codificação para Java "ler" a String na expressão durante o processo de JSP sendo compilado em HTML (um pouco semelhante ao papel da terceira instrução acima), e o

papel de meta é bem conhecido Fornece opções de codificação para navegadores IE, que são usadas para "exibir" os dados finais. Mas nunca vi ninguém me lembrar disso. Sempre usei a página como meta,

o que resultou nos dados que eram originalmente iso-8859 sendo lidos como gb2312 pelo comando page, então ficaram distorcidos, então adicionei uma codificação. função de conversão para converter todos os dados da string. Todos mudaram de iso8859 para gb2312 (

por que

================================================= =============
4. Qual codificação é melhor para o banco de dados?
Os bancos de dados atualmente populares incluem principalmente sql server, mysql, oracle, DB2, etc. Entre eles, o mysql é o líder entre os bancos de dados gratuitos. Seu desempenho e funções são relativamente convenientes de instalar e configurar, e o driver

correspondente

. Então pegue o mysql como exemplo.

Eu pessoalmente recomendo usar a codificação padrão do mysql para armazenamento, que é iso-8859-1 (correspondente a latin-1 nas opções do mysql). Existem vários motivos principais. Primeiro, iso-8859-1 tem um bom suporte para

chinês

A estabilidade também é melhor, porque o suporte multi-codificação

é fornecido por produtos de banco de dados específicos, sem mencionar a incompatibilidade com outros bancos de dados, mesmo versões diferentes deles podem ter problemas de compatibilidade.

Por exemplo, em produtos anteriores ao mysql 4.0, muitas soluções chinesas usam o campo characterEncoding na conexão para definir a codificação, como gb2312 ou algo assim. Isso está OK

porque os dados originais são codificados em ISO8859_1 e o driver jdbc usará o especificado. no url. O conjunto de caracteres é usado para codificação e resultSet.getString(*) remove a

string codificada. Desta forma, você pode obter diretamente os dados do gb2312.

No entanto, o lançamento do mysql 4.1 trouxe muitos problemas para muitos administradores de banco de dados, porque o mysql 4.1 suporta o conjunto de caracteres no nível da coluna. Cada tabela e coluna pode especificar a codificação

. Se não for especificado, será ISO8895_1, portanto, após o jdbc retirar o. dados, será baseado na coluna O conjunto de caracteres é usado para codificação, em vez de usar um parâmetro global para obter todos os dados.

Isso também mostra por outro aspecto que o problema dos caracteres distorcidos é realmente complicado e tem muitos motivos. Apenas forneço algumas soluções para a situação real que encontrei. Se houver algum

erro

Somente para uso interno.
Qualquer dúvida, consulte [email protected]
================================================= ==============

Finalmente encontrei a solução mais perfeita para o problema chinês. . . Obrigado ao autor deste artigo online. . .
Meu artigo original é baseado em minha própria experiência. Embora não houvesse nada de errado, a causa raiz final do problema nunca foi encontrada. Depois de ler este artigo, de repente percebi, haha,
—————————————————————————————————————————————————————————————————— ——————-

Como o problema chinês na programação Java é um problema comum, depois de ler muitas soluções para problemas Java chineses, combinados com a prática de programação do autor, descobri que muitos dos métodos discutidos no passado não podem explicar claramente o problema e resolver o problema, especialmente o problema chinês quando multiplataforma.
Então dei este artigo, que inclui minha análise e sugestões de soluções para problemas chineses em classes, Servelets, classes JSP e EJB rodando no console. Espero que você possa me dar alguns conselhos.

Resumo: Este artigo analisa profundamente o processo de codificação/decodificação de arquivos de origem Java pelo compilador Java e arquivos de classe pela JVM na programação Java. Por fim, a causa raiz dos problemas chineses na programação Java é revelada. dado O método ideal proposto para resolver problemas Java Chineses.

1. A origem do problema chinês

A codificação suportada pelo sistema operacional original do computador era a codificação de caracteres de byte único. Portanto, todos os programas de processamento no computador foram inicialmente processados ​​em inglês com codificação de byte único.

Com o desenvolvimento dos computadores, para se adaptarem às línguas de outras nações do mundo (incluindo, claro, os nossos caracteres chineses), as pessoas propuseram a codificação UNICODE, que utiliza codificação de byte duplo e é compatível com caracteres ingleses. e codificações de caracteres de byte duplo de outras nações. Portanto, atualmente, a maioria dos softwares internacionais usa a codificação UNICODE internamente. Quando o software está em execução, ele obtém o formato de codificação suportado por padrão pelo sistema de suporte local (na maioria das vezes, o sistema operacional). ) e, em seguida, converte o UNICODE dentro do software no formato de codificação suportado pelo sistema local por padrão. O formato é exibido.

Este é o caso do JDK e JVM do Java. O JDK de que estou falando aqui se refere à versão internacional do JDK. Nossos caracteres chineses são uma linguagem de codificação de byte duplo. Para permitir que os computadores processem chinês, desenvolvemos nossos próprios padrões, como gb2312, GBK e GBK2K, para atender às necessidades de processamento do computador.

Portanto, para se adaptar às nossas necessidades de processamento de chinês, a maioria dos sistemas operacionais possui sistemas operacionais chineses personalizados. Eles usam formatos de codificação GBK e GB2312 para exibir corretamente nossos caracteres chineses. Por exemplo: O Windows chinês usa codificação GBK para exibição por padrão Ao salvar arquivos no Windows 2000 chinês, o formato de codificação usado por padrão para salvar arquivos também é GBK. codificação por padrão Nota: GBK é expandido com base em GB2312.

Como a linguagem Java usa codificação UNICODE internamente, quando o programa Java está em execução, há um problema de conversão de entrada e saída da codificação UNICODE e do formato de codificação correspondente suportado pelo sistema operacional e pelo navegador. Se houver um erro em qualquer uma das etapas, os caracteres chineses exibidos ficarão distorcidos. Este é o nosso problema comum em Java Chinês.

Ao mesmo tempo, Java é uma linguagem de programação multiplataforma, o que significa que os programas que escrevemos podem ser executados não apenas em janelas chinesas, mas também em Linux chinês e outros sistemas. muitas vezes vemos alguém transplantar um programa Java escrito no Windows 2000 chinês para rodar no Linux inglês). Esta operação de transplante também trará problemas aos chineses.

Além disso, algumas pessoas usam sistemas operacionais e navegadores em inglês, como o IE, para executar programas com caracteres chineses e navegar em páginas da web em chinês. Eles próprios não oferecem suporte ao chinês e também causarão problemas em chinês.

Quase todos os navegadores passam parâmetros no formato de codificação UTF-8 por padrão, em vez da codificação chinesa. Portanto, também haverá problemas ao passar parâmetros chineses, resultando em caracteres ilegíveis.

Resumindo, os aspectos acima são as principais fontes de problemas chineses em Java. Chamamos os problemas causados ​​​​pelo não funcionamento correto do programa pelos motivos acima: problemas chineses em Java.

2. Processo detalhado de conversão de codificação Java.

Nossos programas Java comuns incluem as seguintes categorias:

*Classes que são executadas diretamente no console (incluindo classes de interface visual)

*Classes de código JSP (Nota: JSP é uma variante da classe Servlets)

*Servelets

classe

* classe EJB

* outras classes de suporte que não podem ser executadas diretamente

Esses arquivos de classe podem conter strings chinesas, e geralmente usamos os três primeiros tipos de programas Java para interagir diretamente com os usuários para caracteres de saída e entrada, como: usamos JSP. e o Servlet obtém os caracteres enviados pelo cliente, e esses caracteres também incluem caracteres chineses. Independentemente da função dessas classes Java, o ciclo de vida desses programas Java é assim:

*Os programadores escolhem um software de edição adequado em um determinado sistema operacional para implementar o código-fonte do programa e salvá-lo no sistema operacional com a extensão .Java , por exemplo, usamos o Bloco de notas para editar um programa de origem Java no Windows 2000 chinês.

*Os programadores usam Javac.exe no JDK para compilar esses códigos-fonte para formar classes .class (os arquivos JSP são compilados pelo contêiner que chama o JDK).

*Execute essas classes diretamente ou implante-as no contêiner WEB para executar e gerar os resultados.

Então, durante esses processos, como o JDK e a JVM codificam, decodificam e executam esses arquivos?

Aqui, tomamos o sistema operacional chinês Windows 2000 como exemplo para ilustrar como as classes Java são codificadas e decodificadas.

A primeira etapa é usar um software de edição como o Bloco de Notas para escrever um arquivo de programa de origem Java (incluindo os cinco tipos de programas Java acima) no Windows 2000 chinês. Ao salvar o arquivo do programa, o arquivo do programa usa o formato de codificação GBK suportado pelo sistema operacional por padrão (suportado pelo sistema operacional por padrão). O formato é o formato file.encoding) formando um arquivo .Java, ou seja, antes de o programa Java ser compilado, nosso arquivo de programa fonte Java é salvo no arquivo .encoding. formato de codificação suportado pelo sistema operacional por padrão No programa de origem Java Contém caracteres de informação em chinês e códigos de programa em inglês para visualizar o parâmetro file.encoding do sistema, você pode usar o seguinte código:

public class ShowSystemDefaultEncoding;
{
público estático void principal(String[] args)
{
Codificação de string =
System.getProperty("arquivo.codificação");
System.out.println(codificação);
}
}

Na segunda etapa, usamos o arquivo Javac.exe do JDK para compilar nosso programa fonte Java. Como o JDK é uma versão internacional, ao compilar, se não usarmos o parâmetro -encoding para especificar o formato de codificação de nossa fonte Java. programa, então Javac.exe primeiro obtém o formato de codificação usado por nosso sistema operacional por padrão. Ou seja, ao compilar um programa Java, se não especificarmos o formato de codificação do arquivo do programa de origem, o JDK primeiro obtém o parâmetro file.encoding. do sistema operacional (que salva o formato de codificação padrão, como Windows2000, seu valor é GBK) e, em seguida, o JDK converte nosso programa de origem Java do formato de codificação file.encoding para o formato UNICODE padrão interno do Java e o coloca na memória.

Em seguida, Javac compila o arquivo de formato Unicode convertido em um arquivo de classe .class. Neste momento, o arquivo .class é codificado em UNICODE e é temporariamente colocado na memória. é salvo em nosso sistema operacional para formar o arquivo .class que vemos.

Para nós, o arquivo .class que finalmente obtivemos é um arquivo de classe cujo conteúdo é salvo no formato de codificação UNICODE. Ele contém a string chinesa em nosso programa de origem, mas neste momento foi convertido para o formato UNICODE por meio do formato file.encoding. .

Nesta etapa, o arquivo do programa de origem JSP é diferente. Para JSP, o processo é assim: ou seja, o contêiner WEB chama o compilador JSP. O compilador JSP primeiro verifica se o formato de codificação do arquivo está definido no arquivo JSP. não há formato de codificação de arquivo no arquivo JSP. Para definir o formato de codificação do arquivo JSP, o compilador JSP chama JDK para primeiro converter o arquivo JSP em uma classe Servlet temporária usando o formato de codificação de caracteres padrão da JVM (ou seja, o padrão arquivo.encoding do sistema operacional onde o contêiner WEB está localizado) e então é compilado em uma classe de formato UNICODE e salvo em uma pasta temporária.

Por exemplo: No Windows 2000 chinês, o contêiner WEB converte o arquivo JSP do formato de codificação GBK para o formato UNICODE e, em seguida, compila-o em uma classe Servlet salva temporariamente para responder à solicitação do usuário.

A terceira etapa é executar a classe compilada na segunda etapa, que é dividida em três situações:
A. Classes executadas diretamente no console

B. Classes EJB e classes de suporte que não podem ser executadas diretamente (como classes JavaBean)

C. Código JSP e classes Servlet

D. Entre programas Java e bancos de dados

Vejamos essas quatro situações abaixo.

R. No caso de uma classe executada diretamente no console

, a execução dessa classe requer primeiro suporte JVM, ou seja, o JRE deve estar instalado no sistema operacional. O processo de execução é assim: Primeiro, Java inicia a JVM. Neste momento, a JVM lê o arquivo de classe salvo no sistema operacional e lê o conteúdo na memória. e então a JVM a executa. Se neste momento Se esta classe precisar receber entrada do usuário, a classe usará o formato de codificação file.encoding por padrão para codificar a string inserida pelo usuário e convertê-la em unicode e salvá-la na memória. (o usuário pode definir o formato de codificação do fluxo de entrada).

Após a execução do programa, a string gerada (codificada em UNICODE) é retornada à JVM. Finalmente, o JRE converte a string no formato file.encoding (o usuário pode definir o formato de codificação do fluxo de saída) e a passa para o sistema operacional. interface de exibição e envia-o para a interface. Cada uma das etapas de conversão acima requer a conversão correta do formato de codificação para que caracteres ilegíveis não apareçam no final. B. Classes EJB e classes de suporte que não podem ser executadas diretamente (como classes JavaBean)

. Como as classes EJB e classes de suporte não podem ser executadas diretamente, elas geralmente não interagem diretamente com os usuários para entrada e saída. para entrada e saída, portanto, após serem compilados na segunda etapa, eles formam uma classe cujo conteúdo é codificação UNICODE e são salvos no sistema operacional, desde que não haja interação entre ela e outras classes. perdido durante o processo de passagem de parâmetros, ele será executado corretamente.

C.

Após a segunda etapa do código JSP e da classe Servlet, o arquivo JSP também é convertido em um arquivo de classe Servlets, mas não existe no diretório de classes como os Servlets padrão. Ele existe no diretório temporário do contêiner WEB. , então nesta etapa também o veremos como Servlets.

Para Servlets, quando o cliente solicita, o contêiner WEB chama sua JVM para executar o Servlet. Primeiro, a JVM lê a classe Servlet do sistema e a carrega na memória. UNICODE Então a JVM executa a classe Servlet na memória. Se o Servlet estiver em execução, ele precisa aceitar caracteres do cliente, como os valores inseridos no formulário e os valores passados ​​​​na URL. tempo, se o programa não estiver configurado para aceitar Se o formato de codificação for usado como parâmetro, o contêiner WEB usará o formato de codificação ISO-8859-1 por padrão para aceitar o valor recebido e convertê-lo para o formato UNICODE na JVM e salve-o na memória do contêiner WEB.

Depois que o Servlet é executado, ele gera saída, e a string de saída está no formato UNICODE. Em seguida, o contêiner envia diretamente a string de formato UNICODE (como sintaxe HTML, string de saída do usuário, etc.) gerada pela execução do Servlet para o cliente. navegador e envia-o para Se o usuário especificar o formato de codificação para saída ao enviar neste momento, ele será enviado para o navegador no formato de codificação especificado. Se não for especificado, será enviado para o navegador do cliente em ISO-8859-. 1 codificação por padrão.

D. Entre o programa Java e o banco de dados

Para quase todos os drivers JDBC de banco de dados, o formato de codificação padrão para transferência de dados entre o programa Java e o banco de dados é ISO-8859-1. Portanto, nosso programa está transmitindo dados para o banco de dados ao armazenar dados contendo chinês. o programa, JDBC primeiro converte os dados no formato de codificação UNICODE dentro do programa para o formato ISO-8859-1 e, em seguida, passa-os para o banco de dados. Quando o banco de dados salva os dados, o padrão é salvar ISO-8859-1. então é por isso que os dados chineses que frequentemente lemos no banco de dados estão distorcidos.

3. Vários princípios que devem ser entendidos ao analisar problemas comuns de Java Chinês

. Primeiro, após a análise detalhada acima, podemos ver claramente que no ciclo de vida de qualquer programa Java, o processo chave de conversão de codificação é: inicialmente compilado em uma classe. arquivo A transcodificação e a saída final do processo de transcodificação para o usuário.

Em segundo lugar, devemos entender que os seguintes formatos de codificação comumente usados ​​e suportados por Java em tempo de compilação são:

*ISO-8859-1, 8 bits, o mesmo que 8859_1, ISO-8859-1, ISO_8859_1 e outras codificações

*Cp1252, American Codificação em inglês, igual à codificação padrão ANSI

*UTF-8, igual à codificação unicode

*GB2312, igual a gb2312-80, gb2312-1980 e outras codificações

*GBK, igual a MS936, é uma expansão de gb2312 e outras codificações, como coreano, japonês, chinês tradicional, etc. Ao mesmo tempo, devemos prestar atenção à relação de compatibilidade entre essas codificações da seguinte forma:

as codificações Unicode e UTF-8 têm uma correspondência um-para-um. GB2312 pode ser considerado um subconjunto de GBK, ou seja, a codificação GBK é expandida em gb2312. Ao mesmo tempo, a codificação GBK contém 20.902 caracteres chineses e o intervalo de codificação é: 0×8140-0xfefe Todos os caracteres podem ser mapeados para UNICODE2.0 um para um.

Em terceiro lugar, para o arquivo de programa fonte .Java colocado no sistema operacional, durante a compilação, podemos especificar o formato de codificação de seu conteúdo, especificamente usando -encoding. Nota: Se o programa de origem contiver caracteres chineses e você usar -encoding para especificar outros caracteres de codificação, obviamente ocorrerá um erro.

Use -encoding para especificar o método de codificação do arquivo de origem como GBK ou gb2312. Não importa em qual sistema compilamos o programa de origem Java contendo caracteres chineses, ele converterá corretamente o chinês em UNICODE e o armazenará no. arquivo de classe.

Então, devemos deixar claro que o formato de codificação de caracteres padrão de quase todos os contêineres WEB usa ISO-8859-1 como valor padrão. Ao mesmo tempo, quase todos os navegadores usam UTF-8 por padrão ao passar parâmetros. .

Portanto, embora nosso arquivo fonte Java especifique o método de codificação correto na entrada e na saída, ele ainda é processado como ISO-8859-1 quando executado dentro do contêiner.

4. Classificação dos problemas chineses e suas soluções ótimas recomendadas

Depois de compreender os princípios acima do processamento de arquivos Java, podemos apresentar um conjunto de sugestões de soluções ótimas para problemas de caracteres chineses. Nosso objetivo é: os programas de origem Java contendo strings chinesas ou processamento chinês que editamos no sistema chinês podem ser migrados para qualquer outro sistema operacional para serem executados corretamente após a compilação, ou podem ser compilados em outros sistemas operacionais. passar parâmetros em chinês e inglês e pode comunicar corretamente strings em chinês e inglês com o banco de dados. Nossa ideia específica é restringir o método de codificação para torná-lo correto na entrada e saída da transcodificação do programa Java e onde o programa Java possui conversão de entrada e saída com o usuário.

As soluções específicas são as seguintes:

1. Para classes que rodam diretamente no console

, neste caso, recomendamos que ao escrever um programa, se você precisar receber entrada do usuário que possa conter chinês ou saída que possa conter chinês, o programa deve usar Fluxos de caracteres são usados ​​para manipular entrada e saída Especificamente, os seguintes tipos de fluxo de nós orientados a caracteres são aplicados:

Para arquivos: FileReader, FileWrieter,

seus tipos de fluxo de nós orientados a bytes são: FileInputStream, FileOutputStream

Para memória (matriz. ): CharArrayReader,

CharArrayWriter Os tipos de fluxo de nó são: ByteArrayInputStream, ByteArrayOutputStream

Memória

(string): StringReader, StringWriter

Pipes

: PipedReader, PipedWriter.

fluxos de processamento orientados devem ser usados:

BufferedWriter, BufferedReader,

seus fluxos de processamento do tipo byte são: BufferedInputeStream, BufferedOutputStream

InputStreamReader, OutputStreamWriter,

seus fluxos de processamento do tipo byte são: DataInputStream, DataOutputStream

e InputStreamWriter

fluxo de bytes de acordo com o conjunto de codificação de caracteres especificado. Converta em um fluxo de caracteres, como:

InputStreamReader in = new InputStreamReader(System.in, "GB2312"); exemplo: o seguinte exemplo de codificação Java pode atender aos requisitos:

//Read.Java
importar Java.io.*;
classe pública Ler
{
público estático void principal(String[] args)
lançaIOException
{
Stringstr =
"nTeste chinês, esta é a string interna codificada "+"ntest caractere inglês";
String string = "";
BufferedReader stdin=
novo BufferedReader(novo
InputStreamReader(System.in,”gb2312″));
//Define a interface de entrada para ser codificada em chinês
BufferedWriter saída padrão =
novo BufferedWriter(novo
OutputStreamWriter(System.out,”gb2312″));
//Define a interface de saída para ser codificada em chinês
stdout.write("Por favor, digite:");
stdout.flush();
strin = stdin.readLine();
stdout.write("Esta é a string inserida pelo usuário:"+strin);
stdout.write(str);
stdout.flush();
}}

Ao mesmo tempo, ao compilar o programa, usamos o seguinte método:

Javac -encoding gb2312 Read.Java

2. Para classes EJB e classes de suporte que não podem ser executadas diretamente (como a classe JavaBean),

porque essas próprias classes são usados ​​​​por outras classes A chamada não interage diretamente com o usuário, portanto, para esse tipo, nosso método de processamento recomendado é que o programa interno use fluxos de caracteres para processar as strings chinesas dentro do programa (especificamente como na seção acima), e ao mesmo tempo, ao compilar a classe, use o parâmetro -encoding gb2312 para indicar que o arquivo de origem está codificado no formato chinês.

3. Para a classe Servlet

, recomendamos o seguinte método:

Ao compilar o programa de origem da classe Servlet, use -encoding para especificar a codificação como GBK ou GB2312 e use o setContentType("texto" do objeto de resposta na codificação parte ao enviar para o usuário /html;charset=GBK”); ou gb2312 para definir o formato de codificação de saída. Da mesma forma, ao receber a entrada do usuário, usamos request.setCharacterEncoding(”GB2312″); nossa classe de servlet é transplantada para, apenas o cliente. Se o seu navegador suportar exibição em chinês, ele será exibido corretamente. Aqui está um exemplo correto:

//HelloWorld.Java
pacote olá;
importar Java.io.*;
importar Javax.servlet.*;
importar Javax.servlet.http.*;
classe pública HelloWorld
estende HttpServlet
{
inicialização pública nula()
lança ServletException
{
}
public void doGet
(solicitação HttpServletRequest,
Resposta HttpServletResponse)
lança IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Definir formato de codificação de entrada
resposta.setContentType
("texto/html;charset=GB2312");
//Define o formato de codificação de saída
PrintWriter out = resposta.getWriter();
//É recomendado usar a saída do PrintWriter
out.println(”<hr>”);
out.println("Olá mundo!
Isto é criado por Servlet!Test Chinese!");
out.println(”<hr>”);
}
public void doPost(solicitação HttpServletRequest,
Resposta HttpServletResponse)
lança IOException, ServletException
{
request.setCharacterEncoding("GB2312");
//Definir formato de codificação de entrada
resposta.setContentType
("texto/html;charset=GB2312");
//Define o formato de codificação de saída
String nome = request.getParameter("nome");
String id = request.getParameter("id");
if(nome==nulo) nome="";
if(id==nulo) id="";
PrintWriter out = resposta.getWriter();
//É recomendado usar a saída do PrintWriter
out.println(”<hr>”);
out.println("A string chinesa que você passou é: " + nome);
out.println("<hr>O id que você digitou é: " + id);
out.println(”<hr>”);
}
destruição de vazio público ()
{
}
}

Use a codificação Javac gb2312 HelloWorld.Java para compilar este programa.

O programa para testar este Servlet é o seguinte:

< %@page contentType="text/html;
conjunto de caracteres=gb2312″%>
<%request.setCharacterEncoding("GB2312");%>
<html><head><title></title>
<linguagem script="JavaScript">
função Enviar()
{
//Passa o valor da string chinesa para o Servlet através da URL
documento.base.action=
"./HelloWorld?name=中文";
document.base.method = “POST”;
document.base.submit();
}
</Script>
</head>

<body bgcolor=”#FFFFFF”
text=”#000000″ margem superior=”5″>
<nome do formulário = "método base" =
“POST” alvo=”_self”>
<input nome="id" tipo="texto"
valor=”” tamanho=”30″>
<a href = “JavaScript:Enviar()">
Passe para Servlet</a>
</form></body></html>

4.

Para evitar dados distorcidos na transferência de dados entre o programa Java e o banco de dados, recomendamos os seguintes métodos ideais para lidar com eles:

1. O programa Java deve ser processado de acordo com o método especificado por nós.

2. Altere o formato de codificação suportado pelo banco de dados por padrão para GBK ou GB2312.

Por exemplo: no mysql, podemos adicionar a seguinte instrução ao arquivo de configuração my.ini para conseguir isso:

default-character-set=gbk

na área [mysqld]

e adicione:

[client]
default-character-set=gbk

No SQL Server2K, podemos definir o idioma padrão do banco de dados para chinês simplificado para atingir esse objetivo.

5. Para código JSP,

como JSP é compilado dinamicamente pelo contêiner WEB em tempo de execução, se não especificarmos o formato de codificação do arquivo de origem JSP, o compilador JSP obterá o valor file.encoding do sistema operacional do servidor para compilar o Arquivo JSP. Sim, é mais provável que cause problemas durante o transplante. Por exemplo, um arquivo jsp que pode funcionar bem no Windows 2000 chinês não funcionará no Linux inglês, mesmo que os clientes sejam os mesmos. o arquivo JSP ao compilá-lo Causado por diferentes codificações de sistemas operacionais (file.encoding em chinês wink é diferente de file.encoding em inglês Linux, e file.encoding em inglês Linux não suporta chinês, então haverá problemas com o. classe JSP compilada).

A maioria dos problemas discutidos na Internet são desse tipo, principalmente porque o arquivo JSP não pode ser exibido corretamente quando transplantado para a plataforma. Para esse tipo de problema, entendemos o princípio da conversão da codificação do programa em Java, e é muito mais fácil de fazer. resolva isso. Nossas soluções sugeridas são as seguintes:

1. Devemos garantir que o JSP seja enviado em codificação chinesa quando enviado para o cliente, ou seja, não importa o que aconteça, primeiro adicionamos a seguinte linha ao nosso código-fonte JSP:

< %@page contentType =”texto/html;
charset = gb2312 ″%>

2. Para permitir que o JSP obtenha corretamente os parâmetros de entrada, adicionamos a seguinte frase ao cabeçalho do arquivo de origem JSP:

<%request.Setcharacterencoding (”GB2312 ″);
%>

3. Para que o compilador JSP decodifique corretamente nossos arquivos JSP contendo caracteres chineses, precisamos especificar o formato de codificação de nossos arquivos de origem JSP nos arquivos de origem JSP. Arquivos de origem no cabeçalho do arquivo de origem JSP

.
Ou < %@página páginancoding = "gbk" %>

Esta é uma instrução recém -adicionada na especificação JSP 2.0.

Recomendamos usar este método para resolver problemas chineses nos arquivos JSP

.
< %@página páginancoding = "gb2312 ″ %>
< %@página contentType = "text/html;
charset = gb2312 ″%>
<%request.SetcharAcTerEncoding ("GB2312");
%>
<%
String action = request.getParameter ("ação");
String name = "";
String str = "";
if (ação! = null && action.equals ("enviado"))
{
nome = request.getParameter ("nome");
str = request.getParameter ("str");
}
%>
<html>
<cabeça>
<título></título>
<Script Language = "JavaScript">
função submeter ()
{
document.base.action =
"? Ação = enviado e str = chinês";
document.base.method = "post";
document.base.submit ();
}
</Script>
</head>
<corpo bgcolor = ”#ffffff”
texto = ”#000000 ″ TopMargin =” 5 ″>
<form name = "base" método =
“Post” Target = ”_ Self”>
<input type = "text" name = "name"
value = ”” size = ”30 ″>
<a href = “javascript: submmit ()"> envie </a>
</form>
<%
if (ação! = null && action.equals ("enviado"))
{
out.println ("<br> Os personagens que você inseriu são:"+nome);
out.println ("<br> Os personagens que você passou pelo URL são:"+str);
}
%>
</body>
</html>