Marca de orden de bytes

En Unicode, la marca de orden de bytes (del idioma inglés "byte order mark" o BOM) es un dato que indica el uso de una codificación Unicode, así como el orden de los bytes, que generalmente se encuentra al principio de algunos archivos de texto.^[1]​

Técnicamente,^[2]​ es un carácter Unicode cuyo código numérico de carácter (code point o code position, en idioma inglés) es U+FEFF (espacio sin salto de línea de ancho cero o zero-width no-break space en idioma inglés), el cual se utiliza para marcar cuál es la posición de mayor o menor valor (endianness)^[3]​ de una cadena del Conjunto de Caracteres Universal ISO/IEC 10646 (en inglés Universal Character Set o UCS) o Unicode ya sea en UTF-16 o UTF-32 y/o como un marcador para indicar que el texto está codificado en UTF-8, UTF-16 o UTF-32. El término oficial para este carácter en la versión francesa de ISO/IEC 10646 (que es la contraparte de Unicode ISO) es marca de orden de bytes (BOM).

Cuando se interpreta correctamente, el usuario final del texto codificado no ve el BOM. Sin embargo, hay dos casos donde este carácter puede ser mal interpretado:

• En el caso de que se considere una versión antigua de Unicode, este carácter es invisible y que no se muestra al usuario.
• En el caso de un texto Unicode UTF-8 mostrado con una codificación incorrecta (es decir, la codificación utilizada no es la que debe usarse), el usuario hallará al comienzo de la página o texto una breve secuencia de caracteres incomprensibles sin significado (en particular con la codificación ISO/IEC 8859-1). En este caso los siguientes tres caracteres aparecen al principio del texto:

 

Debido a que la codificación utilizada no es la especificada, algunos caracteres regionales o acentuados no se muestran correctamente en el resto del texto.

La marca de orden de bytes de la mayoría de las codificaciones Unicode es una secuencia de pocos bytes que puede aparecer como una secuencia inusual de caracteres si el software que se usa para leer el texto está mal configurado o como un espacio si el software que se usa para leer el texto no reconoce este indicador.^[4]​

Si una marca de orden de bytes se interpreta erróneamente como un carácter dentro del texto, será invisible porque es un espacio sin interrupción de ancho cero (es decir, un zero-width no-break space). El uso del carácter U+FEFF como un espacio sin interrupción de ancho cero, (es decir, como un espacio duro) se ha vuelto obsoleto en la versión Unicode 3.2, la cual proporciona el carácter U+2060 como alternativa para este uso específico.^[5]​ Por lo tanto, este carácter debe usarse solo como un marca de orden de bytes.

Historia

• En julio de 1995, la versión 1.1.5 de Unicode define:

FEFF;ZERO WIDTH NO-BREAK SPACE;Zs;0;ON;;;;;N;BYTE ORDER MARK;;;; 

y no define el código numérico de carácter anterior, el FEFE ni el FEFD. La lista se detiene en FEFC (ARABIC LIGATURE LAM WITH ALEF FINAL FORM).^[6]​

• En julio de 1996, la versión Unicode 2.0 definió en las secciones §2.3 y §2.4 el rol de la secuencia FFFE / FEFF para detectar el orden de los bytes ( little-endian / big-endian).^[7]​
• En septiembre de 1999, la versión 3.0 de Unicode retoma lo que está definido en la versión 2.0. Sin embargo, en §13.6 se agrega una explicación de los usos de la marca de orden de bytes UTF-16 como en UTF-8.^[8]​
• Hasta Unicode 3.2, en marzo de 2002, U+FEFF era el único código numérico de carácter con semántica de unión de palabras (en inglés, word joining), pero como se usa más comúnmente como indicador de orden de bytes, la semántica de la unión de palabra se delega en el código numérico de carácter U+2060. Sin embargo, U+FEFF conserva ambos significados por razones de retrocompatibilidad.^[9]​
• En 2001, el error 4508058 se identifica en Java "La codificación UTF-8 no reconoce la lista de materiales inicial"; se decide no corregirlo. Fue reportado el 27 de septiembre de 2001 y fue corregido el 18 de febrero de 2006.^[10]​
• En noviembre de 2003, el problema del BOM es considerado en el RFC 3629.
• Entre junio de 2001 y 2009, la problemática de la marca de orden de bytes se tuvo en cuenta en el lenguaje Python por medio de la Propuesta de Mejora 263 (en inglés, Python Enhancement Proposals, PEP 263).^[11]​
• El 20 de enero de 2005, Microsoft introdujo una función de compatibilidad con Unicode en el software bloc de notas que rompe la interoperabilidad con algunos software antiguos en Unix no preparados para ello.^[12]​

Usos

UTF-16 y UTF-32

En UTF-16, un BOM se expresa mediante una secuencia de dos bytes al principio de la cadena codificada para indicar el orden de escritura que emplean los caracteres que la siguen, siendo ésta: FE FF si emplean el orden big-endian (escritura secuencial en el orden natural de lectura) o FF FE si emplean el orden little-endian (al contrario).^[13]​ En ningún caso el valor U+FFFE puede ser un carácter Unicode y este hecho permite que se pueda emplear para detectar el orden de los bytes de la cadena, en contraste con U+FEFF que sí es un carácter.

