Pregunta ¿Qué hay de diferente entre UTF-8 y UTF-8 sin BOM?


Lo que es diferente entre UTF-8 y UTF-8 sin una BOM? ¿Cual es mejor?


636
2018-02-08 18:26


origen


Respuestas:


La BOM UTF-8 es una secuencia de bytes (EF BB BF) que permite al lector identificar un archivo como codificado en UTF-8.

Normalmente, la lista de materiales se utiliza para señalar la endianidad de una codificación, pero como la endianidad es irrelevante para UTF-8, la lista de materiales no es necesaria.

De acuerdo con la Estándar Unicode, el La lista de materiales para archivos UTF-8 no se recomienda:

2.6 Esquemas de codificación

... El uso de una lista de materiales no se requiere ni se recomienda para UTF-8, pero puede ser   encontrado en contextos donde los datos UTF-8 se convierten de otros   formularios de codificación que usan una lista de materiales o donde la lista de materiales se utiliza como un UTF-8   firma. Consulte la subsección "Marca de orden de bytes" en Sección 16.8,   Especiales,   para más información.


599
2018-02-08 18:33



Las otras excelentes respuestas ya respondieron que:

  • No hay diferencia oficial entre UTF-8 y BOM-ed UTF-8
  • Una cadena BOM-ed UTF-8 comenzará con los tres siguientes bytes. EF BB BF
  • Esos bytes, si están presentes, se deben ignorar al extraer la cadena del archivo / secuencia.

Pero, como información adicional a esto, la lista de materiales para UTF-8 podría ser una buena manera de "oler" si una cadena estaba codificada en UTF-8 ... O podría ser una cadena legítima en cualquier otra codificación ...

Por ejemplo, los datos [EF BB BF 41 42 43] podrían ser:

  • El legítimo ISO-8859-1 cadena "ï» ¿ABC "
  • El legítimo UTF-8 cadena "ABC"

Entonces, aunque puede ser genial reconocer la codificación de un contenido de archivo mirando los primeros bytes, no debe confiar en esto, como se muestra en el ejemplo anterior

Las codificaciones deben ser conocidas, no adivinadas.


195
2018-02-08 18:42



Hay al menos tres problemas al colocar una lista de materiales en archivos codificados en UTF-8.

  1. Los archivos que no contienen texto ya no están vacíos porque siempre contienen la lista de materiales.
  2. Los archivos que contienen texto que está dentro del subconjunto ASCII de UTF-8 ya no son ellos mismos ASCII porque la lista de materiales no es ASCII, lo que hace que algunas herramientas existentes se descompongan, y puede ser imposible para los usuarios reemplazar dichas herramientas heredadas.
  3. No es posible concatenar varios archivos juntos porque cada archivo ahora tiene una lista de materiales al principio.

Y, como han mencionado otros, no es ni suficiente ni necesario tener una lista de materiales para detectar que algo es UTF-8:

  • No es suficiente porque puede suceder que una secuencia de bytes arbitraria comience con la secuencia exacta que constituye la lista de materiales.
  • No es necesario porque puede leer los bytes como si fueran UTF-8; si eso tiene éxito, es, por definición, UTF-8 válido.

103
2017-11-15 13:28



Es una vieja pregunta con muchas buenas respuestas, pero se debe agregar una cosa.

Todas las respuestas son muy generales. Lo que me gustaría agregar son ejemplos del uso de BOM que en realidad causan problemas reales y, sin embargo, muchas personas no lo conocen.

BOM rompe scripts

Los scripts de Shell, los scripts de Perl, los scripts de Python, los scripts de Ruby, los scripts de Node.js o cualquier otro ejecutable que deba ser ejecutado por un intérprete, todo comienza con un línea shebang que se parece a uno de esos:

#!/bin/sh
#!/usr/bin/python
#!/usr/local/bin/perl
#!/usr/bin/env node

Le dice al sistema qué intérprete necesita ejecutarse al invocar dicho script. Si la secuencia de comandos está codificada en UTF-8, uno puede tener la tentación de incluir una lista de materiales al principio. Pero en realidad el "#!" los personajes no son solo personajes De hecho, son un número mágico eso sucede que está compuesto de dos caracteres ASCII. Si coloca algo (como una lista de materiales) antes de esos personajes, entonces el archivo se verá como si tuviera un número mágico diferente y eso puede ocasionar problemas.

Ver Wikipedia, artículo: Shebang, sección: número mágico:

Los caracteres shebang están representados por los mismos dos bytes en   codificaciones ASCII extendidas, incluyendo UTF-8, que se usa comúnmente para   scripts y otros archivos de texto en sistemas actuales tipo Unix. Sin embargo,   Los archivos UTF-8 pueden comenzar con la marca de orden de bytes opcional (BOM); Si el   La función "exec" detecta específicamente los bytes 0x23 y 0x21, luego el   presencia de la BOM (0xEF 0xBB 0xBF) antes de que el shebang evite   el intérprete de guión de ser ejecutado. Algunas autoridades recomiendan   contra el uso de la marca de orden de bytes en secuencias de comandos POSIX (tipo Unix), [14]   por esta razón y para una mayor interoperabilidad y filosófica   preocupaciones Además, una marca de orden de bytes no es necesaria en UTF-8,   ya que esa codificación no tiene problemas de endianness; sirve solo para   identifique la codificación como UTF-8. [énfasis añadido]

