¿Cuál es la diferencia entre UTF-8 e ISO-8859-1?


Respuestas:


321

UTF-8 es una codificación multibyte que puede representar cualquier carácter Unicode. ISO 8859-1 es una codificación de un solo byte que puede representar los primeros 256 caracteres Unicode. Ambos codifican ASCII exactamente de la misma manera.


11
Una cosa a tener en cuenta es que ASCII se extiende de 0 a 127 solamente. El MSB siempre es 0.
Hritik

3
Cuando se definen puntos de código superiores a 127, el sistema de codificación es una versión de ASCII extendido.
Rohan Bhale

1
@RohanBhale No use la frase ASCII extendido; solo causará confusión.
Sr. Lister

Pero ascii extendido podría ser el término correcto. Lo leí en múltiples recursos
Rohan Bhale

135

Wikipedia explica ambas cosas razonablemente bien: UTF-8 vs Latin-1 (ISO-8859-1). La primera es una codificación de longitud variable, la última codificación de longitud fija de un solo byte. Latin-1 codifica solo los primeros 256 puntos de código del juego de caracteres Unicode, mientras que UTF-8 puede usarse para codificar todos los puntos de código. A nivel de codificación física, solo los puntos de código 0 - 127 se codifican de forma idéntica; los puntos de código 128-255 difieren al convertirse en una secuencia de 2 bytes con UTF-8, mientras que son bytes únicos con Latin-1.


@mu tal vez mi declaración era ambigua, pero no es incorrecta: no estaba hablando de secuencias de bytes codificadas, sino de conjuntos de caracteres codificados; lo que significa que ISO-8859-1 se usa para codificar los primeros 256 puntos de código del juego de caracteres Unicode.
StaxMan

Su aclaración funciona para mí y "ambiguo" habría sido una mejor elección de palabra que "incorrecto".
mu es demasiado corto el

83

UTF

UTF es una familia de esquemas de codificación de varios bytes que pueden representar puntos de código Unicode que pueden ser representativos de hasta 2 ^ 31 [aproximadamente 2 mil millones] caracteres. UTF-8 es un sistema de codificación flexible que utiliza entre 1 y 4 bytes para representar los primeros 2 ^ 21 [aproximadamente 2 millones] puntos de código.

En pocas palabras: cualquier personaje con un punto de código / representación ordinal por debajo de 127, también conocido como ASCII de 7 bits seguro, está representado por la misma secuencia de 1 byte que la mayoría de las otras codificaciones de un solo byte. Cualquier carácter con un punto de código superior a 127 está representado por una secuencia de dos o más bytes, con los detalles de la codificación mejor explicados aquí .

ISO-8859

ISO-8859 es una familia de esquemas de codificación de un solo byte utilizados para representar alfabetos que se pueden representar dentro del rango de 127 a 255. Estos diversos alfabetos se definen como "partes" en el formato ISO-8859- n , el más familiar de estos probablemente sean ISO-8859-1, también conocido como 'Latin-1'. Al igual que con UTF-8, el ASCII seguro de 7 bits no se ve afectado independientemente de la familia de codificación utilizada.

El inconveniente de este esquema de codificación es su incapacidad para acomodar idiomas compuestos por más de 128 símbolos, o para mostrar de manera segura más de una familia de símbolos a la vez. Además, las codificaciones ISO-8859 han caído en desgracia con el aumento de UTF. El "Grupo de trabajo" ISO a cargo de que se disolviera en 2004, dejando el mantenimiento a su subcomité matriz.


1
+1 por responder la pregunta pero ir más allá y ofrecer información sobre codificaciones relacionadas. Re: codifique puntos para UTF-8, de acuerdo con stackoverflow.com/a/38488358/3353984 , UTF-8 admite 2 ^ 21 puntos de código. ¿Es eso un error, o podría ser necesaria una solución aquí?
Tom Loredo

1
Unicode es en realidad 17 planos de 2 ^ 16 puntos de código. 0x00_0000 a 0x1F_FFFF. Los 17 aviones pueden acomodar 1,114,112 puntos de código. De estos, 2,048 son sustitutos, 66 no son personajes y 137,468 están reservados para uso privado, dejando 974,530 para asignación pública. Alrededor de 1 millón. Consulte ¿Cuántos caracteres puede codificar UTF-8? .
georgeawg

22
  • ASCII: 7 bits. 128 puntos de código.

  • ISO-8859-1: 8 bits. 256 puntos de código.

  • UTF-8: 8-32 bits (1-4 bytes). 1.112.064 puntos de código.

Tanto ISO-8859-1 como UTF-8 son compatibles con ASCII, pero UTF-8 no es compatible con ISO-8859-1:

#!/usr/bin/env python3

c = chr(0xa9)
print(c)
print(c.encode('utf-8'))
print(c.encode('iso-8859-1'))

Salida:

©
b'\xc2\xa9'
b'\xa9'

21

ISO-8859-1 es un estándar heredado de la década de 1980. Solo puede representar 256 caracteres, por lo que solo es adecuado para algunos idiomas en el mundo occidental. Incluso para muchos idiomas compatibles, faltan algunos caracteres. Si crea un archivo de texto con esta codificación e intenta copiar / pegar algunos caracteres chinos, verá resultados extraños. En otras palabras, no lo use. Unicode se ha apoderado del mundo y UTF-8 es prácticamente el estándar en estos días a menos que tenga algunos motivos heredados (como los encabezados HTTP que deben ser compatibles con todo).


1
Había visto dónde supuestamente los Umlaut no se convertían con UTF8. Vimos ejemplos de esto y al buscar encontramos el ISO-8859-1 y parece funcionar. Tenemos muchos científicos alemanes con los que trabajamos.
Aggie Jon de 87

44
Los Umlaut se representan como dos caracteres en utf8. Se convierten bien y funcionan bien. El problema proviene de programas que esperan 1 byte por carácter. Para estos programas heredados, ISO-8859-1 tiene diéresis de 1 byte.
Erik Aronesty

3

Desde otra perspectiva, los archivos que las codificaciones unicode y ascii no pueden leer porque tienen un byte 0xc0en ellos, parecen ser leídos por iso-8859-1 correctamente. La advertencia es que el archivo no debe tener caracteres Unicode, por supuesto.


2

Una cosa más importante a tener en cuenta: si ve iso-8859-1, probablemente se refiere a Windows-1252 en lugar de a ISO / IEC 8859-1 . Difieren en el rango de 0x80–0x9F, donde ISO 8859-1 tiene los códigos de control C1 y Windows-1252 tiene caracteres visibles útiles en su lugar.

Por ejemplo, ISO 8859-1 tiene 0x85 como un carácter de control (en Unicode, U + 0085, ``), mientras que Windows-1252 tiene puntos suspensivos horizontales (en Unicode, U + 2026 ELIPSIS HORIZONTAL, ).

La especificación WHATWG Encoding (tal como la utiliza HTML) declara expresamente iso-8859-1que es una etiqueta windows-1252y los navegadores web no admiten ISO 8859-1 de ninguna manera: la especificación HTML dice que todas las codificaciones en la especificación Encoding deben ser compatibles, y no más .

También de interés, las referencias de caracteres numéricos HTML utilizan esencialmente Windows-1252 para valores de 8 bits en lugar de puntos de código Unicode; por https://html.spec.whatwg.org/#numeric-character-reference-end-state , …producirá U + 2026 en lugar de U + 0085.


¡Uy! Pensé que había escrito eso, pero lo perdí en una reescritura. Lo puse ahora.
Chris Morgan

0

Mi razón para investigar esta pregunta fue desde la perspectiva, es de qué manera son compatibles. Latin1 charset (iso-8859) es 100% compatible para almacenarse en un almacén de datos utf8. Todos los caracteres ascii y ascii extendido se almacenarán como un solo byte.

En el otro sentido, desde utf8 a Latin1 charset puede o no funcionar. Si hay caracteres de 2 bytes (caracteres más allá de ascii 255 extendido) no se almacenarán en un almacén de datos Latin1.


2
Útil, pero creo que te refieres a 127 en lugar de 255 en 255 extendido-ascii.
Hydroper

18
Latin-1 o iso-8859-1 no es 100% compatible para almacenarse en utf8. Cualquier carácter latino-n o iso-8859-n por encima de 127 no se traducirá a un solo byte utf-8. Sin embargo, para los valores 1-127, se traducirán exactamente.
Marlin Pierce

44
Esta respuesta es un poco confusa en su uso del término "ascii extendido", que es solo un término para referirse a cualquier codificación de caracteres que no sea ASCII. UTF-8 y latin-1 son ejemplos de codificaciones ASCII extendidas. Pero, los caracteres no ascii latin-1 (es decir, puntos de código superiores a 127) no pueden codificarse como un solo byte en UTF-8.
rdb
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.