español codificacion codepage encoding character-encoding lamp php-5.4

encoding - codificacion - ¿Cuál es la diferencia exacta entre Windows-1252(1/3/4) e ISO-8859-1?



windows 1252 vs iso 8859 1 (4)

8859-1 y 1252

http://www.w3schools.com/charsets/ref_html_ansi.asp

ANSI (Windows-1252) ANSI fue el conjunto de caracteres predeterminado en Windows hasta Windows 95.

ANSI también se llama Windows-1252.

Nota importante ANSI y ISO-8859-1 son muy similares. Sólo difieren en 32 caracteres.

En ANSI, los caracteres de 128 a 159 se utilizan para algunos caracteres útiles, como el símbolo del euro.

En ISO-8859-1, estos caracteres se asignan a caracteres de control que son inútiles en HTML.

__ por lo tanto, una sugerencia para ver si 128 es el símbolo del euro ... si es ANSI / windows 1252. __

Haga clic en la siguiente referencia da este enlace.

http://www.w3schools.com/charsets/ref_html_8859.asp

Los códigos de 128 a 159 no están en uso en ISO-8859-1, pero muchos navegadores mostrarán los caracteres del conjunto de caracteres ANSI (Windows-1252) en lugar de nada.

Esos 2 enlaces los enumeran a ambos.

Estamos alojando aplicaciones PHP en una instalación LAMP basada en Debian. Todo está bastante bien, en cuanto a rendimiento, administración y gestión. Sin embargo, al ser un desarrollador algo nuevo (todavía estamos en la escuela secundaria), nos hemos encontrado con algunos problemas con la codificación de caracteres para Western Charsets.

Después de hacer muchas investigaciones, llegué a la conclusión de que la información en línea es algo confusa. Se trata de que Windows-1252 sea ANSI y totalmente compatible con ISO-8859-1.

De todos modos, ¿cuál es la diferencia entre Windows-1252 (1/3/4) e ISO-8859-1? ¿Y de dónde viene ANSI en esto de todos modos?

¿Qué codificación debemos usar en nuestros servidores Debian (y estaciones de trabajo) para asegurarnos de que los clientes obtengan toda la información de la manera prevista y que no perdamos ningún carácter en el camino?

Esta tabla da una visión general sobre las diferencias. Muestra todos los caracteres que están definidos en Windows-1252 pero no están disponibles en ISO-8859-1 / ISO-8859-15:

│ …0 │ …1 │ …2 │ …3 │ …4 │ …5 │ …6 │ …7 │ …8 │ …9 │ …A │ …B │ …C │ …D │ …E │ …F │ ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 8… │ € │ │ ‚ │ ƒ │ „ │ … │ † │ ‡ │ ˆ │ ‰ │ Š │ ‹ │ Œ │ │ Ž │ │ Unicode │ 20AC │ │ 201A │ 0192 │ 201E │ 2026 │ 2020 │ 2021 │ 02C6 │ 2030 │ 0160 │ 2039 │ 0152 │ │ 017D │ │ ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── 9… │ │ ‘ │ ’ │ “ │ ” │ • │ – │ — │ ˜ │ ™ │ š │ › │ œ │ │ ž │ Ÿ │ Unicode │ │ 2018 │ 2019 │ 201C │ 201D │ 2022 │ 2013 │ 2014 │ 02DC │ 2122 │ 0161 │ 203A │ 0153 │ │ 017E │ 0178 │

A diferencia de Windows-1252, el rango 0x80… 0x9F se usa para los códigos de control en ISO-8859-1.

Esta tabla muestra las diferencias entre Windows-1252, ISO-8859-1 e ISO-8859-15

Character │ € │ Š │ š │ Ž │ ž │ Œ │ œ │ Ÿ │ ¤ │ ¦ │ ¨ │ ´ │ ¸ │ ¼ │ ½ │ ¾ │ ─────────────────────────────────────────────────────────────────────────────────────────────────────── ISO 8859-1 │ – │ – │ – │ – │ – │ – │ – │ – │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │ ISO 8859-15 │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │ – │ – │ – │ – │ – │ – │ – │ – │ Windows-1252 │ 80 │ 8A │ 9A │ 8E │ 9E │ 8C │ 9C │ 9F │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │ Unicode │ 20AC │ 160 │ 161 │ 17D │ 17E │ 152 │ 153 │ 178 │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │

La referencia más autorizada a los significados de los nombres de codificación de caracteres es el Conjunto de caracteres del registro de la IANA.

Windows-1252 se conoce comúnmente como Windows Latin 1 o como Windows West European o algo así. Se diferencia de ISO Latin 1, también conocido como ISO-8859-1 como una codificación de caracteres, por lo que el rango de códigos 0x80 a 0x9F se reserva para los caracteres de control en ISO-8859-1 (llamados Controles C1), cuando está en Windows -1252, algunos de los códigos se asignan a caracteres imprimibles (en su mayoría, caracteres de puntuación), otros se dejan sin definir.

ANSI viene aquí como un nombre inapropiado. Microsoft una vez envió Windows-1252 al American National Standards Institute (ANSI) para que fuera adoptado como estándar; La propuesta fue rechazada, pero Microsoft todavía llama a su código "ANSI". Para mayor confusión, pueden usar "ANSI" para diferentes codificaciones (básicamente, la "codificación nativa de 8 bits" de una instalación de Windows).

En el contexto web, la declaración ISO-8859-1 se tomará como si declarara Windows-1252. La razón es que los controles C1 no se usan, o son útiles, en la web, mientras que los caracteres agregados se usan a menudo, incluso en páginas etiquetadas incorrectamente como ISO-8859-1. Así que en términos prácticos no importa cuál usted declara.

Es posible que aún existan algunos navegadores que realmente interpretan los datos como ISO-8859-1 si se declaran así, pero deben ser muy raros (lo último que recuerdo haber visto fue una versión de Opera hace unos diez años).

Usted no describe los problemas que ha encontrado. La causa más común de los problemas parece ser que los datos en realidad están codificados en UTF-8 pero declarados como ISO-8859-1 (o Windows-1252), o viceversa. Esto se convierte en un problema real para los autores de páginas web si un servidor fuerza un encabezado Content-Type declara una codificación de caracteres y es uno con el que no pueden lidiar en su entorno de creación (o no saben cómo hacerlo).

Me gustaría responder esto de una manera más parecida a la web y para poder responderla, por lo que necesitamos un poco de historia. Joel Spolsky ha escrito un muy buen artículo introductorio sobre el mínimo absoluto que todo desarrollador debería saber sobre la codificación de caracteres Unicode. Tengan paciencia aquí porque esta será una respuesta bastante looong . :)

Como historia, señalaré algunas citas de allí: (Muchas gracias Joel! :))

Los únicos caracteres que importaban eran las buenas y antiguas letras en inglés sin acentos, y teníamos un código para ellos llamado ASCII que podía representar a todos los caracteres usando un número entre 32 y 127. El espacio era 32, la letra "A" era 65, etc. Esto podría ser almacenado convenientemente en 7 bits. La mayoría de las computadoras en esos días usaban bytes de 8 bits, así que no solo podías almacenar todos los caracteres ASCII posibles, sino que tenías un poco de sobra, que, si fueras malvado, podrías usar para tus propios propósitos.

Y todo estuvo bien, suponiendo que fueras angloparlante. Debido a que los bytes tienen espacio para hasta ocho bits, muchas personas se pusieron a pensar: "Dios mío, podemos usar los códigos 128-255 para nuestros propios fines". El problema era que muchas personas tenían esta idea al mismo tiempo, y tenían sus propias ideas de lo que debería ir en el espacio de 128 a 255.

Así que ahora los "conjuntos de caracteres OEM" se distribuían con las PC y aún eran diferentes e incompatibles. Y para nuestro asombro contemporáneo, ¡todo estuvo bien! No tenían Internet atrás y la gente rara vez intercambiaba archivos entre sistemas con diferentes configuraciones regionales.

Joel sigue diciendo:

De hecho, tan pronto como la gente comenzó a comprar PC fuera de los Estados Unidos, se inventaron todo tipo de conjuntos de caracteres OEM diferentes, que utilizaban los 128 caracteres principales para sus propios fines. Finalmente, este OEM gratuito para todos se codificó en el estándar ANSI. En la norma ANSI, todos acordaron qué hacer por debajo de 128, que era más o menos lo mismo que ASCII, pero había muchas formas diferentes de manejar los personajes a partir de 128, dependiendo de dónde vivía. Estos diferentes sistemas fueron llamados páginas de códigos .

