¿Puedo usar un valor centinela de Unicode?

Question

¿Puedo usar un valor centinela de Unicode?

#1 de Esailija (16 votos)
#2 de Martijn Pieters (5 votos)
#3 de parsifal (1 votos)

15

Estoy diseñando un formato de archivo y quiero hacerlo bien. Como es un formato binario, el primer byte (o bytes) del archivo debería no formar caracteres textuales válidos (como en el encabezado del archivo PNG ¹). Esto permite que las herramientas que no reconocen el formato sigan viendo que no es un archivo de texto mirando los primeros bytes.

Cualquier punto de código por encima de 0x7F no es válido US-ASCII, por lo que es fácil. Pero para Unicode es una historia completamente diferente. Además de los caracteres válidos de Unicode, hay caracteres de uso privado , no caracteres y centinelas , como he encontrado en Caracteres de uso privado de Unicode, caracteres no & Preguntas frecuentes de Sentinels .

¿Cuál sería una secuencia de bytes centinela que puedo usar al inicio del archivo que daría como resultado US-ASCII, UTF-8, UTF-16LE y UTF-16BE no válidos?

Obviamente, el primer byte no puede tener un valor inferior a 0x80 , ya que sería un carácter válido de US-ASCII (control), por lo que no se puede usar 0x00 .
Además, dado que los caracteres de uso privado son caracteres Unicode válidos, tampoco puedo usar esos puntos de código.
Dado que debe funcionar tanto con little-endian como con big-endian UTF-16, un no carácter como 0xFFFE tampoco es posible ya que su reverso 0xFEFF es un carácter Unicode válido.
Las preguntas frecuentes mencionadas anteriormente sugieren que no se use ninguno de los no caracteres , ya que eso daría como resultado una secuencia de Unicode válida, por lo que algo como 0xFFFF también está fuera de la imagen.

¿Cuáles serían los valores de centinela preparados para el futuro que me quedan por usar?

¹) El formato PNG tiene como primer byte el valor no-ASCII 0x89 , seguido de la cadena PNG . Una herramienta que lee los primeros bytes de un PNG puede determinar que es un archivo binario, ya que no puede interpretar 0x89 . Un archivo GIF, por otro lado, comienza directamente con la cadena ASCII válida y legible GIF seguida de otros tres caracteres ASCII válidos. Para GIF, una herramienta puede determinar que es un archivo de texto legible. Esto es incorrecto y la idea de iniciar el archivo con una secuencia de bytes sin textura provino de Diseño de formatos de archivo por Andy McFadden.

unicode

pregunta Daniel Pelsmaeker 13.03.2013 - 16:15

3 respuestas

Lea otras preguntas en las etiquetas unicode

¿Qué es cebar la bomba? A veces se llama una lectura de cebado ¿Son las funciones de primera clase un sustituto del patrón de estrategia?

score 16 · Answer 1

16

0xDC 0xDC

Es obvio que no es válido UTF-8 y ASCII
Sustituto de sendero no pareado en la posición principal, independientemente de la endianess en UTF-16. No hay más UTF-16 no válido que eso.

respondido por el Esailija 13.03.2013 - 17:03

score 5 · Answer 2

En UTF-8, los bytes C0, C1 y F5 - FF son ilegales. El primer byte debe ser ASCII o un byte en el rango C2-F4, cualquier otro byte inicial no es válido para UTF-8.
En UTF-16, el archivo normalmente comienza con la marca de orden de bytes (U + FEFF), de lo contrario las aplicaciones deben adivinar el orden de bytes. Los puntos de código en el rango D800-DBFF son bytes iniciales para un par suplente, y DC00-DFFF son los bytes finales para un par suplente.

Por lo tanto, usaría el combo de bytes F5DC . Estos dos valores son:

No es ASCII
No es válido UTF-8
Se interpreta como un byte final UTF-16 en un par sustituto (no es legal), o el punto de código U + F5DC, que es un carácter de uso privado, pero solo por aplicaciones que intentan obstinadamente interprete esto como UTF-16 incluso sin una lista de materiales.

Si necesita más opciones, F5DD hasta F5DF tienen las mismas 3 propiedades, al igual que F6DC - F6DF , F7DC - F7DF y F8DC - F8DF , para un total de 16 combinaciones de bytes diferentes para elegir.

score 1 · Answer 3

Si estás tratando de usar un carácter no imprimible para indicar "no texto", entonces te resultará difícil vencer a 0x89:

Está fuera del rango US-ASCII
En ISO-8859-1 es un carácter no imprimible ("TABULACIÓN DE PERSONAJES CON JUSTIFICACIÓN"). Del mismo modo con Shift-JIS, que creo que todavía es de uso común. Sin embargo, otras codificaciones de 8 bits pueden tratar esto como un carácter válido.
En UTF-8 es un primer byte no válido para una secuencia de múltiples bytes (los bits superiores son 10, que están reservados para los caracteres 2..N de una secuencia de múltiples bytes)

Generalmente, cuando se forman números mágicos, "no texto" es un punto menor. Tendré que buscar la referencia, pero uno de los formatos gráficos estándar (TIFF, creo) tiene algo así como seis piezas diferentes de información útil de su número mágico.