Nenhuma informação em qualquer lugar é tão confiável quanto a informação oficial. Hoje finalmente encontrei uma solução para o problema de codificação ASP do MSDN.
A seguir está uma passagem do MSDN.
A configuração @CODEPAGE afeta explicitamente cadeias de caracteres literais em uma única resposta. Response.CodePage afeta cadeias de caracteres dinâmicas em uma única resposta e Session.CodePage afeta cadeias de caracteres dinâmicas em todas as respostas em uma sessão.
Esta frase explica claramente as funções de @CODEPAGE, Response.CodePage e Session.CodePage respectivamente.
@CODEPAGE atua em todas as strings estáticas, como const blogname="my home" em um arquivo
Response.CodePage, Session.CodePage atua em todas as strings de saída dinâmica, como <%=blogname%>
. O ponto é que o escopo de Response.CodePage é uma resposta única, enquanto o escopo de Session.CodePage declarado em SXNA consiste em todas as respostas em uma sessão.
Veja outra frase.
Se Response.CodePage não estiver explicitamente definido em uma página, ele será definido implicitamente por Session.CodePage, se as sessões estiverem habilitadas. Se as sessões não estiverem habilitadas, Response.CodePage será definido por @CodePage, se @CodePage estiver presente na página. Se não houver @CodePage na página, Response.CodePage será definido pela propriedade da metabase AspCodePage. Se a propriedade da metabase AspCodePage não estiver definida ou definida como 0, Response.CodePage será definida pela página de código ANSI do sistema.
À primeira vista, entendi que esta frase significa o seguinte: quando as sessões estão habilitadas, se Response.CodePage não for declarado, Response.CodePage será atribuído por Session.CodePage. Se as sessões não estiverem habilitadas, se @CodePage tiver sido declarado, Response.CodePage será atribuído por @CodePage, etc.......
Esta frase explica por que depois de sair do SXNA é fácil ter caracteres ilegíveis ao inserir alguns outras páginas como oblog, z-blog, etc., porque outros programas não declaram Response.CodePage e SXNA declara Session.CodePage Portanto, assim que você insere SXNA, Session.CodePage recebe um valor imediatamente (diferente). versões, existem Algumas versões são atribuídas a 936, algumas versões são atribuídas a 65001) e, ao entrar em outros programas, Response.CodePage é imediatamente atribuído por Session.CodePage se o código de Response.CodePage for diferente daquele da própria página. , a página ficará ilegível. Portanto, quando caracteres ilegíveis apareceram ao entrar no z-blog, verifiquei se Session.CodePage e Response.CodePage eram ambos 936, e quando caracteres ilegíveis apareceram ao entrar no oblog, Session.CodePage e Response.CodePage eram ambos 65001. Ou seja,
se eu quiser garantir a superfície da folha Se não houver código distorcido, Response.CodePage deve ser declarado, caso contrário,
ele interpretará a página da web de acordo com Session.CodePage (em vez de interpretar a página da web de acordo com @codepage).
siga a explicação acima, na verdade estou muito confuso, porque todos nós É um sistema operacional chinês. Você pode tentar gerar Session.CodePage toda vez que entrar no navegador. Você pode ver que é 936! Por que ele não atribuiu o Session.CodePage 936 padrão ao Response.CodePage ao entrar no Z-blog? Em vez disso, forneça @CodePage para Response.CodePage? Sob quais circunstâncias Session.CodePage deve ser atribuído a Response.CodePage? Como devemos entender o texto original “as sessões estão habilitadas”?
Talvez as palavras acima devam ser entendidas desta forma:
quando Session.CodePage for declarado por qualquer programa, se Response.CodePage não for declarado, Response.CodePage será atribuído por Session.CodePage. Se Session.CodePage não tiver sido declarado por nenhum programa, se @CodePage tiver sido declarado, Response.CodePage receberá um valor de @CodePage..., e a parte final do conteúdo dinâmico da página será interpretada de acordo com o valor de Response.CodePage.
Como Zblog e Oblog declaram @CodePage, quando o usuário acaba de iniciar a máquina e entra no navegador para navegar no Zblog e Oblog, Response.CodePage receberá um valor de @CodePage, então a exibição da folha é normal.
Esta frase explica melhor a causa dos caracteres ilegíveis.
Se você definir Response.CodePage ou Session.CodePage explicitamente, faça isso antes de enviar strings não literais ao cliente. Se você usar strings literais e não literais na mesma página, certifique-se. a página de código de @CODEPAGE corresponde à página de código de Response.CodePage ou as sequências literais são codificadas de maneira diferente das sequências não literais e são exibidas incorretamente.
Uma das frases mais úteis é que se Response.CodePage e @CODEPAGE forem diferentes, serão gerados caracteres ilegíveis. Ou seja, quando @CODEPAGE=65001 do Z-blog e Response.CodePage do Z-blog recebem 936 por Session.CodePage, caracteres ilegíveis aparecerão e vice-versa para o oblog.
Não sei se a explicação acima é clara o suficiente -_-||
Deixe-me explicar por que o SXNA às vezes atribui Session.CodePage a 936. Tenho uma versão que escreve assim:
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
Quando o usuário entra no navegador, o padrão Session.CodePage é 936. O padrão 936 neste momento não é declarado pelo programa, portanto, não será atribuído a Response.CodePage Ao entrar no SXNA, Session.CodePage é lançado pelo acima. código. Torna-se Session.CodePage=936 declarado pelo programa, portanto, ao entrar novamente no Zblog, 936 é fornecido para Response.CodePage.
Até agora, todas as razões foram analisadas com clareza.
Portanto, o código para garantir que a folha asp não aparecerá ilegível deve ser assim: (assumindo que seja uma folha UTF-8)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response. Conjunto de caracteres ="UTF-8" %>
Explique melhor por que Response.Charset deve ser adicionado, porque o MSDN disse que deveria ser adicionado... Haha
Se a página de código estiver definida em uma página, então Response.Charset também deverá ser definido.
Além disso, o formato do arquivo de uma
página da Web deve ser igual ao @CODEPAGE usado na página.
É por isso que alguns programas como zblog e pjblog precisam salvar arquivos no formato de codificação UTF8.
Em resumo, se todos os programas declararem Response.CodePage, eles não sofrerão interferência de Session.CodePage e causarão caracteres ilegíveis. Portanto, Session.CodePage ainda não pode ser usado facilmente!
Artigo de referência: