<%@LANGUAGE="VBSCRIPT" CODEPAGE="65001"%>
<!--#include file="conn.asp"-->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
¿Es correcto el código de arriba?¿Son codepage 65001 y utf-8 lo mismo?
Sí.
UTF-8 es CP65001 en Windows (que es solo una manera de especificar UTF-8 en las cosas heredadas de la página de códigos). Por lo que leí ASP puede manejar UTF-8 cuando se especifica de esa manera.
Sí, 65001 es el identificador de página de códigos de Windows para UTF-8, como se documentó on the Microsoft website. Wikipedia suggests que la página de códigos de IBM 128 y la página de códigos SAP 4110 también son indicadores de UTF-8.
Su código es correcto aunque prefiero configurar el juego de caracteres en el código en lugar de utilizar la etiqueta meta: - 65001
<% Response.CharSet = "UTF-8" %>
La página de códigos hace referencia al conjunto de caracteres UTF-8. Debería asegurarse de que su página asp (y cualquier incluida) se guarden como UTF-8 si contienen caracteres fuera del conjunto de caracteres ASCII estándar.
Al especificar el atributo CODEPAGE en el bloque <% @, indica que todo lo escrito con Response.Write debe codificarse en la página de códigos especificada, en este caso 65001 (utf-8). Vale la pena tener en cuenta que esto no afecta a ningún contenido estático que se envíe byte literal para byte a la respuesta. De ahí la razón por la cual el archivo necesita ser realmente guardado usando la página de códigos que se especifica.
La propiedad CharSet de la respuesta establece el valor CharSet del encabezado Content-Type. Esto no tiene ningún impacto sobre cómo se codifica el contenido, simplemente le dice al cliente qué codificación se está recibiendo. De nuevo, es importante que su valor coincida con la codificación real enviada.
El principal significado y efecto de '<% @ LANGUAGE =" VBSCRIPT "CODEPAGE =" 65001 "%>' es que la codificación del archivo de origen sea UTF-8 (o la que se especifique en la página de códigos). Solo se conecta en cascada a la propiedad 'Response.CharSet'. Puede guardar su archivo como UTF-8 y poner la declaración CODEPAGE correspondiente en y luego seguir usando otra codificación para 'Response.CharSet'. Como fuente en 65001 y salida en 1251 o 1252. - Ustedes lo saben de manera convincente, simplemente no pensé que fuera completamente claro en su texto, lo cual comienza implicando que podrían ser alternativas simples. – Lumi
@Lumi: no encuentro tal implicación, cito "La propiedad CharSet de la respuesta establece el valor CharSet del encabezado Content-Type. Esto no tiene impacto sobre cómo se puede codificar el contenido". Me parece bastante claro. Por cierto, el único efecto __actual__ de la directiva CODEPAGE es establecer el 'Response.CodePage', es la responsabilidad del desarrollador para garantizar que el archivo se guarde usando la página de códigos correspondiente. – AnthonyWJones
tienes razón. Confundí 'Response.CharSet' y' Response.CodePage'. Establecer la cascada de directivas CODEPAGE para este último, no para el primero; no tiene nada que ver con el encabezado 'Content-Type'. Creo que la directiva CODEPAGE se entiende mejor como "codificación de archivos fuente". [Aquí hay un ejemplo de dónde importa]. (Http://code.activestate.com/lists/activeperl/21512/) La expresión crítica es 'domXml.createElement (" Französisch ")'. El archivo estaba codificado en UTF-8 (debía ser Unicode para todos los idiomas griegos, rusos, etc.) y, por lo tanto, 'codepage = 65001' era crítico. – Lumi
response.codepage = 65001
parecen dar mal resultado cuando el archivo se guarda como física UTF-8
De lo contrario, funciona como se supone a.
¿cómo se puede arreglar esto con utf8? – toxicate20
¿De qué manera es Codepage "legacy"? – AnthonyWJones
Históricamente, los textos tenían una * página de códigos * que simplemente especificaba qué conjunto de caracteres usar. Aquellos tenían un número que difería de un proveedor a otro, Windows parece usar un entero sin signo de 16 bits para ese propósito. Hoy en día, la mayoría de las codificaciones y conjuntos de caracteres tienen * nombres * en lugar de * números *. Considero que el hecho de que UTF-8 tenga un número de página de códigos (que no se especifica en ninguna parte ni se usa fuera de Microsoft) sirve para garantizar que siga funcionando con el antiguo sistema de números de páginas de códigos enteros de 16 bits. Aunque UTF-8 no se parece en nada a una página de códigos en primer lugar. – Joey
@Johannes: el número de página de códigos sigue siendo una característica importante de cómo maneja Windows la codificación de caracteres. Por ejemplo, en .NET, la clase de Codificación solo se puede instanciar usando el número de página de códigos. No creo que Codepage sea aún "heredado". – AnthonyWJones