Le standard Unicode

Il n’y a jamais eu de sujet sur le standard Unicode, comme il est largement connu, même assez du grand‑public. Ce sujet est quand‑même ouvert pour y rapporter des notes.

La première note.

La segmentation en mots, n’est pas compatible avec la segmentation en graphèmes. La première contredit parfois la seconde alors qu’elle ne le devrait pas. C’est le cas pour au moins la version 13 d’Unicode.

Détails.

L’annexe 29 définie des règles par défaut pour la segmentation de texte en graphèmes, mots et phrases. Ces règles sont dites par défaut, parce qu’elles ne sont pas parfaites, peuvent devoir être affinées par écriture ou par langue. Bien que imparfaites, elles sont considérées comme assez raisonnables pour la plupart des cas.

J’ai trouvé une bizarrerie, que j’ai signalé, mais sans savoir si la remarque sera prise en compte dans une prochaine version.

Dans l’annexe 29, la segmentation des graphèmes est définie à partir des code‑points, ce qui n’est pas étonnant, comme les graphèmes ne peuvent avoir que cette source. La segmentation en mots elle aussi, est définie à partir des code‑points, même si elle aurait put l’être à partir des graphèmes, surtout que le chapitre 6 de cette annexe dit (il faut s’en souvenir, parce que ça justifie de voir comme une erreur à corriger, le cas décrit ici) :


Les mises en œuvre des règles de segmentation, peuvent être testées avec des fichier contenant des jeux d’essais, qui sont GraphemeBreakTest.txt et WordBreakTest.txt, pour les deux segmentations dont il est question maintenant. Ces fichiers se trouvent dans le sous‑répertoire auxiliary du répertoire UCD.

Le test d’une mise en œuvre de la segmentation en graphèmes s’est bien déroulé, la méthode a fini par valider tous les tests, après quelques corrections. Mais le test d’une mise en œuvre de la segmentation en mots, utilisant des graphèmes comme source, échoue sur une ligne du fichier de test. C’est au moins le cas avec la version 13 d’Unicode. Le problème me semble être à la ligne 1725 du fichier WordBreakTest.text. C’est le fait de segmenter en mots en utilisant les graphèmes comme entrée (ce qui nécessite des adaptations non‑décrites ici), qui a permis de le remarquer.

Le test de cette ligne 1725, porte sur la séquence de code‑points suivante : ÷ 0061 ÷ 1F1E6 × 200D × 1F1E7 ÷ 1F1E8 ÷ 0062 ÷. Le ÷ signifie une coupure, le × signifie une absence de coupure. Les valeurs des propriétés Word_Break de ces code‑points sont, dans l’ordre : ALetter RI ZWJ RI RI ALetter. D’après les règles de la segmentation en graphèmes, cette séquence produit : (ALetter) (RI ZWJ) (RI RI) (ALetter). Mais d’après cette ligne du fichier de test, qui est d’ailleurs effectivement conforme aux règles de la segmentation en mots, cette séquence produit : (ALetter) (RI ZWJ RI) (RI) (ALetter).

Là est le problème, la segmentation en mot, coupe à l’intérieur d’un graphème. Le troisième graphème, (RI RI), se trouve coupé en deux, son premier RI allant dans un mot et son second RI dans un autre.

Je crois que le problème vient des règles impliquant ZWJ, qui me semblent étranges. ZWJ signifie Zero Width Joiner. Mais dans la segmentation en graphèmes, il peut apparaître tout‑seul à la fin d’un graphème, avec quelque chose à gauche, mais rien à droite et ne joint donc rien (comme c’est le cas plus haut, avec RI ZWJ). Mais en supprimant ZWJ de la règle GB9, la segmentation ne passe plus les tests du fichier GraphemeBreakTest.txt et échoue sur un trop grand nombre de lignes, tandis que la segmentation en mots ne contredit la segmentation en graphèmes, que sur une seule ligne du fichier de test.

Personnellement, je n’envisage pas de couper un graphème pour que la segmentation en mots passe les tests ; ça me semble être une erreur à corriger dans le standard.

Concernant la segmentation en phrases, le chapitre 5 de cette même annexe 29, mentionne explicitement que les règles définies peuvent dans certains cas, faire dire qu’une phrase se termine au milieu d’un mot, tout en qualifiant bien ces cas de “ inconsistencies ”, ne laissant pas de doute sur le fait qu’il est anticipé que ce ne soit vu comme problématique. La citation mentionne d’ailleurs l’idée de tenter de limiter les occurrences de ces cas. Si la segmentation en phrases se fait en prenant le résultat de la segmentation en mots, comme entrée, le risque disparaît, mais le fichier de test SentenceBreakTest.txt en contient peut‑être des mauvais échantillons (édit: finalement, non). Seulement cette fois, ce risque est mentionné, il n’est pas exclut comme par la phrase du chapitre 6, précédemment citée et ne doit alors pas être vu comme une erreur dans le standard, mais comme une chose à laquelle il faut remédier comme possible.

La définition par défaut de la segmentation des phrases n’est vraiment pas idéale, elle coupe les phrases aux sauts de ligne, alors que beaucoup de fichiers texte sont écrits avec des retours à la ligne explicites. Précisément, CR-LF ou CR ou LF, sont considérés comme des fins de paragraphes, impliquant une fin de phrase, au lieu d’être considérés comme des fins de ligne, n’impliquant pas une fin de phrase.

Ces règles essaient surtout de traiter avec l’ambiguïté des signes de ponctuation terminant une phrase, une ambiguïté qui ne peut être vraiment levée qu’avec une véritable analyse des phrases, comme le chapitre le dit lui‑même. Les signes utilisées pour continuer ou terminer une phrase, peuvent quand‑même être retenus, en leur donnant un rôle sans ambiguïté s’ils sont utilisés pour définir une syntaxe d’un aspect proche du langage naturel mais formelle.

Le jeux d’essais SentenceBreakTest.txt, ne contient pas de cas de phrase coupant au milieu d’un mot.

La segmentation en mots, tient pour des mots individuels, les symboles comme « = », « + », et d’autres, incluant tous les symboles mathématiques.

D’un côté, c’est pourtant une pratique courante d’avoir des unités lexicales composées de plusieurs de ces symboles, comme « == » ou « ++ ». D’un autre côté encore, mieux vaut éviter ces compositions de symboles qui créent de la confusion, surtout quand les symboles isolés sont déjà en pratique pas toujours bien définis. Aussi, ces symboles ont un intérêt pour leur concision, qui est plutôt perdue quand ils sont traités quasiment comme des lettres avec lesquelles ont peut composer des sortes de mots (des mots pas naturels).

La segmentation en mots définie par Unicode, ne prévoit pas ce cas, et cette position se défend bien, ces symboles ayant un sens en eux‑même, n’étant pas comme des lettres. S’il y a un intérêt à composer des unités lexicales en combinant certains symboles, c’est surtout pour la raison de deux archaïsmes persistants : les symboles trop souvent pas affichés ou mal affichés et la grande difficulté à les écrire dans les éditeurs. Mieux vaut encore remédier à ces deux problèmes plutôt que continuer à faire avec ces archaïsmes, par là, en les perpétuant.

Il existe une RFC qui définit un paramètre pour les fichiers texte brut, permettant de savoir si les sauts de ligne signifient des fins de paragraphe ou pas. Le paramètre est à définir dans le type MIME, par exemple “ text/plain;format=flowed ”. La différence minuscule/majuscule n’est pas importante, ni pour pour le nom ni pour la valeur du paramètre. Flowed correspond donc à ce qui est aussi appelé « retour à la ligne automatique ».

Flowed signifie que les CR-LF sont des fins de paragraphes. Fixed signifie que les CR-LF sont utilisés pour la mise en page. Si le paramètre n’est pas spécifié, la valeur par défaut est fixed. Donc par défaut, les CR-LF ne sont pas des fins de paragraphe.

Un autre paramètre est défini, delsp, pour les langues n’utilisant pas ou peu, les espaces. Ce paramètre n’est pertinent qu’avec format=flowed et doit être ignoré sinon. Cet autre paramètre peut avoir la valeur yes ou no. Si delsp=yes, les espaces précédents un CR-LF, sont virtuellement supprimés.

Voir : RFC 3676 — The Text/Plain Format and DelSp Parameters (ietf.org).