En travaillant avec un collègue, j'ai trouvé un problème étrange qui semble lié à l'encodage. Nous travaillons avec des images qui ont des noms de fichiers assez simples comme city.gif
ou wine.gif
, mais comme on pouvait s'y attendre les choses se compliquent lorsque vous utilisez des caractères spéciaux tels que é
, ë
, à
. Nous travaillons également avec des données néerlandaises qui ont ces caractères, par exemple café
( pub ). (Nous n'avons aucun contrôle sur l'origine des fichiers.) Voici où les problèmes commencent à se poser. Les noms de fichiers suivants ne sont qu'un exemple. Le problème se produit également pour d'autres personnages avec des signes diacritiques.
café-2.png
cafetaria.png
café.png
Le premier et le dernier élément doivent avoir un e accentué (accent aigu, é
). C'est ainsi que cela est affiché sous Linux (CentOS 6 & 7) dans un terminal lors de l'exécution ls
. Mais voici Windows! (En utilisant Windows 10, 64 bits.) Lorsque vous êtes connecté sur Windows via SSL avec notre serveur puis en appelant ls
, la liste ci-dessus ressemble à ceci:
café-2.png
cafetaria.png
caf▒.png
Comme vous pouvez l'espérer, la première ligne a toujours le e accentué é
, mais pas la troisième. Au lieu de cela, je vois ▒
ce caractère - qui est medium shade
en unicode (9618 décimal). C'est étrange en soi. Cependant, lorsque je me connecte via SFTP avec Filezilla (toujours sous Windows), je vois ceci:
café-2.png
cafetaria.png
café.png
Alors maintenant, les choses ont changé: dans le premier, é
a changé dans la séquence et dans le troisième tout va bien. J'ai trouvé ici que cela est probablement dû à une conversion Latin-1 <-> UTF-8 qui a mal tourné, si j'ai bien compris. Mais ça ne peut pas être tout ce qui se passe, non?
Linux montre tout comme on peut s'y attendre, Windows montre un comportement apparemment incohérent selon la façon dont nous voyons le nom de fichier (SSH (putty) ou SFTP (filezilla)). Existe-t-il un moyen de «normaliser» ces noms de fichiers - c'est-à-dire de les modifier - et de s'assurer qu'ils sont tous les mêmes sur tous les systèmes d'exploitation; ou du moins cohérent, et si oui, comment? UTF-8
est notre encodage de choix.
Même si cela peut être un simple problème esthétique, ce n'est pas le cas. Lorsque j'essaie de télécharger des choses via SFTP dans Windows à partir de notre serveur Linux, je ne peux pas télécharger les fichiers qui ont le problème mentionné ci-dessus. Filezilla lancera une erreur telle que Can't download file café-2.png: café-2.png does not exist on the server
. Ce qui me semble que Filezilla lit le répertoire et le nom de fichier, l'interprète dans un certain encodage, envoie une requête GET au serveur avec son interprétation, mais cette interprétation diffère du nom de fichier Linux donc par conséquent le fichier n'est pas trouvé.
En fin de compte, ce serait bien s'il y avait une solution disponible, même si je suis également intéressé par la raison pour laquelle cela se produit. Cela se produit-il parce que les fichiers image ont peut-être été créés sur différents systèmes d'exploitation? Cela se produit-il parce que le serveur Linux les interprète mal ou que Windows est en train de gâcher? J'espère qu'il existe une solution où nous pouvons simplement contacter notre administrateur système et leur demander d'activer un commutateur dans la configuration du serveur, mais je crains que ce ne soit pas aussi simple que cela.
python -c "import sys; print(repr(sys.argv[1]))" café-2.png
et python -c "import sys; print(repr(sys.argv[1]))" café.png
?