Posté par DerekSagan .
En réponse à la dépêche Mosh, the Mobile Shell.
Évalué à 6.
Dernière modification le 18 avril 2012 à 09:22.
Il n'y a pas de moyen de connaitre l'encoding d'un nom de fichier
Oui c'est pour ça qu'il ne faut en utiliser qu'un seul pour tous les fichiers d'un filesystem donné. Et tant qu'à en utiliser qu'un seul, UTF-8 n'est pas pire qu'ASCII-7.
Un bien bel exemple de ce qui se passe quand deux programmes écrivent des noms de fichiers dans le même filesystems avec des encodages différents.
Cela dit si ce n'était pas une image et que tu écrivais vraiment coréen, tu ne serais pas en train de mener un combat d'arrière garde pro ISO-8859, justement.
tout le monde utilise exclusivement un encoding. Par exemple UTF-8, mais les asiatiques vont faire la gueule.
Les asiatiques sont censés faire la gueule d'avoir enfin un encodage qui permette de représenter tous les caractères dont ils peuvent avoir besoin et qui est interopérable et supporté par le monde occidental (celui qui considérait que 7 bits c'était assez) ?
Il y a sûrement quand même quelques asiatiques qui comme toi sont attachés à leurs anciens encodages qui leur font gagner quelques % d'espace disque sur le texte non compressé ou à pester (à juste titre) contre le fait que tous les logiciels qu'ils utilisent n'en sont pas au même stade de support d'UTF-8… mais globalement, UTF-8 c'est un progrès pour l'Asie…
Je reconnais qu'on pourrait utiliser GB18030 au lieu d'UTF-8, avec le même intérêt et les mêmes bonnes propriétés. Mais comme 80% des logiciels sont faits en Amérique du nord ou en Europe, ça n'a pas beaucoup de chance de se produire. Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
Pour éviter ce genre de conneries, la seule bonne méthode pour l'instant, en attendant que UTF-8 conquiert le monde entier ou que de meta apparaissent dans les filesystems c'est
a) D'utiliser exclusivement les caractères ANSI dans le noms de fichier qui peuvent être exportés
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? Parce que c'est plus sûr si tu ne veux pas foute le bordel chez les gens qui utilisent UTF-8 avec des séquences interdites (ah oui… mais eux on s'en fiche c'est leur faute ils n'ont qu'à pas utiliser UTF-8).
En fait ce n'est même pas ASCII-7 mais ASCII-7 sans certains caractères parce que sinon ça créera d'autres problèmes sur certains OS (genre / sous Unix, \ : * ? sous Windows, : sous MacOS9, ; sous VMS, et j'en oublie). Voire sans espaces aussi. Bref t'as droit à une soixantaine de caractères si tu veux pas être emmerdé, ça passerait dans de l'ASCII-6 en fait ;-)
C'est vraiment dur les noms de fichiers. Donc soit tu n'utilises que des lettres ASCII-7 des chiffres et des underscores, soit tu as un et un seul encodage pour tout ton filesystem et à chaque fois que tu as une interface (ftp, sftp, webdav, git clone, unzip) tu t'assures de ne pas injecter de la merde.
Mais le problème existait avant UTF-8.
Et si t'as déjà plein de merde sur ton filesystem, tu peux aussi essayer convmv (yum/apt-get install convmv) pour qu'il te nettoie les choses sans que tu aies à gesticuler avec des "LANG=C mv toto*foo toto_foo" fais à la main.
Mais fais attention, installer convmv pourrait être la première étape à convertir tout ton filesystem en noms en UTF-8, le Mal pourrait t'atteindre…
b) De passer en locale C avant tout git-clone, unzip, ./script.sh etc. Et seulement si ca ne marche pas de repasser dans la locale présumée du truc mais en faisant très gaffe à ce qu'on fait.
Ah au fait, repasser en locale C est la bonne solution pour shooter un fichier dont le nom en UTF-16 qui contient des caractères UTF-8 invalides. Des fois que ca interresse quelqu'un…
Sauf que dans un shell UTF-8 pur, ben on peut pas repasser en locale C.
Là si je peux me permettre, tu confonds les effets de LANG sur le shell et sur les processus que tu lances. Si tu fixes LANG=C avant un git clone, tout va fonctionner car git clone ne t'enverra que de l'étatsunien en ascii7 qui ne donnera pas de bouton au shell (ni à ton émulateur de terminal) et git lui-même étant configuré en C et pas en C.UTF-8 créera les fichiers en conséquences. Avec toutes les limites que ça a (et que ça a déjà avec ton SSH à la place de Mosh), en particulier les commentaires de commit qui sont conventionnellement écris en UTF-8, mais tu t'en fous c'est pas le nom du fichier c'est son contenu.
Dit autrement ça marche indépendamment du shell.
Même raisonnement avec unzip (encore que de toute façon le format zip gère vraiment très mal l'encodage des noms de fichiers).
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
[^] # Re: Bof
Posté par DerekSagan . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 6. Dernière modification le 18 avril 2012 à 09:22.
Oui c'est pour ça qu'il ne faut en utiliser qu'un seul pour tous les fichiers d'un filesystem donné. Et tant qu'à en utiliser qu'un seul, UTF-8 n'est pas pire qu'ASCII-7.
Un bien bel exemple de ce qui se passe quand deux programmes écrivent des noms de fichiers dans le même filesystems avec des encodages différents.
Cela dit si ce n'était pas une image et que tu écrivais vraiment coréen, tu ne serais pas en train de mener un combat d'arrière garde pro ISO-8859, justement.
Les asiatiques sont censés faire la gueule d'avoir enfin un encodage qui permette de représenter tous les caractères dont ils peuvent avoir besoin et qui est interopérable et supporté par le monde occidental (celui qui considérait que 7 bits c'était assez) ?
Il y a sûrement quand même quelques asiatiques qui comme toi sont attachés à leurs anciens encodages qui leur font gagner quelques % d'espace disque sur le texte non compressé ou à pester (à juste titre) contre le fait que tous les logiciels qu'ils utilisent n'en sont pas au même stade de support d'UTF-8… mais globalement, UTF-8 c'est un progrès pour l'Asie…
Je reconnais qu'on pourrait utiliser GB18030 au lieu d'UTF-8, avec le même intérêt et les mêmes bonnes propriétés. Mais comme 80% des logiciels sont faits en Amérique du nord ou en Europe, ça n'a pas beaucoup de chance de se produire. Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? Parce que c'est plus sûr si tu ne veux pas foute le bordel chez les gens qui utilisent UTF-8 avec des séquences interdites (ah oui… mais eux on s'en fiche c'est leur faute ils n'ont qu'à pas utiliser UTF-8).
En fait ce n'est même pas ASCII-7 mais ASCII-7 sans certains caractères parce que sinon ça créera d'autres problèmes sur certains OS (genre / sous Unix, \ : * ? sous Windows, : sous MacOS9, ; sous VMS, et j'en oublie). Voire sans espaces aussi. Bref t'as droit à une soixantaine de caractères si tu veux pas être emmerdé, ça passerait dans de l'ASCII-6 en fait ;-)
C'est vraiment dur les noms de fichiers. Donc soit tu n'utilises que des lettres ASCII-7 des chiffres et des underscores, soit tu as un et un seul encodage pour tout ton filesystem et à chaque fois que tu as une interface (ftp, sftp, webdav, git clone, unzip) tu t'assures de ne pas injecter de la merde.
Mais le problème existait avant UTF-8.
Et si t'as déjà plein de merde sur ton filesystem, tu peux aussi essayer convmv (yum/apt-get install convmv) pour qu'il te nettoie les choses sans que tu aies à gesticuler avec des "LANG=C mv toto*foo toto_foo" fais à la main.
Mais fais attention, installer convmv pourrait être la première étape à convertir tout ton filesystem en noms en UTF-8, le Mal pourrait t'atteindre…
Là si je peux me permettre, tu confonds les effets de LANG sur le shell et sur les processus que tu lances. Si tu fixes LANG=C avant un git clone, tout va fonctionner car git clone ne t'enverra que de l'étatsunien en ascii7 qui ne donnera pas de bouton au shell (ni à ton émulateur de terminal) et git lui-même étant configuré en C et pas en C.UTF-8 créera les fichiers en conséquences. Avec toutes les limites que ça a (et que ça a déjà avec ton SSH à la place de Mosh), en particulier les commentaires de commit qui sont conventionnellement écris en UTF-8, mais tu t'en fous c'est pas le nom du fichier c'est son contenu.
Dit autrement ça marche indépendamment du shell.
Même raisonnement avec unzip (encore que de toute façon le format zip gère vraiment très mal l'encodage des noms de fichiers).
(bon j’arrête là parce qu'on est légèrement off topic quand même…)