windows winapi unicode codepages fat32

windows - Nombres de archivo Unicode en FAT-32?



winapi codepages (2)

Las entradas básicas del directorio FAT o FAT32 solo admiten nombres cortos (el formato anterior del DOS 8.3) en la página de códigos OEM actual. Sin embargo, VFAT (FAT con soporte de nombre de archivo largo) que se utiliza en Windows, puede almacenar un nombre de archivo adicional, llamado largo para cada archivo, en UTF-16.

Por lo que yo entiendo, NTFS soporta nombres de archivos Unicode (¿UTF-16 como reclamos de Micorsoft?).

Pero la documentación oficial de MSDN es muy vaga con respecto a qué página (s) de código se usa para almacenar nombres de archivos (rutas de archivos) en FAT-32.

Aquí dice que la página de códigos OEM (CP437 supongo) se usa para almacenar nombres de archivos: http://msdn.microsoft.com/en-us/library/windows/desktop/dd317748.aspx

Pero aquí resulta que puede haber diferentes páginas de códigos OEM con el CP437 como una de ellas: http://msdn.microsoft.com/en-us/library/windows/desktop/dd317752.aspx

Y todos sabemos ahora que las utilidades como mount admiten muchas más páginas de códigos diferentes para FAT, más que solo páginas de códigos OEM configuradas.

Entonces, ¿cuál es la cdepage real para los nombres de archivo FAT-32? Depende de la página de códigos del sistema en el momento en que se creó el volumen FAT? ¿Puede FAT admitir páginas de códigos de caracteres de doble byte verdaderas como UTF-16? ¿O las páginas de códigos de personajes de Multi Byte como UTF-8 son el límite?

Y una pregunta más específica: ¿Qué sucede cuando uso la función CreateFileW (que, como dice MSDN, usa UTF-16 como página de códigos de nombre de archivo) para crear un archivo en el volumen FAT-32?


Puede que tengas que experimentar aquí. Esta es una gran pregunta, y no estoy 100% seguro, pero:

Entonces, ¿cuál es la página de códigos real para los nombres de archivo FAT-32? Depende de la página de códigos del sistema en el momento en que se creó el volumen FAT?

La "página de códigos OEM", sea lo que sea para el sistema.

¿Puede FAT admitir páginas de códigos de caracteres de doble byte verdaderas como UTF-16? ¿O las páginas de códigos de personajes de Multi Byte como UTF-8 son el límite?

No, no creo que FAT sea directamente capaz de UTF-16 o UTF-8. Dicho esto, Microsoft almacena el nombre de archivo Unicode en un método fuera de banda. Un archivo tiene dos nombres de archivo. (Así también puede tener nombres de archivos de más de 8,3 caracteres).

Y una pregunta más específica: ¿Qué sucede cuando uso la función CreateFileW (que, como dice MSDN, usa UTF-16 como página de códigos de nombre de archivo) para crear un archivo en el volumen FAT-32?

El nombre de archivo Unicode, como se pasa a CreateFileW se almacena directamente en el nombre de archivo fuera de banda. Se vuelve a codificar en la página de códigos OEM (lo que sea que esté en el sistema) y se coloca allí. Si no se puede convertir en la página de códigos OEM, o supera los 8,3 caracteres, Windows llamará al archivo algo así como, FILENA~1.TXT .

Algunas citas para estas respuestas:

Primero, ¡ esta página nos dice que la página de códigos OEM! = La página de códigos de Windows:

Las aplicaciones que no son Unicode que crean archivos FAT a veces tienen que usar las funciones de conversión de la biblioteca de tiempo de ejecución C estándar para traducir entre el juego de caracteres de la página de códigos de Windows y el juego de caracteres de la página de códigos OEM. Con las implementaciones de Unicode de las funciones del sistema de archivos, no es necesario realizar tales traducciones.

En un sistema estadounidense típico, la página de códigos OEM es "CP437" , pero la página de códigos de Windows es Windows-1252 (las llamadas FooA , creo, usan la página de códigos de Windows, típicamente Windows-1252 en una máquina estadounidense, pero depende de lugar).

Si tiene un volumen FAT disponible, puede ver esto en acción. El carácter "Σ" (U + 03a3) no está presente en Windows-1252, sin embargo, está en CP437. Puede ver los nombres de archivo cortos y largos con dir /X Con un archivo llamado asdfΣ.txt , verá:

ASDFΣ.TXT asdfΣ.txt

Sin embargo, con un archivo llamado "asdfΛ.txt" (Λ no está presente en CP437 o Windows-1252), verá:

ASDF~1.TXT asdf?.txt

(¿Es probable que vea ? Porque la fuente de cmd.exe no puede mostrar un Λ).

Para obtener información sobre nombres largos de archivos, consulte este artículo de Wikipedia .

Además, curiosamente, si nombra un archivo "asdf © .txt", puede obtener:

ASDFC.TXT asdfc.txt

... No estoy 100% seguro aquí, pero creo que Windows inteligentemente decidió sustituir "c" por ©, e hizo lo mismo para mostrarlo. Si cambia la fuente a algo que no está basado en ráster, como Consolas, verá:

ASDFC.TXT asdf©.txt

Y esta es la razón por la que deberías usar las funciones FooW .