Marca de orden de bytes

La marca de orden de bytes (BOM) es un uso particular del carácter especial Unicode, U+FEFF BYTE ORDER MARK, cuya aparición como un número mágico al comienzo de un flujo de texto puede indicar varias cosas a un programa que lee el texto:

• Orden byte, o endianness, del flujo de texto en los casos de codificación de 16 bits y 32 bits;
• El hecho de que la codificación del flujo de texto es Unicode, a un alto nivel de confianza;
• Que codificación de caracteres Unicode se utiliza.

El uso de BOM es opcional. Su presencia interfiere con el uso de UTF-8 por parte del software que no espera bytes que no sean ASCII al comienzo de un archivo pero que, de lo contrario, podría manejar el flujo de texto.

Unicode se puede codificar en unidades de enteros de 8 bits, 16 bits o 32 bits. Para las representaciones de 16 y 32 bits, una computadora que recibe texto de fuentes arbitrarias necesita saber en qué orden de bytes están codificados los números enteros. La lista de materiales está codificada en el mismo esquema que el resto del documento y se convierte en un punto de código Unicode sin caracteres. si sus bytes están intercambiados. Por lo tanto, el proceso que accede al texto puede examinar estos primeros bytes para determinar el endianness, sin requerir ningún contrato o metadatos fuera del flujo de texto en sí. Generalmente, la computadora receptora intercambiará los bytes a su propio endian, si es necesario, y ya no necesitará la lista de materiales para el procesamiento.

La secuencia de bytes de la lista de materiales difiere según la codificación Unicode (incluidas las que están fuera del estándar Unicode, como UTF-7, consulte la tabla a continuación), y es probable que ninguna de las secuencias aparezca al comienzo de los flujos de texto almacenados en otras codificaciones.. Por lo tanto, colocar una lista de materiales codificada al comienzo de una secuencia de texto puede indicar que el texto es Unicode e identificar el esquema de codificación utilizado. Este uso del carácter BOM se denomina "firma Unicode".

Uso

El carácter BOM es, simplemente, el punto de código Unicode U+FEFF ZERO WIDTH NO-BREAK SPACE, codificado en la codificación actual. Tradicionalmente, este punto de código es solo un espacio de ancho cero que no se rompe y que inhibe los saltos de línea entre los glifos de palabras. Como tal, si el carácter BOM aparece en medio de un flujo de datos, Unicode dice que debe interpretarse como un punto de código normal, no como una BOM. Desde Unicode 3.2, este uso ha quedado obsoleto en favor de U+2060 WORD JOINER.

UTF-8

La representación UTF-8 de la lista de materiales es la secuencia de bytes (hexadecimal) EF BB BF.

El estándar Unicode permite la BOM en UTF-8, pero no requiere ni recomienda su uso. El orden de los bytes no tiene significado en UTF-8, por lo que su único uso en UTF-8 es señalar al comienzo que el flujo de texto está codificado en UTF-8, o que se convirtió a UTF-8 desde un flujo que contenía un lista de materiales opcional. El estándar tampoco recomienda eliminar una lista de materiales cuando está allí, para que el viaje de ida y vuelta entre codificaciones no pierda información y para que el código que se basa en ella continúe funcionando. El IETF recomienda que si un protocolo (a) siempre usa UTF-8 o (b) tiene alguna otra forma de indicar qué codificación se está usando, entonces DEBE prohibir el uso de U+FEFF como firma. " Un ejemplo de no seguir esta recomendación es el protocolo IETF Syslog, que requiere que el texto esté en UTF-8 y también requiere la lista de materiales.

No usar una lista de materiales permite que el texto sea compatible con versiones anteriores de algún software que no sea compatible con Unicode. Los ejemplos incluyen lenguajes de programación que permiten bytes que no son ASCII en cadenas literales pero no al comienzo del archivo.

UTF-8 es una codificación dispersa: una gran parte de las posibles combinaciones de bytes no dan como resultado un texto UTF-8 válido. Es probable que los datos binarios y el texto en cualquier otra codificación contengan secuencias de bytes que no sean válidas como UTF-8. Prácticamente, la única excepción es el texto que contiene solo bytes de rango ASCII, pero como todas las codificaciones modernas usan bytes de rango ASCII para representar caracteres ASCII, dicho texto se puede interpretar de manera segura como UTF-8, independientemente de la codificación en la que se haya escrito. Debido a estas consideraciones, la falta de errores de UTF-8 indica con mucha confianza que UTF-8 está en uso, sin necesidad de una lista de materiales.

