<foo>
simply produces <foo>in the text).
<URL: http://somewhere.tld/ >
,
and it will be automatically made into a link.
(Do not try any other way or it might count as an attempt to spam.)mailto:
URI,
e.g. mailto:my.email@somewhere.tld
,
if you do not have a genuine Web site).
fakbill (2018-06-15T08:33:09Z)
Pour ce qui est des noms de fichiers, il est clair que le simple fait qu'on puisse avoir des "lettres" identiques (ou Presque) à l'oeil, mais en fait différentes, pose des problèmes de securité évidents. Ca a d'ailleurs été le cas le jour où on a voulu autoriser l'unicode dans les url.
Laurent (2018-06-15T08:18:10Z)
Je pense que ça ne serait pas de mal de mettre un lien sous « API », ainsi qu'un `<abbr title="…"`, parce que ça m'a confusé quelques secondes, le temps d'aller sur Wikipedia pour me rafraichir la mémoire.
Ruxor (2018-06-14T09:53:09Z)
@JML:
C'est vrai, j'ai excessivement simplifié. D'ailleurs, Unicode définit toutes sortes de relations d'équivalence entre suites de caractères (codepoints) Unicode, par exemple U+00E9 LATIN SMALL LETTER E WITH ACUTE (é) devrait être dans un certain sens équivalent à la succession U+0065 LATIN SMALL LETTER E + U+0301 COMBINING ACUTE ACCENT (é) (je ne sais pas comment j'ai réussi à pondre un rant aussi long sans mentionner les combinants) et dans certains contextes, d'ailleurs pas complètement clairs, il est autorisé de transformer l'un en l'autre, d'utiliser l'un pour afficher l'autre, de matcher l'un quand on recherche l'autre, ce genre de choses.
N'empêche qu'on sait très bien que ça va causer des emmerdes de toutes sortes : à moins qu'on normalise les équivalences et les contextes dans lesquels elles doivent servir, on va se retrouver avec un système de recherche qui considère que <foo> et <bar> sont pareil et un autre qui ne le considère pas, un OS qui considère qu'on peut avoir deux fichiers nommés <foo> et <bar> dans le même répertoire et un autre qui ne le considère pas (d'où toutes sortes d'emmerdes quand on échange des fichiers de l'un à l'autre…), ou pire, une situation où on dit à un utilisateur qu'il ne peut pas créer un fichier <foo> parce qu'il y en a déjà un mais où ce fichier n'apparaît pas quand il le recherche — ou bien le contraire.
JML (2018-06-14T08:49:44Z)
« la recherche dans un texte serait rendue excessivement merdique et les problèmes de sécurité se multiplient » Il me semble qu'il y a là une confusion : la merdicité d'un système de recherche textuelle n'a pas vocation à dépendre directement des propriétés de l'encodage choisi ; idem pour la sécurité.
Il s'agit de monter un système de recherche (resp. un système sécurisé) par-dessus un système d'encodage, et qu'il y ait peu ou beaucoup de caractères qui auraient pu être disjoints ou réunis ne devrait pas changer la nature des difficultés à résoudre.
sbi (2018-06-14T08:10:40Z)
On peut alors parler de choses comme
https://en.wikipedia.org/wiki/Faux_Cyrillic
qui mentionne cette page d'exemples
http://tvtropes.org/pmwiki/pmwiki.php/Main/TheBackwardsR
ou pour d'autres alphabets s'il y a… (indien? il me semble,
mais ce ne sont sans doute que des polices pipo).
Ruxor (2018-06-13T15:43:14Z)
@DH: Aaaaaaahhh… Je n'avais même pas imaginé une seule seconde que ça devait être autre chose que /gora/…
DH (2018-06-13T15:30:23Z)
Ah moi ce sont les yaourts "YOPA", dont l'étiquette en faux-grec est "γορα" et que je ne peux m'empêcher de prononcer mentalement /gora/ qui m'agacent prodigieusement…
Ruxor (2018-06-12T23:07:31Z)
@Typhon:
Ce que je crois avoir illustré dans mon rant, c'est qu'à la fois l'amalgamation et la désunification peuvent poser des problèmes, et parfois on n'a que le choix entre Charybde et Scylla, donc d'un côté comme de l'autre les gens vont se plaindre. Quand on râle que des caractères « différents » ont été amalgamés, on oublie que, dans le cas contraire, la recherche dans un texte serait rendue excessivement merdique et les problèmes de sécurité se multiplient. Réclamer « le plus de distinctions possibles » n'est clairement pas une bonne solution ; je le sais notamment parce que j'avais utilisé Emacs pré-Unicode, son principe à lui était de faire la réunion de tous les jeux de caractères existants (en n'unifiant qu'ASCII stricto sensu), alors on avait un ‘à’ latin-1 et un ‘à’ latin-3 et même un ‘à’ latin-15 tous distincts, et sans doute plein d'autres, c'était un cauchemar. À un certain moment, aussi, je passais mon temps à corriger sur Wikipédia les ‘µ’ (U+00B5 MICRO SIGN) qui auraient dû être des ‘μ’ (U+03BC GREEK SMALL LETTER MU) ou vice versa — tiens, j'aurais dû en parler, de ça — et à maudire cette désunification. (Pourquoi est-ce que le ‘k’ de « km » est un ‘k’ tout ce qu'il y a de plus normal alors que le ‘µ’ de « µm » est un truc complètement spécial qui ne sert que pour ça ?)
Et spécifiquement, s'agissant de l'unification Han, j'ai entendu plein de gens râler, mais je n'ai jamais entendu qui que ce soit expliquer ce qu'on aurait dû faire au juste. Notamment, il faut se souvenir qu'avant même qu'Unicode n'existe, les dessins de caractères (voire des polices complètes) avaient déjà commencé à s'échanger librement entre langues asiatiques, conduisant à l'apparition de glyphes passés d'une langue à une autre où ils étaient censément « incorrects » (whatever that means) : la mondialisation n'a pas attendu Unicode, et le phénomène n'est pas spécialement de la faute des « occidentaux ».
Décider de désunifier complètement les idéogrammes japonais, chinois traditionnels, chinois simplifiés, coréens aurait fatalement conduit à des textes hybrides à la frankenstein parce que les gens auraient pris les caractères là où ils étaient en cas de lacunes, la recherche aurait été rendue impossible par la multiplicité des variantes, l'encodage de textes anciens aurait été un casse-tête supplémentaire, et pour les caractères très rares on se serait rendu compte que ça n'a plus aucun sens d'essayer de savoir de quelle langue ils sont (ou alors on aurait fini par encoder N fois 10^5 caractères)… En comparaison, le problème du ‘µ’ versus ‘μ’, ce serait de la gnognote. Et il n'est même pas clair que ça aurait résolu le problème parce que les variations de glyphes existent aussi au sein d'une même langue et qu'un moment ou un autre il faut bien décider ce qu'on considère comme digne d'être encodé et ce qu'on ne considère pas comme digne d'être encodé.
Est-ce que tu suggérerais, par exemple, qu'on dût faire plusieurs ‘G’ différents parce que le ‘G’ majuscule cursif ne s'écrit pas pareil en France et aux États-Unis ? Non, tu vas juste dire à quelqu'un qui cherche une police cursive d'en trouver une qui colle avec l'écriture de son pays.
Bref, il fallait un compromis. Le compromis qui a été trouvé n'était pas parfait, et il y a beaucoup de caractères précis où il est même épouvantable, mais c'est notamment parce que les Japonais, au début, et dans une certaine mesure les Chinois de RPC, ne voulaient pas travailler avec Unicode, parce qu'ils s'estimaient satisfaits de leur standard national, donc ils ont participé aux décisions à reculons, et forcément, elles ont été assez mal prises. Les désunifications excessives l'ont été surtout parce qu'Unicode a eu la main forcé par des standards préexistants (surtout japonais, justement). Les amalgamations excessives l'ont été surtout par manque d'implication des organismes de standards nationaux, mais il y a un point qu'il faut souligner, c'est qu'il est beaucoup plus facile de désunifier sur le tard que de revenir sur une désunification (on ne peut pas réamalgamer deux caractères, au mieux on peut marquer l'un comme déprécié), et Unicode a souvent montré qu'il pouvait revenir sur ses décisions (j'ai donné des exemples).
Le mécanisme des sélecteurs de variations est un excellent moyen de donner plus de flexibilité à Unicode en la matière : cela offre une mesure intermédiaire entre amalgamer complètement et désunifier totalement ; cela permet des variations sans langage de markup mais quand même de ne pas trop casser les recherches. Alors certes, l'implémentation est encore défaillante, mais reprocher à un standard de ne pas être implémenté partout, c'est un peu fallacieux. (Moi aussi ça m'emmerde que mes lecteurs n'aient pas tous le symbole ‘𝔖’ quand je veux parler de maths, mais ce n'est pas la faute d'Unicode, quand même !) En attendant, on peut aussi utiliser des indications explicites de polices ou de langues. La lecture de la page <URL: http://en.wikipedia.org/wiki/Han_unification > me permet de constater que, sur mon navigateur et avec les polices que j'ai installées sur mon ordi, les différences entre glyphes chinois et japonais sont bien réelles.
Et surtout, il faut souligner ceci : UNICODE N'EMPÊCHE RIEN DE CE QUI ÉTAIT POSSIBLE AVANT UNICODE. Tous les encodages de caractères asiatiques sont reflétés fidèlement dans Unicode : si une page Web ou un fichier texte pouvait être écrit en Shift-JIS ou en GB18030, c'est encore possible avec Unicode. Ce n'est pas la faute d'Unicode si le mécanisme de sélection des polices, derrière, se comporte mal. Une fois qu'on a compris ce fait, la grande majorité des critiques contre Unicode en général ou l'unification Han en particulier, apparaissent comme teintées d'une grande mauvaise foi.
Le second lien que tu donnes est très intéressant, mais je ne trouve pas que ce soit une critique du processus d'unification Han, c'est surtout une illustration de l'extrême complexité des choix à faire et de l'impossibilité d'éviter à la fois Charybde et Scylla. Le premier lien… je ne vois vraiment pas ce qu'on peut en tirer quand il ne donne pas le moindre détail technique… il paraît que quelque chose n'est pas encodable en Unicode en bengali, mais quoi ? aucune idée, il ne donne pas une image de ce qu'on devrait pouvoir encoder ni l'approximation que fournit Unicode, ni la moindre précision sur le problème… S'il y a des caractères qui manquent, ils peuvent toujours être ajoutés, mais ce qui est sûr c'est que, une fois de plus, Unicode n'a pas pu empirer la situation par rapport aux standards qui existaient avant (comme ISCII).
Typhon (2018-06-12T20:16:41Z)
L'écriture c'est vraiment un cauchemar d'informaticien, un système legacy de plusieurs millénaires.
Je note que tu abordes pas LE truc le plus controversé dans Unicode, l'infâme "unification Han" qui fusionne kanji, caractères chinois et hanja coréens en piétinant tout plein de particularités locales de la façon la plus déplaisante et impérialiste possible et crée tout un tas de problèmes : <URL: https://modelviewculture.com/pieces/i-can-text-you-a-pile-of-poo-but-i-cant-write-my-name > <URL: https://namakajiri.net/nikki/joyo-kanji-variants-the-curious-case-of-and-%E5%8F%B1/ >, etc…
De la part de l'encodage de caractère qui distingue ‘A’, ‘Α’ et ‘А’, l'unification Han ça fait vraiment très eurocentrique façon : « les distinctions byzantines c'est bon pour nous les Occidentaux et vous les chinetoques vous allez vous partager des points de code parce que comme ça » et c'est d'autant plus mesquin quand ça touche des caractères qui s'écrivent effectivement différemment en Chine et au Japon, et encore plus maintenant qu'on fait rentrer rigoureusement n'importe quoi dans Unicode.
Mais bon, ce dernier fait, je pense que c'est plutôt une bonne chose, je suis pour une approche maximaliste (le plus de caractères et de jeux de caractères possibles) et particulariste (le plus de distinctions possibles).
J'attends donc avec impatience que le système d'encodage qui distingue A et 𝕬 fasse rentrer les caractères Comic Sans dans la prochaine version et qu'on s'empeigne autour de "A" vs U+XXXX COMIC SANS LATIN LETTER A :D :D :D
Bob (2018-06-12T09:09:15Z)
J'adore le Club Contexte et je pense que c'est de loin l'article où il est le plus mentionné !
JML (2018-06-11T22:15:31Z)
« le ‘Q’ majuscule que je crois me rappeler ressemblant vaguement à un ‘2’ »
Pareil. Et j'ai compris bien plus tard que si on boucle assez le ‘2’ pour que la boucle se referme à gauche, ça fait bien un Q… Le G cursif canadien semble provenir du même type de blague (tandis que le J ressemble au G français) ; la particularité du I doit provenir de son utilisation pour dire « je » (en anglais).
Le x canadien est intéressant, on dirait que la barre du x est destinée à être portée après-coup, comme pour la barre du t. Le ‘q’ est étrange et ‘p’ mignon.
Note : j'ai vu des orthophonistes déconseiller de montrer les pattes de liaison dans la présentation de l'écriture cursive.
Merci pour cette délicieuse entrée. Je déconseille absolument de tenter d'ordonner ces remarques « en quelque chose d'un peu systématique » qui serait probablement indigeste.
jonas (2018-06-11T20:57:36Z)
I too only have some random disjoint comments on this topic, and no answers.
- For the Turkish i, we're screwed anyway, no matter what we do.
- For the latin script, it is not even a completely obvious that uppercase letters should be encoded as different characters from lowercase ones, but italic style letters should be encoded the same as roman style letters.
- There's a rule of thumb to determine which alphabets should be encoded as disjoint scripts and which ones should intersect is this. If names originally written in one script are generally transliterated when they're written in a text in the other script, then they're disjoint script; if they're usually written unchanged, even including characters that aren't used in the language of the containing text, then they're the same script. Obviously this one doesn't always give a clear decision either.
- The cyrillic scripts for writing Russian, Ukranian, Belarusian, Serbian, Macedonian, Bulgarian are encoded in Unicode as a single script, with the letters “абвгдежзиклмнопрстухцчш” common among them all. It is not quite clear to me if this was the correct decision, and which of these should be different scripts. In any case, it's probably too late to change now, with all the existing documents and systems using the current encoding.
- I am quite sure that the Hungarian “sz”, “gy”, “ny”, “cs” should be encoded as two letters one after the other. The only way these are treated as a single letter are sorting words (collation), hyphenation, and Scrabble (but not normal crosswords), but it's obvious for other reasons that sorting, hyphenation and Scrabble need language-dependent rules anyway. In contrast, it's not that obvious that casefolding needs to be language-dependent, and the Turkish i is the only reason for that that I know. In particular, these consonants are considered to be two separate letters for capitalizing the first letter of a word at the start of a sentence: only the first of the letters is capitalized. Note that “ch”, “kh”, “th” are written for single consonants in Hungarian in some loanwords (The latter two only for loanwords from Greek, “ch” from greek and from many languages written in the latin script, including German and Latin. Also, “kh” and ”th” occur more frequently as two adjacent consonants in common words.) When they occur as a single consonant, they are treated as such for hyphenation and meter in poetry, but two letters in sorting. Further, the consonants “dz” and “dzs” are treated as single letters for sorting, but used to be treated as two consonants for sorting before approximately 1985.
- Another interesting case you could mention is the letter “Đ/đ” in Serbian latin script and the letter “Ð/ð” in Icelandic. The uppercase of these letters usually look exactly the same, but they're encoded as the same letter.