ouverture de fichiers sur des systèmes non ANSI via d’anciennes fonctions d’API (non wchar)

J’écris un middleware qui me rend dingue. Je cherche des experts I18N pour m’aider – tout cela est assez nouveau pour moi.

Pour le moment, tout est sous Windows, mais il faudra que cela fonctionne sous Linux et Mac aussi, même si je parie que cela sera facile.

J’ai un système (que je ne peux pas toucher) qui me donnera une chaîne qui ressemble à wchar_t *. Il prend en entrée soit en UTF-8 ou la locale actuelle et fait le tour de magie pour me donner un wchar_t *.

J’ai une autre API que j’utilise qui ne peut prendre que les noms de fichiers au format char * (que je ne peux pas toucher non plus).

Donc, ce que j’ai fait est de prendre mon nom de fichier dans wchar_t * et d’utiliser la fonction WideCharToMultiByte de l’API Windows, de le convertir en char * et de le transmettre à mon autre fonction API. Cela fonctionnait très bien jusqu’à ce que QA décide d’utiliser un système d’exploitation japonais. Maintenant, le fopen (profondément dans l’API que je ne peux pas toucher) échoue.

J’ai essayé d’utiliser CP_ACP et CP_UTF8 dans mon appel WideCharToMultiByte et les deux fonctionnent sur ma machine de développement (anglais américain) même avec des caractères japonais dans le nom du fichier. Mais les deux échouent sur le système d’exploitation japonais.

Des astuces sur la manière dont je devrais vraiment gérer ces noms de fichiers?

Eh bien, la bonne façon de résoudre ce problème serait de réparer l’autre API. Accepter uniquement les noms de fichiers étroits, non-unicode, est simplement un comportement rompu.

Mais … tu as dit que tu ne pouvais pas faire ça. Vous pourrez peut-être contourner ce problème en obtenant le nom de fichier court, qui ne comportera pas de caractères non ANSI, et en le transmettant à l’API endommagée. (La raison en est que les noms de fichiers courts sont conçus pour fonctionner avec des applications 16 bits et que les fenêtres 16 bits ne supportent pas du tout Unicode)

Bien sûr, cela échouera si le nom de fichier n’est pas représentable sous forme de nom de fichier court ou si les noms de fichier courts sont désactivés sur la machine cible – mais c’est vraiment la seule option ici.

EDIT : Une autre remarque – si le nom du fichier contient Unicode, le nom du fichier court ne sera généralement pas lisible par l’homme. Il sera renommé pour utiliser un tas d’ordures hexagonales qui identifie de manière unique le fichier dans un monde restreint à 8.3 noms de fichiers.