Problemas con el uso de la marca de orden de bytes

Mientras que el UTF-8 no está relacionado con ninguna problemática de orden de bytes un BOM codificado en UTF-8 puede ser empleado para etiquetar el texto como UTF-8. Muchas aplicaciones del entorno Windows (incluyendo Windows Notepad) añaden un BOM a sus ficheros UTF-8. Sin embargo en los sistemas tipo Unix (que hacen uso exhaustivo de ficheros de texto para configuración) no se recomienda esta práctica, pues puede interferir con el correcto procesado de códigos importantes, tales como el hash-bang al principio de la interpretación de un script.^[14]​ También podría interferir con el código fuente de aquellos lenguajes de programación que no lo reconozcan. Por ejemplo, gcc informa de los caracteres perdidos al comienzo del fichero fuente,^{[cita requerida]} y en PHP 5, cuando el output buffering está desactivado, tiene el sutil efecto de hacer que la página comience de inmediato a ser enviada al navegador, evitando que las cabeceras (custom headers) puedan ser especificadas por el script PHP. La representación UTF-8 del BOM es la secuencia de bytes EF BB BF, que aparece como los caracteres ISO-8859-1 "" en los editores de textos y navegadores no configurados para manejar UTF-8.

Aunque un BOM puede ser empleado con UTF-32, esta codificación casi nunca se usa en la práctica para ningún tipo de transmisión.^{[cita requerida]}

Representaciones de las marcas de orden de bytes para cada codificación

Codificación	Representación (hexadecimal)	Representaçión (decimal)	Representación (ISO-8859-1)
UTF-8^[13]​	EF BB BF	239 187 191	
UTF-16 (big-endian)^[13]​	FE FF	254 255	þÿ
UTF-16 (little-endian)^[13]​	FF FE	255 254	ÿþ
UTF-32 (big-endian)^[13]​	00 00 FE FF	0 0 254 255	□□þÿ (□ es el carácter nulo en ASCII)
UTF-32 (little-endian)^[13]​	FF FE 00 00	255 254 0 0	ÿþ□□ (□ es el carácter nulo en ASCII)
UTF-7	2B 2F 76, y uno de los siguientes bytes: [ 38 | 39 | 2B | 2F ]	43 47 118, y uno de los siguientes bytes: [ 56 | 57 | 43 | 47 ]	+/v, y uno de los siguientes bytes: 8 9 + /
UTF-1	F7 64 4C	247 100 76	÷dL
UTF-EBCDIC	DD 73 66 73	221 115 102 115	Ýsfs
SCSU	0E FE FF	14 254 255	□þÿ (□ es el carácter de cambio de mayúsculas en ASCII)
BOCU-1	FB EE 28 opcionalmente seguido de FF	251 238 40 opcionalmente seguido de 255	ûî( opcionalmente seguido de ÿ
GB 18030	84 31 95 33	132 49 149 51	□1■3 (□ y ■ son caracteres no asignados en ISO-8859-1)

Véase también

• ISO 10646
• ISO-8859-1

Referencias

1. (en inglés) Q: What is a BOM?
2. (en inglés) Q: Where is a BOM useful?
3. (en inglés) Q: What does ‘endian’ mean?
4. (en inglés) Q: What should I do with U+FEFF in the middle of a file?
5. (en inglés) Q: I am using a protocol that has BOM at the start of text. How do I represent an initial ZWNBSP?
6. (en inglés) Unicode 1.1 Composite Name List, including default properties
7. (en inglés) "Chapter 2 General Structure" (páginas 12 y 13)
8. (en inglés) "Chapter 13 Special Areas and Format Characters" ()
9. (en inglés) Unicode 3.2: 3.9 Special Character Properties (revision)
10. (en inglés) "JDK-4508058 : UTF-8 encoding does not recognize initial BOM"
11. (en inglés) PEP 263 -- Defining Python Source Code Encodings
12. Kapian, Michael S. (20 de enero de 2005). (html). MSDN Library (en inglés). Archivado desde el original el 11 de julio de 2010. Consultado el 25 de diciembre de 2018. «And lots of other folks who support Unix tools that did not have to be completely changed to support Unicode by using UTF-8 do not like these extra three bytes at the front of the file. Sometimes that is because they really only support ASCII or ISO-8859-1, other times it is because they just can't handle those three bytes right in front but later on would not matter.» 
13. (en inglés) Q: When a BOM is used, is it only in 16-bit Unicode text?
14. (en inglés) Q: Can a UTF-8 data stream contain the BOM character (in UTF-8 form)? If yes, then can I still assume the remaining UTF-8 bytes are in big-endian order?

Enlaces externos

• (ver 13.6 — Specials)
• en Wayback Machine (archivado el 24 de febrero de 2018).

• Esta obra contiene una traducción sección «Representaciones de las marcas de orden de bytes para cada codificación» derivada de « Marca de ordem de byte » de Wikipedia en portugués, concretamente de esta versión del 4 de noviembre de 2012, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.
• Esta obra contiene una traducción casi total (excepto «Representaciones de las marcas de orden de bytes para cada codificación») derivada de «Indicateur d'ordre des octets» de Wikipedia en francés, concretamente de esta versión del 24 de diciembre de 2018, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.

•   Datos: Q1018724