¿Por qué Windows 7 funciona con Unicode y no con UTF-8?
Terminología
Unicode y UTF-8 no son el mismo tipo de cosas: Unicode es un juego de caracteres que define un conjunto de caracteres (un repertorio) y los números asignados (código de puntos) para cada uno de esos personajes. UTF ‑ 8 es una de varias codificaciones que se pueden usar para representar una secuencia de caracteres Unicode en el disco o en la transmisión. El mismo flujo de caracteres Unicode también podría codificarse como UTF-16, UTF-32 o UTF-7, por ejemplo.
Sin embargo, el Bloc de notas ofertas que "codifica" opciones, incluyendo ANSI, Unicode, Unicode big-endiany UTF-8. Los desarrolladores de Microsoft que escribieron esto han usado los términos incorrectos. Cuando dicen "Unicode", lo más probable es que signifiquen " UTF-16
little-endian ". Cuando dicen "ANSI" se refieren a la página de códigos 1252 (CP-1252).
Bloc de notas de Microsoft
Creo que el Bloc de notas de Microsoft escribe UTF-16 con una marca de orden de bytes ( BOM ) y que el Bloc de notas busca la BOM cuando lee un archivo de texto. La lista de materiales le dice a la aplicación que el archivo es UTF-16 e indica si es big-endian o little-endian.
Si el Bloc de notas no encuentra la lista de materiales, llama a una función de biblioteca IsTextUnicode, que examina los datos e intenta adivinar qué codificación se utilizó. A veces (inevitablemente) adivina incorrectamente. A veces adivina que un archivo "ANSI" es "Unicode". Intentar interpretar un archivo UTF-16 o UTF-8 como página de códigos 1252 provocaría que muestre los glifos incorrectos y no pueda encontrar glifos para representar algunos valores de 8 bits; estos se mostrarían como cuadrados.
Como dice harrymc en su respuesta , hay mejores alternativas al Bloc de notas. Pero el Bloc de notas le permite elegir explícitamente la codificación al abrir un archivo (en lugar de abandonar el Bloc de notas para intentar adivinar).
Marcas de orden de bytes
Según el consorcio Unicode, las marcas de orden de bytes (BOM) son opcionales. Sin embargo, Windows se basa en listas de materiales para distinguir entre algunas codificaciones.
En resumen, ¿quizás sus archivos carecían de una lista de materiales por alguna razón? ¿Quizás la lista de materiales se perdió en algún momento durante el proceso de actualización?
Si todavía tiene los archivos originales que se muestran como cuadrados, puede hacer un volcado hexadecimal de ellos para ver si contienen una lista de materiales.
Estándares de archivos de texto sin formato
El problema es que efectivamente no hay ninguno , no hay estándares universales para archivos de texto sin formato. En cambio, tenemos una serie de incompatibilidades e incógnitas.
¿Cómo se han marcado los finales de línea? Algunas plataformas usan el retorno de carro de caracteres de control (CR) seguido de salto de línea (LF), algunas usan CR solo y otras usan LF solo.
¿Son los terminadores o separadores anteriores? Esto tiene un efecto al final de un archivo y se sabe que causa problemas.
Tratamiento de pestañas y otros caracteres de control. Podemos suponer que se usa una pestaña para alinear a un múltiplo de 8 anchos de caracteres estándar desde el comienzo de la línea, pero realmente no hay certeza al respecto. Muchos programas permiten modificar las posiciones de las pestañas.
Conjunto de caracteres y codificación? No existe un estándar universal para indicar cuáles de estos se han utilizado para el texto del archivo. Lo más cercano que tenemos es buscar la presencia de una lista de materiales que indica que la codificación es una de las utilizadas para Unicode. Desde el valor de BOM, el programa que lee el archivo puede distinguir entre UTF-8 y UTF-16, etc., y entre las variantes Little-Endian y Big-Endian de UTF-16, etc. No existe un estándar universal para indicar que un archivo está codificado en cualquier otra codificación popular como CP-1252 o KOI-8.
Y así. Ninguno de los metadatos anteriores se escribe en el archivo de texto, por lo que el usuario final debe informar al programa al leer el archivo. El usuario final tiene que conocer los valores de metadatos para cualquier archivo específico o correr el riesgo de que su programa use los valores de metadatos incorrectos.
Bush ocultó los hechos
Prueba esto en Windows XP.
- Abra el Bloc de notas.
- Establezca la fuente en Arial Unicode MS. (Es posible que deba instalarlo primero; si no lo ve en el menú, haga clic en "Mostrar más fuentes").
- Ingrese el texto "Bush ocultó los hechos".
- Elija
Save As. Desde el Encodingmenú, seleccione ANSI.
- Cerrar el Bloc de notas.
- Vuelva a abrir el documento (por ejemplo, utilizando
Start, My Recent Documents).
- Verá 畂 桳 栠 摩 琠 敨 映 捡 獴 en lugar de "Bush ocultó los hechos".
Esto ilustra que la IsTextUnicodefunción utilizada por el Bloc de notas adivina incorrectamente que el texto ANSI (realmente Código de página 1252) es Unicode UTF-16LE sin una lista de materiales. No hay una lista de materiales en un archivo guardado como ANSI.
Windows 7
Con Windows 7, Microsoft se ajustó IsTextUnicodepara que lo anterior no suceda. En ausencia de una lista de materiales, ahora es más probable que adivine ANSI (CP 1252) que Unicode (UTF-16LE). Con Windows-7, espero que sea más probable que tenga el problema inverso: un archivo que contiene caracteres Unicode con puntos de código superiores a 255, pero sin BOM, ahora es más probable que se adivine como ANSI y, por lo tanto, se muestre incorrectamente.
Prevenir problemas de codificación
Actualmente, el mejor enfoque parece ser usar UTF-8 en todas partes. Lo ideal sería volver a codificar todos los archivos de texto antiguos en UTF-8 y solo guardar archivos de texto como UTF-8. Hay herramientas como recode e iconv que pueden ayudar con esto.