Recentemente, a empresa possui um projeto japonês. Como costumava usar o CMS chinês desenvolvido por si só e não separou os pacotes de idiomas, encontrou um problema de indução de dor de cabeça durante o processo de construção e depuração do site.
O motivo do código ilegal
Como o espaço de armazenamento de cada codificação de caracteres é diferente, quando caracteres diferentes são usados para ler dados, quando o espaço do caractere é muito pequeno, ele não pode ser exibido normalmente.
Por exemplo, o conjunto de caracteres de caracteres chineses é geralmente GB2312. Se você usar o UTF-8 para forçar a leitura e alterar os caracteres do GB2312, pode haver código ilegal. Como o espaço de armazenamento do conjunto de caracteres do UTF-8 é maior que o GB2312, ao ler usando o UTF-8, alguns caracteres GB2312 não existem na codificação, e os caracteres inexistentes aparecerão naturalmente. Para arquivos estáticos, se a codificação de armazenamento do arquivo for inconsistente com as configurações de codificação (charset) na página da web, o código iluminado ocorrerá devido aos motivos acima.
O exposto acima é uma análise simples do problema ilegível, que envolve o apoio do ASP para internacionalização ao resolver problemas existentes.
Três funções envolvidas: @CodePage, Response.codePage, session.codepage
Abaixo está uma passagem do MSDN.
Setting@codePageExplicticlyfectSliteralStringsinasingleSponse.Response.codepageaffectsdynamicStringsinasingLeSponse e session.CodePageAffetSdynamicsTringsinAsingLeSponse.
Todas as três funções podem definir a codificação do ASP, onde o @codePage é equivalente ao cabeçalho no PHP e deve ser emitido no início do documento.
No IIS do sistema operacional chinês, o padrão é GB2312, o valor do parâmetro é: "936" e o documento japonês precisa ser especificado comperação de código:
<%@CodePage = 932%>
Usamos esta função para definir a codificação do documento para o método de uso específico: http://www.cloudward.net/techlife/article.asp?id=490
Não deve haver problema agora, certo? Uau, o problema ainda existe. Considerando que todos os programas ASP da empresa de SEO precisam gerar páginas estáticas. As páginas geradas são todas as ANSI padrão do Windows e ainda têm códigos ilegais contendo caracteres japoneses. Dessa forma, precisamos de uma função ASP para gerar arquivos UTF-8 ou codificados por japoneses. Usamos o seguinte código para concluí -lo:
Setobjstream = server.createObject ("adodb.stream")
Sembjstream
.Abrir
.Charset = "utf-8" // codificação, aqui você pode alterá-lo para qualquer codificação
.Position = objStream.size
.WRITETEXT = pencat // pencat é os dados escritos
.Savetofilesserver.mappath ("patch/flileneame.html"), 2 // gerar caminho de arquivo
.Fechar
ENDWITH
Setobjstream = nada
O problema do código distorcido após o teste foi resolvido.