Pourquoi mes noms de fichiers semblent-ils «normaux» sous Linux mais pas à distance sous Windows?

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.gifou 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 shadeen 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-8est 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.

Mais voici Windows!

Windows n'a rien à voir avec cela. Vous pouvez reproduire ce même comportement exact avec une instance locale de ( par exemple) Terminal GNOME, avec le codage de terminal sélectionné de façon appropriée et locale correctement configuré pour ls, sans que Windows soit dans l'image du tout .

La seule chose que Windows fait est de montrer clairement ce qui se passe ici. Votre programme FTP Windows prend les octets dans les noms de fichiers et les affiche en tant que points de code pertinents dans la page de codes 1252. Ceci, un codage à un octet avec presque tout ce qui est au-dessus de 0x1F un glyphe imprimable, nous dit exactement quels sont les octets dans vos noms de fichiers. .

Votre deuxième nom de fichier est largement informatif, mais le premier et le troisième sont révélateurs.

• Le premier nom de fichier est la séquence d'octets 63 61 66 c3 a9 2d 32 2e 70 6e 67- dans la page de codes 1252, c'est café-2.png. C'est aussi le codage UTF-8 de café-2.png.
• Le troisième nom de fichier est la séquence d'octets 63 61 66 e9 2e 70 6e 67- dans la page de code 1252, c'est café.png. Ce n'est cependant pas un encodage UTF-8 valide. e9commence une séquence de codage de caractères incomplète.

Donc, ce qui se passe, c'est que les choses n'utilisent pas la page de codes 1252 mais qui utilisent UTF-8, à savoir votre session SSH et votre émulateur de terminal local, gèrent l' UTF-8 valide de la même manière que les autres mais gèrent l' UTF-8 invalide de deux manières différentes:

• Celui qui affiche le graphique de bloc utilise très probablement simplement ce graphique de bloc comme caractère de sortie de remplacement général pour les séquences UTF-8 non valides.
• Celui qui affiche la lettre érevient à la page de code 1252 lorsqu'il rencontre un codage non valide.

Votre problème sous-jacent est un système qui génère en quelque sorte des noms de fichiers encodés en UTF-8 et d'autres noms de fichiers encodés dans la page de code 1252.