Quel codage utilisent les noms de fichiers stockés dans NTFS?

Question

Je viens de commencer à travailler sur la programmation pour gérer les noms de fichiers avec des noms non anglais sur un système WinXP. J'ai lu quelques recommandations sur l'unicode et je pense avoir saisi l'idée de base, mais certaines parties ne sont pas très claires pour moi.

Plus précisément, dans quel encodage (UTF-8, UTF-16LE/BE) les noms de fichiers (pas le contenu, mais le nom réel du fichier) sont-ils stockés dans NTFS? Est-il possible d'ouvrir n'importe quel fichier en utilisant fopen(), qui prend un char*, ou n'ai-je pas d'autre choix que d'utiliser wfopen(), qui utilise un wchar_t*, et qui prend probablement une chaîne UTF-16?

J'ai essayé d'introduire manuellement une chaîne encodée en UTF-8 à fopen(), par exemple.

unsigned char filename[] = {0xEA, 0xB0, 0x80, 0x2E, 0x74, 0x78, 0x74, 0x0}; // .txt

FILE* f = fopen((char*)filename, "wb+");

mais cela est sorti comme '.txt'.

J'étais sous l'impression (qui peut être fausse) qu'une chaîne encodée en UTF8 serait suffisante pour ouvrir n'importe quel nom de fichier sous Windows, car je me souviens vaguement qu'une application Windows passait autour de (char*), pas de (wchar_t*), et qu'il n'y avait pas de problèmes.

Est-ce que quelqu'un peut éclairer ma lanterne à ce sujet?

Answer 1

NTFS stocke les noms de fichiers en UTF-16, cependant fopen utilise ANSI (pas UTF-8).

Pour utiliser un nom de fichier encodé en UTF-16, vous devrez utiliser les versions Unicode des appels d'ouverture de fichier. Faites cela en définissant UNICODE et _UNICODE dans votre projet. Ensuite, utilisez l'appel CreateFile ou l'appel wfopen.

Answer 2

Fopen() - in MSVC on windows does not (by default) take a utf-8 encoded char*.

Malheureusement, l'utf-8 a été inventé assez récemment dans le grand schéma des choses. Les API Windows sont divisées en versions Unicode et Ansi. Chaque API Windows qui prend ou traite des chaînes est en fait disponible avec un suffixe W ou A - W pour "Wide" caractère/Unicode et A pour Ansi. La magie des macros cache tout cela au développeur, vous appelez donc simplement CreateFile avec un char* ou un wchar_t* selon la configuration de votre construction sans connaître la différence.

L'encodage 'Ansi' n'est en fait pas un encodage spécifique:- mais signifie que l'encodage utilisé pour les chaînes "char" est spécifique au paramètre local du PC.

Maintenant, parce que les fonctions de la c-runtime - comme fopen - doivent fonctionner par défaut sans connaissances du développeur - sur les systèmes Windows, elles s'attendent à recevoir leurs chaînes dans l'encodage local de Windows. msdn indique que l'api setlocale du runtime C de Microsoft peut changer le paramètre local du thread actuel - mais précise spécifiquement qu'il échouera pour tous les paramètres locaux qui nécessitent plus de 2 octets par caractère - comme l'utf-8.

Donc, sur Windows, il n'y a pas de raccourci. Vous devez utiliser wfopen, ou l'API native CreateFileW (ou créer votre projet en utilisant les paramètres de construction Unicode et simplement appeler Createfile) avec des chaînes wchar_t*.

Answer 3

Comme le soulignent d'autres, la meilleure façon de gérer les chaînes encodées en UTF-8 est de les convertir en UTF-16 et d'utiliser des API Unicode natives telles que _wfopen ou CreateFileW.

Cependant, cette approche ne fonctionnera pas lorsque vous appelez des bibliothèques qui utilisent fopen() de manière inconditionnelle car elles ne prennent pas en charge Unicode ou parce qu'elles sont écrites en C portable. Dans ce cas, il est toujours possible d'utiliser les anciens "chemins courts" pour convertir une chaîne encodée en UTF-8 en une forme ASCII utilisable avec fopen, mais cela nécessite un certain travail :

1. Convertissez la représentation UTF-8 en UTF-16 en utilisant MultiByteToWideChar.

2. Utilisez GetShortPathNameW pour obtenir un "chemin court" qui n'est que de l'ASCII. GetShortPathNameW le renverra sous forme de chaîne large avec un contenu entièrement ASCII, que vous devrez convertir trivialement en une chaîne étroite en copiant chaque wchar_t char de manière sans perte.

3. Transmettez le chemin court à fopen() ou au code qui utilisera éventuellement fopen(). Notez que les messages d'erreur imprimés par ce code, le cas échéant, feront référence au "chemin court" laid (par exemple KINTO~1 au lieu de kinto-un-筋斗雲).

Bien que cela ne soit pas exactement une stratégie recommandée à long terme, car les chemins courts de Windows sont une fonctionnalité héritée qui peut être désactivée par volume, c'est probablement le seul moyen de transmettre des noms de fichiers à du code utilisant fopen() et d'autres appels d'API liés au fichier (stat, access, versions ANSI de CreateFile et similaires).