Ninguna información en ningún lugar es tan autorizada como la información oficial. Hoy finalmente encontré una solución al problema de codificación ASP de MSDN.
El siguiente es un pasaje de MSDN.
La configuración de @CODEPAGE afecta explícitamente a las cadenas literales en una sola respuesta. Response.CodePage afecta a las cadenas dinámicas en una sola respuesta, y Session.CodePage afecta a las cadenas dinámicas en todas las respuestas de una sesión.
Esta oración explica claramente las funciones de @CODEPAGE, Response.CodePage y Session.CodePage respectivamente.
@CODEPAGE actúa sobre todas las cadenas estáticas, como const blogname="my home" en un archivo
Response.CodePage, Session.CodePage actúa sobre todas las cadenas generadas dinámicamente, como <%=blogname%>.
Esta oración es muy clave
.El punto es que el alcance de Response.CodePage es una respuesta única, mientras que el alcance de Session.CodePage declarado en SXNA son todas las respuestas en una sesión.
Mira otra frase.
Si Response.CodePage no se establece explícitamente en una página, Session.CodePage lo establece implícitamente, si las sesiones están habilitadas. Si las sesiones no están habilitadas, @CodePage establece Response.CodePage, si @CodePage está presente en la página. Si no hay @CodePage en la página, Response.CodePage se establece mediante la propiedad de la metabase AspCodePage. Si la propiedad de la metabase AspCodePage no está establecida o se establece en 0, Response.CodePage se establece mediante la página de códigos ANSI del sistema.
A primera vista, entendí que esta oración significaba esto: cuando las sesiones están habilitadas, si no se declara Response.CodePage, Session.CodePage asignará Response.CodePage. Si las sesiones no están habilitadas, si se ha declarado @CodePage, @CodePage asignará Response.CodePage, etc.
Esta oración explica por qué después de salir de SXNA es fácil tener caracteres confusos al ingresar algunos otras páginas como oblog, z-blog, etc., porque otros programas no declaran Response.CodePage y SXNA declara Session.CodePage. Por lo tanto, tan pronto como ingresa a SXNA, a Session.CodePage se le asigna un valor inmediatamente (diferente). versiones, hay algunas versiones a las que se les asigna 936, a algunas versiones se les asigna 65001), y luego, al ingresar a otros programas, Session.CodePage asigna inmediatamente Response.CodePage si el código de Response.CodePage es diferente al de la página misma. , la página quedará confusa. Entonces, cuando aparecían caracteres confusos al ingresar a z-blog, verifiqué que Session.CodePage y Response.CodePage eran ambos 936, y cuando aparecían caracteres confusos al ingresar a oblog, Session.CodePage y Response.CodePage eran ambos 65001. Es decir,
si quiero asegurar la superficie de la hoja Si no hay código confuso, se debe declarar Response.CodePage; de lo contrario,
interpretará la página web de acuerdo con Session.CodePage (en lugar de interpretar la página web de acuerdo con @codepage).
Siga la explicación anterior, en realidad estoy muy confundido, porque todos Es un sistema operativo chino. Puede intentar generar Session.CodePage cada vez que ingresa al navegador. ¡Puede ver que es 936! ¿Por qué no asignó el Session.CodePage 936 predeterminado a Response.CodePage al ingresar al Z-blog? En su lugar, dé @CodePage a Response.CodePage? ¿En qué circunstancias se debe asignar Session.CodePage a Response.CodePage? ¿Cómo debemos entender el texto original "las sesiones están habilitadas"?
Quizás las palabras anteriores deberían entenderse de esta manera:
cuando cualquier programa declara Session.CodePage, si no se declara Response.CodePage, Session.CodePage asignará Response.CodePage. Si ningún programa ha declarado Session.CodePage, si se ha declarado @CodePage, @CodePage asignará un valor a Response.CodePage..., y la parte final del contenido dinámico de la página se interpretará de acuerdo con el valor. de Response.CodePage.
Debido a que tanto Zblog como Oblog declaran @CodePage, cuando el usuario acaba de iniciar la máquina y luego ingresa al navegador para explorar Zblog y Oblog, @CodePage asignará un valor a Response.CodePage, por lo que la visualización de la hoja es normal.
Esta oración explica con más detalle la causa de los caracteres confusos.
Si configura Response.CodePage o Session.CodePage de manera explícita, hágalo antes de enviar cadenas no literales al cliente. Si usa cadenas literales y no literales en la misma página, asegúrese. la página de códigos de @CODEPAGE coincide con la página de códigos de Response.CodePage, o las cadenas literales están codificadas de manera diferente a las cadenas no literales y se muestran incorrectamente.
Una de las frases más útiles es que si Response.CodePage y @CODEPAGE son diferentes, se generarán caracteres confusos. Es decir, cuando Session.CodePage asigna 936 a @CODEPAGE=65001 de Z-blog y Response.CodePage de Z-blog, aparecerán caracteres confusos y viceversa para oblog.
No sé si la explicación anterior es lo suficientemente clara -_-||
Déjame explicarte por qué SXNA a veces asigna Session.CodePage a 936. Tengo una versión que escribe así:
<% OriginalCodePage=Session.CodePage %>
.. .....
<% Session.CodePage=OriginalCodePage %>
Cuando el usuario ingresa al navegador, Session.CodePage tiene como valor predeterminado 936. El programa no declara el 936 predeterminado en este momento, por lo que no se asignará a Response.CodePage. Al ingresar a SXNA, lo anterior descarta Session.CodePage. código Se convierte en Session.CodePage=936 declarado por el programa, por lo que al ingresar a Zblog nuevamente, se le da 936 a Response.CodePage.
Hasta ahora se han analizado claramente todos los motivos.
Por lo tanto, el código para garantizar que la hoja asp no aparezca confusa debería ser así: (suponiendo que sea una hoja UTF-8)
<%@ CODEPAGE=65001 %>
<% Response.CodePage=65001%>
<% Response. Juego de caracteres ="UTF-8" %>
Explique con más detalle por qué se debe agregar Response.Charset, porque MSDN dijo que se debe agregar... Jaja.
Si la página de códigos está configurada en una página, entonces también se debe configurar Response.Charset.
Además, el formato de archivo de una
página web debe ser el mismo que el @CODEPAGE utilizado en la página.
Es por eso que algunos programas como zblog y pjblog necesitan guardar archivos en formato de codificación UTF8.
En resumen, si todos los programas declaran Response.CodePage, Session.CodePage no interferirá en ellos y provocará caracteres confusos. ¡Así que Session.CodePage todavía no se puede usar fácilmente!
Artículo de referencia: