Comprendre les encodages

Coucou, voici le tutoriel que j’avais initialement publié sur le SdZ, dans une version revue et subtilement augmentée.

Je suis donc confiant sur le « fond » — mais si vous voyez des choses à enlever (ou ajouter…), n’hésitez pas à le dire. Je suis aussi globalement satisfait de la « forme », mais deux points sont peut‐être améliorables :

• la première partie dégénérée,
• et la sous-partie sur la programmation qui fait un peu fourre‐tout.

Ce qui m’attire en bêta sont surtout les détails techniques liés à ZdS, pour éviter de spammer les validateurs.

• Je ne sais pas dans quelle(s) catégorie(s) classer ce tutoriel. Ce qui est sûr, c’est qu’aucune catégorie actuelle ne convient. Peut‐être une catégorie générique genre « informatique » ou « culture générale informatique » (voire en bonus une autre « programmation ») ? À moins que le format adapté soit celui d’un article ?
• Les tableaux qu’on m’avait vendu ici ne marchent pas comme promis : les cellules multilignes ne semblent pas prises en charge, la syntaxe Table: pour les légendes n’est pas reconnue, et les tableaux ne sont pas centrés. Est‐ce connu, normal, résoluble ?

Merci !

Salut,

Peut-être ai-je mal lu, mais tu ne parles pas du fait qu'un graphème Unicode (un "vrai caractère") peut être composé de plusieurs codepoints Unicode (ce que tu appelles "caractère" dans ton tutoriel). Par exemple, "é" peut être représenté par un seul codepoint ou par deux ("e" et l'accent). Ceci est indépendant de l'encodage Unicode utilisé : cela signifie que l'UTF32 est aussi à longueur variable si l'on considère les graphèmes plutôt que les codepoints (souvent appelés "caractères" à tord).

Il me semble que "NBSP" veut dire "non breakable space" et non "non breaking space" non ?

Sinon dans les liens l'article "ce que tout programmeur doit savoir" est-il encore valide ? Je veux dire l'article date de 2003, c'est à dire environ 15 ans… Est-ce que php à toujours un problème d'encodage comme il le dit ?

Il me semble que "NBSP" veut dire "non breackable space" et non "non breacking space" non ?

Ni l'un ni l'autre, "NBSP" désigne avant tout un "non-breaking space", mais peut aussi signifier "non-breakable space", ce qui revient au même niveau acronymie mais est moins commun (le vrai nom était "non-breaking space" en typographie).

Hum si on traduit en français par "espace insécable" on devrait dire "non-breakable" et pas "non-breaking" non ? "Non-breaking" traduirait le fait que c'est l'espace qui ne coupe pas et non pas l'idée qu'il est insécable. D'après l'article wikipédia l'usage du nbsp étant bien de ne pas casser la ligne, tu as raison et c'est "non breaking space" qui doit être le vrai non. Du coup la traduction française est mauvaise et c'est elle qui m'a induite en erreur

…

Costaud, là…

Bref…

1. Il n’y a pas de « traduction française », c’est le terme employé en français depuis toujours.
2. L’anglais break est à la fois transitif et intransitif, là où le français distingue « casser » transitif de « se casser » intransitif. Dans non-breaking, c’est la version intransitive qui est utilisée, et cela signifie donc « espace ne se cassant pas ». Dans la logique de l’anglais, c’est parfaitement normal.

Sinon, Maëlan, si ça t’intéresse, pour ta section programmation : en Haskell, l’extension UnicodeSyntax de GHC permet d’utiliser des caractères Unicode à la place de certains mots-clés ou symboles de la syntaxe, comme ∀ au lieu de forall ou → au lieu de ->. C’est un peu inutile, mais c’est rigolo. Et c’est sous-entendu, mais les noms de fonctions et variables peuvent utiliser n’importe quel caractère Unicode : on peut programmer en chinois.

un bogue avait tronqué mon message, j’ai édité pour y remettre le texte complet, qui précise les points éventuellement améliorables et les détails techniques auxquels je cherche encore une solution.

en effet, et c’est à dessein : si on commence à en parler, il faudrait aussi parler d’équivalences, de normalisation, de collation… ce qui alourdirait encore cet écrit déjà bien assez long. j’ai donc sommairement omis tous ces aspects d’Unicode pour me focaliser sur la partie « encodage ». tout est condensé dans ce paragraphe :

On peut voir Unicode comme une surcouche d’ISO 10646. ISO 10646 liste les caractères du jeu en leur assignant un nom et un code. Unicode leur ajoute des attributs et des relations. Unicode décrit aussi des algorithmes de traitement notamment pour la gestion des sens d’écriture et l’ordre alphabétique, et surtout — ce qui nous intéresse ici — des encodages pour transcrire le JUC.

peut‐être faudrait‐il quand même le mentionner, ou au moins rendre ce passage plus explicite.

à une époque, j’envisageais d’écrire un truc à part sur Unicode, ce qui justifiait aussi le fait de ne pas plus développer ici.

je ne sais pas, je ne connais pas PHP. ceci dit, il s’agit surtout d’une présentation historique et d’explications sur Unicode, il y a assez peu d’informations périssables (le passage sur PHP dont je ne connais pas la fraîcheur mais qui est plutôt vague, et celui sur C(++) qui est toujours plus ou moins d’actualité). comme c’est une sorte d’article de référence et que je trouve que c’est bien expliqué, je le mets.

Coq et d’autres langages ont ça aussi, mais je ne crois pas que ce soit suffisamment important pour le mentionner. d’autant plus que c’est la manipulation programmatique du texte qui m’intéresse ici, pas trop la syntaxe des langages de progammation.

C'est super-intéressant !

J'ai trouvé l'historique assez long par rapport à l'application pratique. Vu cette longueur, je m'attendais à avoir une partie sur l'application pratique plus fournie. Par exemple comment écrire des caractères en HTML tels que © ou '\00b7' en CSS. Et pourquoi ne pas avoir parlé d'avantage des glyphs et passé les emoji à la trappe alors que ce sont des trucs en vogue ?

Mais c'est tout-à-fait subjectif. Objectivement, je trouve que c'est déjà très instructif comme ça.

j’ai finalement mis à jour le tutoriel, en ajoutant :

• un passage sur la composition de points de code Unicode,

• des tableaux sur le coût mémoire d’UTF‐16 et d’UTF‐8 et leur intérêt respectif selon les alphabets,

• deux sections dans la partie pratique, sur l’utilisation d’outils comme iconv et sur l’UTF‐8 « corrompu »,

• ça :

  par exemple comment écrire des caractères en HTML tels que © ou '\00b7' en CSS

• diverses anecdotes (EBCDIC, hangeul, SMS, IRC).

J'ai trouvé l'historique assez long par rapport à l'application pratique. Vu cette longueur, je m'attendais à avoir une partie sur l'application pratique plus fournie.

en effet, je comprends très bien. le problème, c’est que cette partie est un fourre‐tout sur le thème « trucs pratiques en rapport avec les encodages », je n’y vois pas vraiment de fil directeur.

Et pourquoi ne pas avoir parlé davantage des glyphes et passé les émojis à la trappe alors que ce sont des trucs en vogue ?

à vrai dire, les deux figuraient sur ma liste à un moment, mais je ne sais pas vraiment quoi en dire.

je veux envoyer le tutoriel en validation maintenant, mais je ne sais toujours pas dans quelle catégorie(s) le ranger, ni même si ça ne devrait pas plutôt être un article !

Super !
C'est un peu long pour un article, je trouve.

Autres > Accessibilité ?
Analyse et conception > API ?

Bah simplement en parler vite fait : juste dire sur le ton de l'anecdote qu'il existe des icônes et smileys appelés emoji parmi les caractères UTF8, on peut même évoquer aussi les lettres runiques et ce genre de choses, qui sont surprenantes.
Bon, les glyphs, je suis d'accord que c'est assez éloigné du sujet (c'est plus à propos des polices/fonts).

Bonjour,

La bêta du contenu « Comprendre les encodages » a été désactivée.