Marca de orden de bytes
En Unicode, la marca de orden de bytes o BOM(11s) (del inglés byte order mark) es un dato que indica el uso de una codificación Unicode, así como el orden de los bytes. Generalmente se encuentra al principio de algunos archivos de texto.[1]
Técnicamente,[2] es un carácter Unicode cuyo punto de código es U+FEFF (espacio sin salto de línea de ancho cero o zero-width no-break space en 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 una marca de orden de bytes.
Historia
editar- 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 U+FEFE ni el U+FEFD. La lista se detiene en U+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 U+FFFE / U+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 en UTF-16 y 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 programa Bloc de notas que rompe la interoperabilidad con algunos software antiguos en Unix no preparados para ello.[12]
Usos
editarUTF-16 y UTF-32
editarEn 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
editarMientras que 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 Bloc de notas) 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 shebang 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
editar| 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
editarReferencias
editar- ↑ (en inglés) Q: What is a BOM?
- ↑ (en inglés) Q: Where is a BOM useful?
- ↑ (en inglés) Q: What does ‘endian’ mean?
- ↑ (en inglés) Q: What should I do with U+FEFF in the middle of a file?
- ↑ (en inglés) Q: I am using a protocol that has BOM at the start of text. How do I represent an initial ZWNBSP?
- ↑ (en inglés) Unicode 1.1 Composite Name List, including default properties
- ↑ (en inglés) "Chapter 2 General Structure" (páginas 12 y 13)
- ↑ (en inglés) "Chapter 13 Special Areas and Format Characters" ()
- ↑ (en inglés) Unicode 3.2: 3.9 Special Character Properties (revision)
- ↑ (en inglés) "JDK-4508058 : UTF-8 encoding does not recognize initial BOM"
- ↑ (en inglés) PEP 263 -- Defining Python Source Code Encodings
- ↑ Kapian, Michael S. (20 de enero de 2005). «Every character has a story #4: U+feff (alternate title: UTF-8 is the BOM, dude!)» (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.»
- ↑ a b c d e f (en inglés) Q: When a BOM is used, is it only in 16-bit Unicode text?
- ↑ (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
editar- The Unicode Standard, chapter 13 (PDF) (ver 13.6 — Specials)
- FAQ — UTF and BOM
- (en inglés) File Encoding Check a file's Byte Order Mark (BOM) to determine its text encoding 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 4.0 Internacional.
- 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 4.0 Internacional.
Datos: Q1018724