Los compiladores e intérpretes de Microsoft, y muchas piezas de software en Microsoft Windows, como el Bloc de notas, tratan la lista de materiales como un número mágico requerido en lugar de usar heurística. Estas herramientas agregan una lista de materiales al guardar texto como UTF-8 y no pueden interpretar UTF-8 a menos que la lista de materiales esté presente o el archivo contenga solo ASCII. Windows PowerShell (hasta 5.1) agregará una lista de materiales cuando guarde documentos XML UTF-8. Sin embargo, PowerShell Core 6 agregó un interruptor -Encoding en algunos cmdlets llamados utf8NoBOM para que el documento se pueda guardar sin BOM. Google Docs también agrega una lista de materiales al convertir un documento en un archivo de texto sin formato para su descarga.

UTF-16

En UTF-16, se puede colocar un BOM (U+FEFF) como el primer carácter de un archivo o flujo de caracteres para indicar el endianness (orden de bytes) de todo el código de 16 bits. unidad del archivo o secuencia. Si se intenta leer este flujo con el endian incorrecto, los bytes se intercambiarán, entregando así el carácter U+FFFE, que Unicode define como "no carácter" que nunca debe aparecer en el texto.

• Si las unidades de 16 bits están representadas en orden de byte grande-endiano ("UTF-16BE"), la BOM es la secuencia de byte (hexadecimal) FE FF
• Si las unidades de 16 bits utilizan el orden pequeño-endiano ("UTF-16LE"), el BOM es la secuencia de byte (hexadecimal) FF FE

Para los juegos de caracteres UTF-16BE y UTF-16LE registrados por IANA, no se debe usar una marca de orden de bytes porque los nombres de estos juegos de caracteres ya determinan el orden de los bytes. Si se encuentra en cualquier parte de un flujo de texto de este tipo, U+FEFF debe interpretarse como un "espacio sin interrupción de ancho cero".

Si no hay BOM, es posible adivinar si el texto es UTF-16 y su orden de bytes buscando caracteres ASCII (es decir, un byte 0 adyacente a un byte en el rango 0x20-0x7E, también 0x0A y 0x0D para CR y LF). Un número grande (es decir, mucho más alto que la probabilidad aleatoria) en el mismo orden es una muy buena indicación de UTF-16 y si el 0 está en los bytes pares o impares indica el orden de los bytes. Sin embargo, esto puede dar como resultado tanto falsos positivos como falsos negativos.

La cláusula D98 de conformidad (sección 3.10) de los estados estándar de Unicode, "El esquema de codificación UTF-16 puede o no comenzar con una lista de materiales. Sin embargo, cuando no hay BOM, y en ausencia de un protocolo de nivel superior, el orden de bytes del esquema de codificación UTF-16 es big-endian." Si un protocolo de nivel superior está en vigor o no, está abierto a interpretación. Los archivos locales a una computadora para la cual el orden de bytes nativo es little-endian, por ejemplo, podría argumentarse que están codificados como UTF-16LE implícitamente. Por lo tanto, la presunción de big-endian es ampliamente ignorada. El estándar de codificación W3C/WHATWG utilizado en HTML5 especifica que el contenido etiquetado como "utf-16" o "utf-16le" deben interpretarse como little-endian "para manejar el contenido desplegado". Sin embargo, si hay una marca de orden de bytes, entonces esa lista de materiales debe tratarse como "más autorizada que cualquier otra cosa".

Los programas que interpretan UTF-16 como una codificación basada en bytes pueden mostrar una confusión de caracteres, pero los caracteres ASCII serían reconocibles porque el byte bajo de la representación UTF-16 es el mismo que el código ASCII y, por lo tanto, sería mostró lo mismo. El byte superior de 0 puede mostrarse como nada, un espacio en blanco, un punto o algún otro glifo invariable.

UTF-32

Aunque se podría usar un BOM con UTF-32, esta codificación rara vez se usa para la transmisión. De lo contrario, se aplican las mismas reglas que para UTF-16.

La lista de materiales para little-endian UTF-32 es el mismo patrón que una lista de materiales para little-endian UTF-16 seguida de un carácter NUL, un ejemplo inusual de que la lista de materiales tiene el mismo patrón en dos codificaciones diferentes. Los programadores que utilicen BOM para identificar la codificación tendrán que decidir si es más probable que sea UTF-32 o un primer carácter NUL.

Marcas de orden de bytes por codificación

Esta tabla ilustra cómo se representa el carácter BOM como una secuencia de bytes en varias codificaciones y cómo pueden aparecer esas secuencias en un editor de texto que interpreta cada byte como una codificación heredada (CP1252 y notación de intercalación para los controles C0):