Y así es como nacieron las "páginas de códigos de Windows", eventualmente. En realidad fueron "parentales" por las páginas de códigos de DOS. ¡Y entonces nació Unicode! :) y UTF-8 es "otro sistema para almacenar su cadena de puntos de código Unicode" y en realidad "todos los puntos de código de 0-127 se almacenan en un solo byte" y son los mismos que ASCII . No entraré en más detalles específicos de Unicode y UTF-8, pero debería leer sobre la BOM , Endianness y codificación de caracteres como un general.

En "la conspiración ANSI", Microsoft admite el etiquetado incorrecto de Windows-1252 en un glosario de términos :

El llamado conjunto de caracteres de Windows (WinLatin1, o página de códigos de Windows 1252, para ser exactos) utiliza algunas de esas posiciones para los caracteres imprimibles. Por lo tanto, el conjunto de caracteres de Windows NO es idéntico a ISO 8859-1. El conjunto de caracteres de Windows a menudo se denomina "conjunto de caracteres ANSI", pero se trata DE UN INCORRECTO GRAVE. NO ha sido aprobado por ANSI.

Por lo tanto, ANSI cuando se refiere a juegos de caracteres de Windows no está certificado por ANSI . :)

Como señaló Jukka (los créditos son para ti por la buena respuesta)

Windows-1252 ISO Latin 1, también conocido como ISO-8859-1 como una codificación de caracteres, por lo que el rango de código 0x80 a 0x9F se reserva para los caracteres de control en ISO-8859-1 (los llamados Controles C1), cuando está en Windows -1252, algunos de los códigos se asignan a caracteres imprimibles (en su mayoría, caracteres de puntuación), otros se dejan sin definir.

Sin embargo, mi opinión personal y mi entendimiento técnico es que tanto Windows-1252 como ISO-8859-1 NO SON CÓDIGOS WEB . :) Asi que:

  • Para las páginas web, utilice UTF-8 como codificación para el contenido. Almacene los datos como UTF-8 y "escúpalos" con el encabezado HTTP : Content-Type: text/html; charset=utf-8 Content-Type: text/html; charset=utf-8 .

    También hay una cosa llamada meta-etiqueta de tipo de contenido HTML : <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> Ahora, qué navegadores En realidad, cuando se encuentran con esta etiqueta es que vuelven a comenzar desde el principio del documento HTML para que puedan reinterpretar el documento en la codificación declarada. Esto debería ocurrir solo si no hay un encabezado de ''tipo de contenido''.

  • Utilice otras codificaciones específicas si los usuarios de su sistema necesitan archivos generados a partir de él. Por ejemplo, algunos usuarios occidentales pueden necesitar archivos generados por Excel o CSV en Windows-1252. Si este es el caso, codifique el texto en esa configuración regional y luego guárdelo en la fs y entréguelo como un archivo descargable.

  • Hay otra cosa que hay que tener en cuenta en el diseño de HTTP : el mecanismo de distribución de codificación de contenido debería funcionar así.

    I. El cliente solicita una página web en un tipo de contenido y codificación específicos a través de los encabezados de solicitud "Aceptar" y "Aceptar juego de caracteres".

    II. Luego, el servidor (o la aplicación web) devuelve el contenido trans-codificado a esa codificación y conjunto de caracteres.

Esto NO ES EL CASO en la mayoría de las aplicaciones web modernas. Lo que realmente sucede es que las aplicaciones web sirven (forzar al cliente) el contenido como UTF-8. Y esto funciona porque los navegadores interpretan los documentos recibidos según los encabezados de respuesta y no según lo que realmente esperaban.

Todos debemos usar Unicode, así que, por favor, use UTF-8 para distribuir su contenido siempre que sea posible y, sobre todo, aplicable. ¡O si no, los ancianos de Internet te perseguirán! :)

PD. here se pueden encontrar algunos artículos más interesantes sobre el uso de caracteres de MS Windows en páginas web.