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


11

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.


1
C'est une question de client (PuTTY, etc.), et de leur configuration, et non pertinente pour Windows. Pour PuTTY, cela se fait dans la section de traduction .
Thomas Dickey

2
Il semble un peu comme si le é dans "café-2.png" est codé UTF-8, mais le é dans "café.png" est codé ISO-8859-1. Pouvez-vous courir python -c "import sys; print(repr(sys.argv[1]))" café-2.pnget python -c "import sys; print(repr(sys.argv[1]))" café.png?
Oskar Skog

@OskarSkog Je vais essayer ça le matin. Mais j'ai toujours pensé que les noms de fichiers n'avaient pas «d'encodage», en d'autres termes: c'est comme le système d'exploitation le veut. Cela signifierait-il donc que les différents fichiers ont été créés sur différents systèmes d'exploitation? (Nous n'avons aucun contrôle sur l'origine des fichiers.)
Bram Vanroy

Sur les systèmes d'exploitation Unix, le nom de fichier n'est qu'une chaîne d'octets. Le concept de personnages se situe à un niveau supérieur.
Oskar Skog

1
Pas même proche d'une réponse, ou d'une solution, simplement une réflexion sur la voie à suivre. De l'OP, il semble que les fichiers peuvent avoir des origines variées, sans contrôle sur le nom généré par la source, et il est trop tard pour appliquer des filtres pour corriger le snafus de nom de fichier entrant. La solution impliquera probablement l'exécution d'un script sur le serveur capable de détecter et de corriger les erreurs de nom de fichier, voire de standardiser le jeu de caractères / page de codes utilisé pour les noms. Ensuite, l'OP peut utiliser la même page de codes dans Filezilla ou un autre client, et les choses fonctionneront. Au-delà de mes compétences, mais une piste à suivre, peut-être.
user207673

Réponses:


11

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.


Je ne suis pas d'accord pour dire que Windows n'a rien à voir avec cela. Cela ne se produirait probablement pas sur d'autres Linux. Le problème est l'encodage par défaut, et afaik Windows a (ou du moins a eu) utilisé son CP et non UTF, ce qui se produit même sur le même système d'exploitation à travers les pays. Vous pouvez reproduire cela sur Linux, mais Linux est plus cohérent dans le choix d'Unicode
MatthewRock

Salut! Merci pour la réponse élaborée. Vous vous concentrez sur ce qui se passe, ce qui est bien: j'aime toujours comprendre ce qui se passe. Mais pourriez-vous peut-être nous expliquer pourquoi cela se produit et comment nous pouvons contrer les problèmes qui découlent de cette incohérence? J'ai ajouté deux paragraphes pour clarifier ce que je veux dire.
Bram Vanroy

Je me demande pourquoi les deux "cafés" sont montrés identiques alors qu'ils ne le sont pas. Est-ce que ls (1) de GNU a une gestion ridicule des erreurs de codage?
Oskar Skog

@MatthewRock Dans ce cas, je pense que Windows n'a vraiment rien à voir avec cela. Je ne suis pas satisfait de la plupart de ce que fait M $, et j'admets volontiers bon nombre de ses maux, mais je ne vois aucun blâme là où aucun n'est dû. Comme la réponse le montre clairement, le problème vient des valeurs d'octet des noms eux-mêmes. Dans ce cas, Windows a exposé le symptôme, mais ce n'est pas le problème. Pas plus que le thermomètre n'est le problème quand il montre que votre fièvre est de 104 °. Le problème provient de tous les processus qui ont créé les noms sur le serveur contenant les fichiers auxquels l'OP tente d'accéder.
user207673

Pourriez-vous fournir plus d'informations et des solutions possibles? Sinon, j'ai dépensé ma prime pour rien.
Bram Vanroy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.