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.
ASCII-7 (ou même ANSI complet sur toute la plage 32-255) va créer des erreurs d'affichage, UTF-8 va créer des erreurs d'execution. C'est largement pire.
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.
Tu ne travailles qu'avec des gens en qui sont en pur UTF-8 ? Et eux-même ne travaillent qu'avec des gens qui sont en pur UTF-8 ? Parceque sinon tu prends le risque de mélanger les encodings à un moment ou à un autre. Rien que les sources du kernel linux ne passent pas un "make menuconfig" proprement. (Bon c'est juste moche, pas de dégats collatéraux - mais justement parceque les devs utilisent exclusivement ANSI dans le nommage des fichiers)
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) ?
Plutôt oui. Déjà si ils prennent un encoding ce sera UTF-16, pas UTF-8 sinon une grosse partie des caractères va se retrouver à occuper 4 octects au lieu de 2. Sur un ordinateur normal on s'en fout un peu (et encore, bonjour la gueule des bases de données) mais sur une solution embarquée ca ne passe juste pas.
Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
GB18030-2005 est justement la réponse de la Chine à UTF-8/UTF-16 qui reste compatible avec ASCII et l'ancien système GBK. Ils ont créé ce système à cause des nombreux problèmes que l'on peut rencontrer avec UTF-8 et UTF-16. Il couvre tout unicode (et largement même) donc rien n'empêche d'écrire en japonais avec GB18030-2005, mais il est peut rentable pour les caractères japonais ou corééns qui vont systématiquement se retrouver sur 4 octets.
De façon générale tout pays va chercher à faire un encoding qui
a) fait un mapping direct des caractères ASCII
b) dans la mesure du possible fait un mapping direct de l'ancienne norme en vigueur.
c) economise un maximum de place pour les caractères les plus utilisés dans le pays.
GB18030 est juste cela, un enconding qui respecte ASCII, GBK et qui essaye de mettre d'autres caractères dans les trous disponibles.
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? ….. Mais le problème existait avant UTF-8.
Non le problème n'éxistait pas avant UTF-X. Certes il y avait déjà des caractères illégaux dans les noms de fichier, mais un caractère illégal n'a rien à voir avec un caractère interdit. En ASCII je vais juste me dire "mais quel est le con qui a foutu un CR dans un nom de fichier", en UTF-8 ca va donner un truc du genre "le nom de fichier n'est pas décodable, on fait quoi ?".
La norme UTF-8 (qui fort heureusement n'est pas respectée dans ce cas) dit qu'il faut dropper la séquence - donc pour un filesystem je me retrouve avec un fichier invisible et innacessible complètement, du moins jusqu'à ce que je change ma locale.
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.
Et tu t'en assures comment ? Un collègue sous windows t'envoies un .rar, un vieux logiciel métier sur une babasse de dix ans d'age a son code prisonnier dans un tar.gz. Tu fais quoi ? Perso je repasse en locale C, tout autre aproche étant casse gueule.
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.
Oui, et là tu te rends compte que pour lancer la compilation/faire fonctionner l'ETL/linker/ecrire dans le log etc. tu dois te frapper 8500 à la mano et en éditer le contenu (prie pour qu'il n'y ait pas trop de binaires dans le lot). En plus convmv ca me sert principalement à réparer les anneries faites par une personne qui pensait gagner du temps en l'utilisant. convmv est en perl, ce qui veut dire qu'il faut régler les locales et autres charmap de ton interpreteur perl avant de lancer la moindre conversion. Et si tu as des fichiers de plusieurs origines dans plusieurs encodings il vaut mieux reconfigurer entre chaque lot.
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
Déjà c'est pas juste LANG, mais toute la locale que je repasse en C et ensuite même si j'en ai rien à fiche des commentaires de commit (alors que bon en vrai ca m'interresse un peu) GIT ne dispose pas de moyen de modifier le code source à l'intérieur du contenu. Donc les fichiers auront des noms propres, mais je vais devoir me rééditer tout le contenu à la mano pour reprendre les includes, les chemins, les libs etc. Et quand le dev original voudra synchroniser il va se retrouver avec une tonne de modifs complètement con et les deux lignes de correction de bugs vont passer à la trappe, noyées sous un flot de destruction de fichiers et de création de nouveau fichiers. Bref GIT ne servira à rien et sera même contre productif. Seule solution => ASCII/ANSI.
(et que ça a déjà avec ton SSH à la place de Mosh)
Si ton SSH est en pur UTF-8 oui. Mais le truc c'est que justement le pur UTF-8 en shell ca ne marche pas. Maintenant moyennant deux ou trois essai j'arriverai à caler ma locale sur celle du dev et quand je travaillerais sur ce repo je passerais dans cette locale. C'est ce que mosh ne permet pas.
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
On est pas off-topic du tout. La question est "un shell pur UTF-8, bonne ou mauvaise idée". Pour moi c'est une très mauvaise idée, pour toutes les raisons exposées.
[^] # Re: Bof
Posté par Kaane . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 1.
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.
ASCII-7 (ou même ANSI complet sur toute la plage 32-255) va créer des erreurs d'affichage, UTF-8 va créer des erreurs d'execution. C'est largement pire.
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.
Tu ne travailles qu'avec des gens en qui sont en pur UTF-8 ? Et eux-même ne travaillent qu'avec des gens qui sont en pur UTF-8 ? Parceque sinon tu prends le risque de mélanger les encodings à un moment ou à un autre. Rien que les sources du kernel linux ne passent pas un "make menuconfig" proprement. (Bon c'est juste moche, pas de dégats collatéraux - mais justement parceque les devs utilisent exclusivement ANSI dans le nommage des fichiers)
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) ?
Plutôt oui. Déjà si ils prennent un encoding ce sera UTF-16, pas UTF-8 sinon une grosse partie des caractères va se retrouver à occuper 4 octects au lieu de 2. Sur un ordinateur normal on s'en fout un peu (et encore, bonjour la gueule des bases de données) mais sur une solution embarquée ca ne passe juste pas.
Et comme seule la Chine utilise GB18030, on ne peut même pas parler de norme asiatique… (va faire du GB18030 au Japon…)
GB18030-2005 est justement la réponse de la Chine à UTF-8/UTF-16 qui reste compatible avec ASCII et l'ancien système GBK. Ils ont créé ce système à cause des nombreux problèmes que l'on peut rencontrer avec UTF-8 et UTF-16. Il couvre tout unicode (et largement même) donc rien n'empêche d'écrire en japonais avec GB18030-2005, mais il est peut rentable pour les caractères japonais ou corééns qui vont systématiquement se retrouver sur 4 octets.
De façon générale tout pays va chercher à faire un encoding qui
a) fait un mapping direct des caractères ASCII
b) dans la mesure du possible fait un mapping direct de l'ancienne norme en vigueur.
c) economise un maximum de place pour les caractères les plus utilisés dans le pays.
GB18030 est juste cela, un enconding qui respecte ASCII, GBK et qui essaye de mettre d'autres caractères dans les trous disponibles.
Tu veux dire utiliser exclusivement les caractères ASCII-7 ? ….. Mais le problème existait avant UTF-8.
Non le problème n'éxistait pas avant UTF-X. Certes il y avait déjà des caractères illégaux dans les noms de fichier, mais un caractère illégal n'a rien à voir avec un caractère interdit. En ASCII je vais juste me dire "mais quel est le con qui a foutu un CR dans un nom de fichier", en UTF-8 ca va donner un truc du genre "le nom de fichier n'est pas décodable, on fait quoi ?".
La norme UTF-8 (qui fort heureusement n'est pas respectée dans ce cas) dit qu'il faut dropper la séquence - donc pour un filesystem je me retrouve avec un fichier invisible et innacessible complètement, du moins jusqu'à ce que je change ma locale.
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.
Et tu t'en assures comment ? Un collègue sous windows t'envoies un .rar, un vieux logiciel métier sur une babasse de dix ans d'age a son code prisonnier dans un tar.gz. Tu fais quoi ? Perso je repasse en locale C, tout autre aproche étant casse gueule.
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.
Oui, et là tu te rends compte que pour lancer la compilation/faire fonctionner l'ETL/linker/ecrire dans le log etc. tu dois te frapper 8500 à la mano et en éditer le contenu (prie pour qu'il n'y ait pas trop de binaires dans le lot). En plus convmv ca me sert principalement à réparer les anneries faites par une personne qui pensait gagner du temps en l'utilisant. convmv est en perl, ce qui veut dire qu'il faut régler les locales et autres charmap de ton interpreteur perl avant de lancer la moindre conversion. Et si tu as des fichiers de plusieurs origines dans plusieurs encodings il vaut mieux reconfigurer entre chaque lot.
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
Déjà c'est pas juste LANG, mais toute la locale que je repasse en C et ensuite même si j'en ai rien à fiche des commentaires de commit (alors que bon en vrai ca m'interresse un peu) GIT ne dispose pas de moyen de modifier le code source à l'intérieur du contenu. Donc les fichiers auront des noms propres, mais je vais devoir me rééditer tout le contenu à la mano pour reprendre les includes, les chemins, les libs etc. Et quand le dev original voudra synchroniser il va se retrouver avec une tonne de modifs complètement con et les deux lignes de correction de bugs vont passer à la trappe, noyées sous un flot de destruction de fichiers et de création de nouveau fichiers. Bref GIT ne servira à rien et sera même contre productif. Seule solution => ASCII/ANSI.
(et que ça a déjà avec ton SSH à la place de Mosh)
Si ton SSH est en pur UTF-8 oui. Mais le truc c'est que justement le pur UTF-8 en shell ca ne marche pas. Maintenant moyennant deux ou trois essai j'arriverai à caler ma locale sur celle du dev et quand je travaillerais sur ce repo je passerais dans cette locale. C'est ce que mosh ne permet pas.
(bon j’arrête là parce qu'on est légèrement off topic quand même…)
On est pas off-topic du tout. La question est "un shell pur UTF-8, bonne ou mauvaise idée". Pour moi c'est une très mauvaise idée, pour toutes les raisons exposées.