BOM es ilegal en JSON

Ver RFC 7159, sección 8.1:

Las implementaciones NO DEBEN agregar una marca de orden de bytes al comienzo de un texto JSON.

BOM es redundante en JSON

No solo es ilegal en JSON, también es innecesario para determinar la codificación de caracteres porque hay formas más confiables de determinar inequívocamente tanto la codificación de caracteres como la endianidad utilizada en cualquier secuencia JSON (ver esta respuesta para detalles).

BOM rompe los analizadores JSON

No solo es ilegal en JSON y innecesario, En realidad rompe todo el software que determinan la codificación utilizando el método presentado en RFC 4627:

Determinación de la codificación y endianness de JSON, examinando los primeros 4 bytes para el byte NUL:

00 00 00 xx - UTF-32BE
00 xx 00 xx - UTF-16BE
xx 00 00 00 - UTF-32LE
xx 00 xx 00 - UTF-16LE
xx xx xx xx - UTF-8

Ahora, si el archivo comienza con BOM se verá así:

00 00 FE FF - UTF-32BE
FE FF 00 xx - UTF-16BE
FF FE 00 00 - UTF-32LE
FF FE xx 00 - UTF-16LE
EF BB BF xx - UTF-8

Tenga en cuenta que:

  1. UTF-32BE no comienza con tres NUL por lo que no será reconocido
  2. UTF-32LE el primer byte no es seguido por 3 NULs por lo que no será reconocido
  3. UTF-16BE tiene solo 1 NUL en los primeros 4 bytes, por lo que no será reconocido
  4. UTF-16LE tiene solo 1 NUL en los primeros 4 bytes, por lo que no será reconocido

Dependiendo de la implementación, todos ellos pueden interpretarse incorrectamente como UTF-8 y luego malinterpretarse o rechazarse como UTF-8 no válido, o no ser reconocidos en absoluto.

Además, si la implementación prueba un JSON válido como recomiendo, rechazará incluso la entrada que efectivamente está codificada como UTF-8 porque no comienza con un carácter ASCII <128 como debería según el RFC.

Otros formatos de datos

La BOM en JSON no es necesaria, es ilegal y rompe el software que funciona correctamente de acuerdo con el RFC. Debería ser un nobrainer simplemente no usarlo en ese momento y, sin embargo, siempre hay personas que insisten en romper JSON mediante el uso de listas de materiales, comentarios, reglas de cotización diferentes o diferentes tipos de datos. Por supuesto, cualquiera puede usar cosas como listas de materiales o cualquier otra cosa si lo necesita, simplemente no lo llame JSON.

Para otros formatos de datos que JSON, observe cómo se ve realmente. Si las únicas codificaciones son UTF- * y el primer carácter debe ser un carácter ASCII menor que 128, entonces ya tiene toda la información necesaria para determinar tanto la codificación como la endianidad de sus datos. Agregar listas de materiales incluso como una función opcional solo lo haría más complicado y propenso a errores.

Otros usos de BOM

En cuanto a los usos fuera de JSON o scripts, creo que ya hay muy buenas respuestas aquí. Quería agregar más información detallada específicamente sobre scripting y serialización porque es un ejemplo de los caracteres de la BOM que causan problemas reales.


56
2018-06-26 11:34



¿Qué hay de diferente entre UTF-8 y UTF-8 sin BOM?

Respuesta corta: en UTF-8, una BOM se codifica como los bytes EF BB BF al comienzo del archivo.

Respuesta larga:

Originalmente, se esperaba que Unicode estaría codificado en UTF-16 / UCS-2. La lista de materiales fue diseñada para esta forma de codificación. Cuando tiene unidades de código de 2 bytes, es necesario indicar en qué orden están esos dos bytes, y una convención común para hacer esto es incluir el carácter U + FEFF como una "Marca de orden de byte" al comienzo de los datos. El carácter U + FFFE está permanentemente desasignado para que su presencia pueda usarse para detectar el orden de bytes incorrecto.

UTF-8 tiene el mismo orden de bytes independientemente del endianamiento de la plataforma, por lo que no es necesaria una marca de orden de bytes. Sin embargo, puede ocurrir (como la secuencia de bytes EF BB FF) en datos que se convirtieron a UTF-8 de UTF-16, o como una "firma" para indicar que los datos son UTF-8.

¿Cual es mejor?

Sin. Como Martin Cote respondió, el estándar Unicode no lo recomienda. Causa problemas con software no compatible con BOM.

Una mejor forma de detectar si un archivo es UTF-8 es realizar una verificación de validez. UTF-8 tiene reglas estrictas sobre qué secuencias de bytes son válidas, por lo que la probabilidad de un falso positivo es insignificante. Si una secuencia de bytes se parece a UTF-8, probablemente lo sea.


43
2017-07-31 22:53



