Linux? - Page 156

Perso, j'ai toujours pensé que l'UTF-8 était une fausse bonne idée particulièrement dangereuse...

Explique?

Schrödinger's box… bien trouvé. Hein ? Quoi ? On devrait y voir un chat ?

Ta police est incomplète (regarde les commentaires en bas )

Sinon, je vois bien la distro qui prend pour non New line\r\nNew future

(aaaaah, pour nom, j'ai mis du temps à comprendre )

./4652 > Je vais répondre à la place de Zerosquare, mais en gros l'UTF-8 est vendu comme un moyen de transporter de l'Unicode là où l'ASCII étendu (8 bits) est autorisé, sans avoir besoin d'adapter les applications de transport de flux, contrairement à UTF-16 ou UTF-32 qui introduiraient des zéro dans le flux. (J'imagine que tu sais déjà tout ça, mais bon)

(Fausse bonne idée) C'est génial pour tous les scripts utilitaires unix qui fonctionnent avec des chaînes binaires 8 bits terminées par un zéro, parce que du coup tu n'as pas besoin de les mettre à jour pour supporter ce nouvel encodage. (risque élevé d'ajouter de nouveaux bugs) Donc tout marche déjà sans que tu n'aies rien à faire… !

Sauf qu'en pratique, et à part quelques exceptions, les applications ont toujours — un peu, ou même beaucoup — besoin de comprendre ce qui transite par elles. Et c'est là que toute la logique tombe à l'eau.
Tu finis tôt ou tard par devoir corriger chaque application pour ajouter un support explicite UTF-8. (Mais le plus tard possible parce qu'on a vraiment pas envie de le faire… ^^)

Au final tu as juste fonctionné pendant des années avec un support partiel et bogué de la chose sans t'en préoccuper, ce qui ne signifie pas pour autant que des utilisateurs ça et là n'aient pas été incommodés par la chose; mais tu n'en avais rien à foutre, donc ils essayaient de contourner les problèmes, par exemple en évitant de mettre des accents "parce que ça pose des problèmes"… (Parfait exemple de non-solution)

À titre d'exemple tout con, un shell comme bash, zsh, ou autre, si codé sans support spécifique UTF-8, ne va pas comprendre ce qui lui arrive en recevant certaines séquences de caractères UTF-8 à partir du [driver du] clavier… Inutile de mentionner que l'expérience utilisateur est alors complètement à chier… (Je ne mentionne pas ça au hasard…)


(Y'a souvent le même genre de problème avec les espaces dans les noms de fichiers aussi… On va te répondre "ben ne mets pas d'espace ! ", et là tu te diras "belle mentalité !" )

jevaisrepondrealaplacedezerosquare,maisengrosl'utf-8estvenducommeunmoyendetransporterdel'unicodelaoul'asciietendu(8bits)estautorise,sansavoirbesoind'adapterlesapplicationsdetransportdeflux,contrairementautf-16ouutf-32quiintroduiraientdeszerodansleflux.(j'imaginequetusaisdejatoutça,maisbon)

(faussebonneidee)c'estgenialpourtouslesscriptsutilitairesunixquifonctionnentavecdeschaînesbinaires8bitstermineesparunzero,parcequeducouptun'aspasbesoindelesmettreajourpoursupportercenouvelencodage.(risqueeleved'ajouterdenouveauxbugs)donctoutmarchedejasansquetun'aiesrienafaire…!

saufqu'enpratique,etapartquelquesexceptions,lesapplicationsonttoujours—unpeu,oumemebeaucoup—besoindecomprendrecequitransiteparelles.etc'estlaquetoutelalogiquetombeal'eau.
tufinistôtoutardpardevoircorrigerchaqueapplicationpourajouterunsupportexpliciteutf-8.(maisleplustardpossibleparcequ'onavraimentpasenviedelefaire…^^)

aufinaltuasjustefonctionnependantdesanneesavecunsupportpartieletboguedelachosesanst'enpreoccuper,cequinesignifiepaspourautantquedesutilisateursçaetlan'aientpaseteincommodesparlachose;maistun'enavaisrienafoutre,doncilsessayaientdecontournerlesproblemes,parexempleenevitantdemettredesaccents"parcequeçaposedesproblemes"…(parfaitexempledenon-solution)

atitred'exempletoutcon,unshellcommebash,zsh,ouautre,sicodesanssupportspecifiqueutf-8,nevapascomprendrecequiluiarriveenrecevantcertainessequencesdecaracteresutf-8apartirdu[driverdu]clavier…inutiledementionnerquel'experienceutilisateurestalorscompletementachier…(jenementionnepasçaauhasard…)


(y'asouventlememegenredeproblemeaveclesespacesdanslesnomsdefichiersaussi…onvaterepondre"bennemetspasd'espace!",etlatutediras"bellementalite!")

?

(Fais gaffe, tu as laissé des — dans le texte, ça risque de ne pas passer à la moulinette ! ^^)

Bon sinon, intéressant cette histoire de flux sans 0, ça parait une bonne idée en effet, j'ignorais tout ça merci ^^

(je viens de voir les tirets longs )

Voilà, comme le dit GC, c'est une solution qui évite de devoir réécrire les applis pour qu'elles soient compatibles Unicode... sauf qu'en pratique, ça donne surtout l'illusion que ça marche, mais en introduisant des tas de problèmes vicieux.

Je pense qu'il aurait fallu faire le contraire : choisir un standard incompatible avec les fonctions existantes, de manière à ce que les bugs soient immédiatement apparents. Et tant qu'à faire, imposer que les textes Unicode commencent par un BOM, pour pouvoir les détecter de manière sûre, au lieu de jouer aux devinettes comme c'est le cas actuellement.

À ce sujet, l'expérience de Python est instructive.

Dans Python 2, il y a deux types de chaînes
"toto" => type("toto") == str
u"toto" => type(u"toto") == unicode

Le premier ne peut contenir que des caractères ASCII, ce sont en fait des tableaux d'octets.
Le second représente une chaîne unicode, qu'il faut encoder (par exemple en UTF-8) pour avoir un tableau d'octets.
type(u"toto".encode(u'utf-8')) == str
type("toto".decode(u'utf-8')) == unicode

Idéalement, il faudrait toujours utiliser u"toto" quand on utilise du texte. Mais en pratique, on oublie le préfixe u, sauf quand il y a des accents.
u"toto" + "titi" fonctionne (concaténation), tout comme "titi" + u"toto" . Par contre, "titi" + u"tête" ne passe pas (il sait convertir de façon transparente une chaîne ASCII valide en unicode, mais pas encoder à la voler vu qu'il ne saurait pas quel encodage utiliser).

Au final, il y a beaucoup de bugs liés à ça, qui ne sont déterminés que quand on utilise des caractères accentués...


En Python 3, ils ont pris le taureau par les cornes, et ils ont corrigé cet (énorme, à mes yeux) problème de conception.
b"toto" représente un tableau d'octets
"toto" représente une chaîne de caractères unicode, et la concaténation ne fonctionne plus du tout entre les deux.
Du coup, on repère les bugs immédiatement.

Au final, il est assez difficile d'avoir des bugs d'encodage en Python 3, alors qu'il est très facile d'en avoir en Python 2. Bref, ça montre bien que la tentative du passage transparent de l'ASCII à l'Unicode a été catastrophique, et je pense que tout le monde est d'accord pour dire que c'est *LE* souci de Python 2.

GC/0² > OK, je me doutais qu'UTF-8 c'était du 8bit, mais je ne connaissais pas tous les détails, vu comme ça en effet l'UTF-8 est plus un cautère sur une jambe de bois que quelque chose d'utilisable sérieusement.

l'autre raison d'UTF-8, c'est que ça consomme moins de place. Les caractères les plus utilisés sont encodés sur 8 bits, ceux moins utilisés (accents, par exemple) sur 16 bits, puis encore plus rares sur 32 bits.
C'est plus chiant dans certains langages de programmation (pour déterminer la longueur d'une chaîne, ce n'est pas juste nombre de bits / 8), mais ça ne consomme pas trop.

En gros, ça donne en moyenne 30% de plus par rapport à de l'ASCII pour l'UTF-8.
L'UTF-32, en comparaison, encode tout sur 32 bits, donc x 4 en taille par rapport à l'ASCII.

Ah oui, je comprends.

./4661 > Ça a l'air intéressant comme solution. Est-ce que tu es autorisé à mettre des caractères ≥ 128 dans tes tableaux d'octets du coup ? Si oui, comment ça se passe au niveau encodage ?
./4662 > Attention quand, même, on ne veut pas dire que l'UTF-8 c'est le mal. Tout dépend juste à quel sauce tu le mets.
./4663 > Ouais, pour la plupart des langages basés sur les caractères latins, UTF-8, c'est super niveau transfert et stockage de données. Pour les autres, moins… (Enfin après, ça dépend du texte, quoi.)
Et l'UTF-32, ça ne sert à rien (Sérieusement, ça coûte trop cher pour ce que a apporte)

GoldenCrystal (./4665) :
./4661 > Ça a l'air intéressant comme solution. Est-ce que tu es autorisé à mettre des caractères ≥ 128 dans tes tableaux d'octets du coup ? Si oui, comment ça se passe au niveau encodage ?

Oui, sans problème (heureusement !).

Simplement, tu auras des soucis si tu fais un .decode('utf-8') si ton tableau d'octets ne représente pas des caractères unicode valides (logique).
Tout est fait pour qu'il n'y ait plus de confusion possible entre les tableaux représentant des données binaires quelconques et les chaînes de caractères.
Les chaînes de caractères ne sont pas encodées (tu n'as pas à savoir qu'en interne c'est de l'UTF-16LE, par exemple, tu sais juste que c'est de l'unicode).
L'incompatibilité entre tableaux d'octets et chaînes est vraiment bénéfique, tu n'as plus à te poser des questions sur la gestion des caractères accentués.

Mais du coup, ce qui rentre dans ton tableau d'octets dépend de l'encodage du fichier source, c'est bien ça ?
(Si oui je trouve que c'est quand même un problème ^^)

flanker (./4663) :
L'UTF-32, en comparaison, encode tout sur 32 bits, donc x 4 en taille par rapport à l'ASCII.

Oui, mais du coup tu dois avoir énormément de séquences compressibles avec un Ziv-Lampel ou équivalent, non ?

GoldenCrystal (./4667) :
Mais du coup, ce qui rentre dans ton tableau d'octets dépend de l'encodage du fichier source, c'est bien ça ?
(Si oui je trouve que c'est quand même un problème ^^)

À moitié : par défaut, l'encodage d'un fichier python est ASCII pour Python 2, UTF-8 pour Python 3.

Si ce n'est pas le cas, il faut spécifier l'encodage dans la première ligne, avec quelque chose du genre :
#-*- coding = utf-8 -*-

Donc oui, ça dépend de l'encodage, mais celui-ci est connu par Python, donc ça ne pose pas de problème ^^


Nil > certes, mais c'est chiant de devoir tout compresser, non ? ceci dit, le texte ne doit plus représenter grand-chose actuellement… sauf sur internet, mais c'est compressé de façon transparente.

flanker (./4669) :
Nil > certes, mais c'est chiant de devoir tout compresser, non ? ceci dit, le texte ne doit plus représenter grand-chose actuellement… sauf sur internet, mais c'est compressé de façon transparente.

Oui, mais c'est ce que je veux dire : c'est quasi partout compressé, et les documents qui sont susceptibles d'accueillir le plus de texte formaté (docx et odt) sont finalement compressés. Du coup, on s'en fiche un peu que ça prenne tant de place, non ?
Enfin, remarque, si, quand tu as du traitement à faire sur de grosses données de texte, ça influe peut-être.

./4669 > Ah si c'est spécifié dans chaque fichier, ça va alors… C'est pas une solution trop tordue au moins ^^
(Après j'ai quand même toujours un peu de mal avec le fait de vouloir représenter des données binaires via des caractères textuels…)

./4668> Oui, parce que tu auras toujours un octet entièrement nul… En général deux… Et même, pour les langues basées sur les caractères latin, souvent trois.
Par contre, on peut fortement supposer que la compression sera meilleure avec UTF-32BE qu'avec UTF-32LE.

GoldenCrystal (./4665) :
./4662 > Attention quand, même, on ne veut pas dire que l'UTF-8 c'est le mal. Tout dépend juste à quel sauce tu le mets.

Je déteste cette tournure 'c'est le mal', j'ai toujours eu le sentiment que c'était un détournement maladroit de 'c'est mal' dont on a abusé parce que les gens adorent faire de barbarismes des tics de langage à la mode (comme l'infernal 'du coup', usé et abusé à la télé).

TL;DR, tout ça pour dire que non je n'irais pas dire 'c'est le mal', je dirais au maximum 'c'est mal' parce que c'est emmerdant à implémenter même si ça se révèle utile.

le mal… le malin… le diable… satan… non ? (C'est toujours comme ça que je l'ai compris ^^)

./4670 > C'est tout pourri pour le traitement des données, ça nécessite un débit mémoire double, et ça remplit le cache deux fois plus que nécessaire (déjà qu'à ce niveau là, UTF-16 puisse être discutable). En plus, c'est un énorme gâchis de place pour un jeu de caractères qui tient sur 21 bits (et non pas 32), sachant que l'essentiel des caractères utiles (réalistement…) tient dans un seul caractère 16 bit UTF-16 (et deux pour les autres, comme par exemple les emoji, ou diverses langues mortes) ou 2 à 3 caractères UTF-8.

Ben oui, c'est le Mal Absolu !

GoldenCrystal (./4671) :
./4669 > Ah si c'est spécifié dans chaque fichier, ça va alors… C'est pas une solution trop tordue au moins ^^

Comme l'encodage par défaut est bien précisé (et qu'en plus c'est de l'UTF-8), ça ne pose pas trop de souci.

(Après j'ai quand même toujours un peu de mal avec le fait de vouloir représenter des données binaires via des caractères textuels…)

, mais c'est parfois bien pratique pour des petites données

menteur, j'ai déjà vu de toi des dc.b

J'étais jeune, à l'époque !

GoldenCrystal (./4673) :
le mal… le malin… le diable… satan… non ? (C'est toujours comme ça que je l'ai compris ^^)

J'y voyais un ton de prédicateur, mais j'y voyais surtout un barbarisme, enfin bref.

Brunni (./4646) :
on pourrait dire la même chose de LaTeX vu la portabilité des documents qui dépend de ton install

LaTeX fait très attention à ce que les sources soient portables. (La sortie l'est forcément, c'est du PDF.) Le seul ennui que tu peux avoir, c'est qu'il te manque un paquetage, et dans ce cas, tu installe le paquetage qui te manque (comme indiqué par le message d'erreur) et c'est bon. Les paquetages font normalement très attention à garder la compatibilité antérieure. (C'est aussi pour ça qu'il faut parfois écrire quelques lignes pour avoir un bon comportement par défaut.)

Au fait, une astuce pour LaTeX: Il est conseillé de mettre ça dans l'entête de tous vos documents:

\usepackage[T1]{fontenc}
\usepackage{lmodern}

Sans la première ligne, LaTeX utilise le codage OT1 qui ne gère les accents qu'à travers des hacks qui cassent le découpage en syllabes. Et avec seulement la première ligne, comme la police Computer Modern n'est pas en Type1, LaTeX utilise des polices bitmap Type3 qui rendent très mal, surtout à l'écran. (C'est de là que viennent ces affreux PDFs avec les polices foireuses.) La deuxième ligne dit donc à LaTeX d'utiliser Latin Modern, la version Type1 de Computer Modern (non officielle, d'où le nom différent), ce qui donne des PDFs avec des polices au rendu professionnel.

flanker (./4647) (posté le 8 septembre 2013):
Tiens, Kevin, y a-t-il un tram de Vienne à Paris ? http://linuxfr.org/news/rencontres-fedora-19-a-paris-le-7-septembre-2013--2

Et surtout, le tram fait-il des voyages dans le temps?

Et de toute façon, c'était un évènement local.

Folco (./4648) :
https://lwn.net/Articles/545741/
Intéressant, vers une résolution des problèmes liés à l'unicode ? ^^

Faut pas exagérer les problèmes aussi. Le caractère le plus problématique était l'apostrophe vertical, un caractère ASCII. Les caractères UTF-8 ne posent problème que dans les environnements minimaux au tout début du processus de démarrage, qui n'étaient pas prévus pour afficher autre chose que de l'ASCII. (C'est corrigé ou en cours de correction.) Une fois le système démarré, l'UTF-8 marche sans traîtement spécial.

Zerosquare (./4660) :
Je pense qu'il aurait fallu faire le contraire : choisir un standard incompatible avec les fonctions existantes, de manière à ce que les bugs soient immédiatement apparents. Et tant qu'à faire, imposer que les textes Unicode commencent par un BOM, pour pouvoir les détecter de manière sûre, au lieu de jouer aux devinettes comme c'est le cas actuellement.

C'est ce qu'a fait un certain système d'exploitation propriétaire, et pour le choix de l'UTF-16 (pas pour l'horreur qu'est le BOM UTF-8) malheureusement aussi plusieurs frameworks multiplateformes comme Qt, le Java ou le Python. Ça crée beaucoup plus de problèmes que ça ne résout: applications vétustes qui ne gèrent toujours pas le Unicode et ne le gèreront probablement jamais (sauf pour Qt où QString est en UTF-16 obligatoire depuis Qt 2 et les applications Qt 1 n'existent plus en pratique), conversions entre 8-bits et UTF-16 qui compliquent le code et causent des pertes si le programme utilise le mauvais charset 8-bits pour la conversion, consommation de mémoire doublée pour l'ASCII etc., et pour le BOM UTF-8, perte d'interopérabilité avec le reste du monde.

flanker (./4663) :
C'est plus chiant dans certains langages de programmation (pour déterminer la longueur d'une chaîne, ce n'est pas juste nombre de bits / 8)

Dans la plupart des cas, c'est la taille en octets qui t'intéresse, pas le nombre de codepoints Unicode.

GoldenCrystal (./4665) :
Et l'UTF-32, ça ne sert à rien (Sérieusement, ça coûte trop cher pour ce que a apporte)

C'est l'UTF-16 qui ne sert à rien et est un accident historique. Il n'apporte ni la taille fixe pour un codepoint Unicode de l'UTF-32 (alors qu'il avait été conçu pour ça à la base, mais les caractères CJK ont éclaté les 16 bits), ni l'efficacité et la compatibilité ASCII de l'UTF-8.

Pour ce qui est du latex c'est certainement très bien, mais il faudrait que tu comprenne que beaucoup de gens (dont je fait partie) n'ont clairement pas envie de l'apprendre pour le faible usage qu'ils en feraient alors qu'il existe des outils wysiwyg me permettent de faire la même chose naturellement.

Par contre pour l'utf-8, je . Ce n'est certes pas un outil magique qui fait que tout peut passer à l'unicode sans avoir a se soucier de rien, mais il a de très nombreux avantages.

Parmi ceux qui me viennent en premier à l'esprit il y a :
* taille réduite pour la majorité des langues. (Et même dans les langues à idéogrammes, les fichiers avec balisage comme xml, json,... et les fichiers de scripts sont majoritairement composés de caractères ascii standards. Je pense qu'en général, un programme a davantage à traiter ce genre de texte que le langage naturel.)
* pas de 0 dans le flux
* pas de problème de big/little endian
* compatibilité ascii standard -> utf-8

Le point ou je ne rejoint pas vraiment Kevin, c'est que le fait de ne pas connaitre directement l’emplacement des lettres est un vrai inconvénient, ça complexifie le traitement du texte. Cela est cependant mitigé par le fait que l'on a les bibliothèques pour faire ça ce n'est généralement pas ce qu'il y a de plus couteux en temps d’exécution.

l'UTF-16 est en effet désormais vraiment bâtard. C'était une bonne solution à l'époque ou unicode faisait seulement 16 bit. Maintenant, il cumule les défauts de l'UTF-8 et de l'UTF-32, sans aucun des avantages (sauf à considérer que l'unicode > 16bit n'existe pas).

Bref UTF-8 me semble une très bonne solution à la plupart des cas.