Marca de orden de bytes

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

El estándar Unicode permite el BOM en UTF-8 , ^{[ 4 ]} pero no exige ni recomienda su uso. ^{[ 5 ]} UTF-8 siempre tiene el mismo orden de bytes, ^{[ 6 ]} por lo que su único uso en UTF-8 es indicar al inicio que el flujo de texto está codificado en UTF-8, o que se convirtió a UTF-8 desde un flujo que contenía un BOM opcional. El estándar tampoco recomienda eliminar un BOM cuando está presente, para que el intercambio entre codificaciones no pierda información y para que el código que depende de él siga funcionando. ^{[ 7 ] [ 8 ]} 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 "DEBERÍA prohibir el uso de U+FEFF como firma". ^{[ 9 ]} Un ejemplo de no seguir esta recomendación es el protocolo Syslog de la IETF , que requiere que el texto esté en UTF-8 y también requiere la BOM. ^{[ 10 ]}

No utilizar una marca de orden de bytes (BOM) permite que el texto sea compatible con versiones anteriores de software diseñado para ASCII extendido . Por ejemplo, muchos lenguajes de programación permiten bytes que no son ASCII en literales de cadena , pero no al principio del archivo.

No es necesario un BOM para detectar la codificación UTF-8. UTF-8 es una codificación dispersa: una gran fracción 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 son válidas como UTF-8, por lo que la existencia de dichas secuencias no válidas indica que el archivo no es UTF-8, mientras que la ausencia de secuencias no válidas es una indicación muy fuerte de que el texto es UTF-8. Prácticamente la única excepción es el texto que contiene solo bytes en el rango ASCII, ya que esto podría ser una codificación de 7 bits no ASCII, pero esto es improbable en cualquier dato moderno e incluso en ese caso la diferencia con ASCII es mínima (como cambiar '\' por '¥').

Los compiladores e intérpretes de Microsoft ^{[ 11 ]} , y muchos programas de Microsoft Windows como el Bloc de notas (antes de Windows 10 Build 1903 ^{[ 12 ]} ) tratan el BOM como un número mágico obligatorio en lugar de usar heurísticas. Estas herramientas agregan un BOM al guardar texto como UTF-8 y no pueden interpretar UTF-8 a menos que el BOM esté presente o el archivo contenga solo ASCII. Windows PowerShell (hasta la versión 5.1) agregará un BOM al guardar documentos XML UTF-8. Sin embargo, PowerShell Core 6 ha agregado un -Encodingmodificador en algunos cmdlets llamado utf8NoBOM para que el documento se pueda guardar sin BOM. Google Docs también agrega un BOM al convertir un documento a un archivo de texto plano para su descarga.

En UTF-16U+FEFF , se puede colocar una BOM ( ) como los primeros bytes de un archivo o flujo de caracteres para indicar el orden de bytes (endianness) de todas las unidades de código de 16 bits del archivo o flujo. Si se intenta leer este flujo con un orden de bytes incorrecto, los bytes se intercambiarán, lo que generará el carácter U+FFFE, que Unicode define como un " no carácter " que nunca debería aparecer en un texto.

• Si las unidades de 16 bits se representan en orden de bytes big-endian ("UTF-16BE"), la BOM es la secuencia de bytes ( hexadecimal ).FE FF
• Si las unidades de 16 bits utilizan el orden little-endian ("UTF-16LE"), la BOM es la secuencia de bytes ( hexadecimal ).FF FE

Para los conjuntos de caracteres UTF-16BE y UTF-16LE registrados por la IANA , no se debe utilizar una marca de orden de bytes, ya que los nombres de estos conjuntos de caracteres ya determinan dicho orden.

La cláusula D98 de conformidad (sección 3.10) del estándar Unicode establece: «El esquema de codificación UTF-16 puede o no comenzar con una marca de orden de bytes (BOM). 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». La existencia o no de un protocolo de nivel superior está sujeta a interpretación. Por ejemplo, se podría argumentar que los archivos locales de un ordenador cuyo orden de bytes nativo es little-endian se codifican implícitamente como UTF-16LE. Por lo tanto, la presunción de big-endian se ignora ampliamente. El estándar de codificación W3C / WHATWG utilizado en HTML5 especifica que el contenido etiquetado como «utf-16» o «utf-16le» debe interpretarse como little-endian «para gestionar el contenido desplegado». ^{[ 13 ]} Sin embargo, si hay una marca de orden de bytes, entonces esa BOM debe tratarse como «más autorizada que cualquier otra cosa». ^{[ 14 ]}

Sin una marca de orden de bytes (BOM), sigue siendo bastante fiable detectar si un texto es UTF-16 y cuál es su orden de bytes si el texto es suficientemente largo. Los caracteres del bloque de caracteres latinos básicos (U+0001 a U+007F) tienen un byte alto nulo (0x00); incluso en alfabetos no latinos, los saltos de línea y los espacios (que se incluyen en este bloque) se utilizan con frecuencia. Si los bytes nulos aparecen con mucha más frecuencia en posiciones pares del archivo, es probable que se trate de UTF-16 big-endian, y little-endian si aparecen con más frecuencia en posiciones impares.

Si bien se podría usar una marca de orden de bytes (BOM) con UTF-32 , esta codificación rara vez se utiliza para la transmisión. Por lo demás, se aplican las mismas reglas que para UTF-16 .

La marca de orden de bytes (BOM) para UTF-32 little-endian tiene el mismo patrón que la BOM de UTF-16 little-endian seguida de un carácter nulo (NUL) de UTF-16, un ejemplo inusual de una BOM con el mismo patrón en dos codificaciones diferentes. Los programadores que utilicen la BOM para identificar la codificación deberán decidir si es más probable que se trate de UTF-32 o UTF-16 con un carácter nulo al principio. UTF-32 se detecta fácilmente sin una BOM porque cada cuarto byte es nulo.