UTF-8 con BOM está mejor identificado. He llegado a esta conclusión por las malas. Estoy trabajando en un proyecto donde uno de los resultados es un CSV archivo, incluidos los caracteres Unicode.

Si el archivo CSV se guarda sin una lista de materiales, Excel piensa que es ANSI y muestra un galimatías. Una vez que agrega "EF BB BF" al frente (por ejemplo, al volver a guardarlo usando el Bloc de notas con UTF-8 o Notepad ++ con UTF-8 con BOM), Excel lo abre bien.

La RFC 3629 recomienda el anteponer el carácter BOM a los archivos de texto Unicode: "UTF-8, un formato de transformación de ISO 10646", noviembre de 2003 a http://tools.ietf.org/html/rfc3629 (esta última información encontrada en: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html)


29
2018-06-28 17:34



BOM tiende a auge (sin juego de palabras (sic)) en algún lugar, en algún lugar. Y cuando se dispara (por ejemplo, no es reconocido por los navegadores, editores, etc.), aparece como los personajes extraños  al comienzo del documento (por ejemplo, archivo HTML, JSON respuesta, RSS, etc.) y causa el tipo de vergüenza como el problema reciente de codificación experimentado durante la charla de Obama en Twitter.

Es muy molesto cuando aparece en lugares difíciles de depurar o cuando se descuidan las pruebas. Por lo tanto, es mejor evitarlo a menos que deba usarlo.


15
2017-07-11 07:56



Pregunta: ¿Qué hay de diferente entre UTF-8 y UTF-8 sin una lista de materiales? ¿Cual es mejor?

Aquí hay algunos extractos del artículo de Wikipedia sobre el marca de orden de bytes (BOM) que creo que ofrecen una respuesta sólida a esta pregunta.

Sobre el significado de BOM y UTF-8:

El estándar Unicode permite BOM en UTF-8, pero no requiere   o recomiende su uso. La orden de bytes no tiene sentido en UTF-8, por lo que   solo el uso en UTF-8 es señalizar desde el principio que la secuencia de texto es   codificado en UTF-8.

Argumento para  NO  usando una BOM:

La principal motivación para no usar una BOM es la compatibilidad con versiones anteriores   con un software que no es consciente de Unicode ... Otra motivación para no   usar una lista de materiales es alentar a UTF-8 como la codificación "predeterminada".

Argumento  PARA  usando una BOM:

El argumento para usar una lista de materiales es que sin ella, el análisis heurístico es   requerido para determinar qué carácter está usando la codificación de un archivo.   Históricamente, dicho análisis, para distinguir varias codificaciones de 8 bits, es   complicado, propenso a errores, y a veces lento. Una cantidad de bibliotecas   están disponibles para facilitar la tarea, como Mozilla Universal Charset   Detector y componentes internacionales para Unicode.

Los programadores asumen erróneamente que la detección de UTF-8 es igualmente   difícil (no es debido a la gran mayoría de las secuencias de bytes   son inválidos UTF-8, mientras que las codificaciones estas bibliotecas están tratando de   distinguir permitir todas las secuencias de bytes posibles). Por lo tanto, no todos   Los programas con reconocimiento de Unicode realizan dicho análisis y en su lugar confían en   la lista de materiales.

En particular, Microsoft compiladores e intérpretes, y muchos   piezas de software en Microsoft Windows como el Bloc de notas no   leer correctamente el texto UTF-8 a menos que solo tenga caracteres ASCII o   comienza con la lista de materiales y agregará una lista de materiales al comienzo al guardar el texto   como UTF-8. Google Docs agregará una lista de materiales cuando se encuentre un documento de Microsoft Word.   descargado como un archivo de texto sin formato.

En cuál es mejor,  CON  o  SIN  la lista de materiales:

los IETF recomienda que si un protocolo (a) siempre usa UTF-8,   o (b) tiene alguna otra forma de indicar qué codificación se está utilizando,   entonces "DEBERÍA prohibir el uso de U + FEFF como firma".

Mi conclusión:

Usa la lista de materiales solamente si la compatibilidad con una aplicación de software es absolutamente esencial.

También tenga en cuenta que, si bien el artículo de Wikipedia mencionado indica que muchas aplicaciones de Microsoft se basan en la lista de materiales para detectar correctamente UTF-8, este no es el caso de todas Aplicaciones de Microsoft. Por ejemplo, como lo señala @barlop, cuando se usa el símbolo del sistema de Windows con UTF-8, ordena tales type y more no espere que la lista de materiales esté presente. Si la lista de materiales es presente, puede ser problemático como lo es para otras aplicaciones.


† Los chcp comando ofrece soporte para UTF-8 (sin la lista de materiales) a través de la página de códigos 65001.


12
2017-10-02 20:24



Citado en la parte inferior de la página de Wikipedia en la lista de materiales: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"El uso de una lista de materiales no es necesario ni recomendado para UTF-8, pero puede encontrarse en contextos donde los datos UTF-8 se convierten de otras formas de codificación que usan una lista de materiales o donde la lista de materiales se utiliza como firma UTF-8"


7
2018-02-08 18:35