Chiffres romains et tri

Version imprimable

Bonjour,

les nombres écrits en chiffres romains posent un problème dés lors qu'on souhaite les trier puisque ceux-ci utilisent des lettres mais ne suivent pas l'ordre alphabétique.

Pour parer à ce problème, j'ai donc eu l'idée d'utiliser non pas des "I", des "V" et des "X" de la plage ASCII, mais les points de code de U+2160 à U+2169 (ROMAN NUMERAL x) de manière à avoir un unique point de code pour figurer un nombre (je n'ai pas besoin de grands nombres).

J'ai ensuite procédé à quelques tests en créant des fichiers nommés (en UTF-8) avec ces fameux points de code.

Test 1:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #!/usr/bin/env bash mkdir 'Livre Lambda' cd 'Livre Lambda' touch 'Tome Ⅰ' touch 'Tome Ⅱ' touch 'Tome Ⅲ' touch 'Tome Ⅳ' touch 'Tome Ⅴ' touch 'Tome Ⅵ' touch 'Tome Ⅶ'
Si je fais: find . -type f -printf "%f\n" | LC_COLLATE=C sort, j'obtiens bien l'ordre attendu:
Code:

1 2 3 4 5 6 7 Tome Ⅰ Tome Ⅱ Tome Ⅲ Tome Ⅳ Tome Ⅴ Tome Ⅵ Tome Ⅶ
Ce qui n'est pas étonnant vu que dans ce cas les noms de fichiers sont comparés "bêtement" octet par octet.
J'obtiens le même résultat avec LC_COLLATE=fr_FR.UTF-8. Donc jusque là, pas de problème.

Test 2:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #!/usr/bin/env bash mkdir 'À la recherche du temps perdu' cd 'À la recherche du temps perdu' touch 'Tome Ⅰ : Du côté de chez Swann' touch 'Tome Ⅱ : À l’ombre des jeunes filles en fleurs' touch 'Tome Ⅲ : Le Côté de Guermantes' touch 'Tome Ⅳ : Sodome et Gomorrhe Ⅰ et Ⅱ' touch 'Tome Ⅴ : La Prisonnière' touch 'Tome Ⅵ : Albertine disparue' touch 'Tome Ⅶ : Le Temps retrouvé'
Si je fais: find . -type f -printf "%f\n" | LC_COLLATE=C sort, j'obtiens toujours l'ordre attendu.
Par contre si je change la collation en LC_COLLATE=fr_FR.UTF-8 alors là rien ne va plus car le Tome Ⅴ est propulsé en fin de liste:
Code:

1 2 3 4 5 6 7 Tome Ⅰ : Du côté de chez Swann Tome Ⅱ : À l’ombre des jeunes filles en fleurs Tome Ⅲ : Le Côté de Guermantes Tome Ⅳ : Sodome et Gomorrhe Ⅰ et Ⅱ Tome Ⅵ : Albertine disparue Tome Ⅶ : Le Temps retrouvé Tome Ⅴ : La Prisonnière
Pour quelle raison?

26/05/2025, 01h13
CosmoKnacki
Même avec de simples lettres accentuées (NFC), l'ordre n'est pas respecté:
Code:

1 2 3 4 5 $ echo -e "côté\ncoté\ncote\ncôte" | LC_COLLATE=fr_FR.UTF-8 sort cote coté côte côté

Bonjour :coucou:

Question intéressante.

Un simple copier-coller dans vim montre qu'il y a un problème. Tous les chiffres romains sont affichés correctement sauf Ⅴ. (qui s'affiche bien dans le navigateur, vous notez).

Pourtant, od -c donne un code normal pour le Ⅴ :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
0000000   T   o   m   e     342 205 240       :       D   u       c 303                                                
0000020 264   t 303 251       d   e       c   h   e   z       S   w   a                                                
0000040   n   n  \n   T   o   m   e     342 205 241       :     303 200                                                
0000060       l 342 200 231   o   m   b   r   e       d   e   s       j                                                
0000100   e   u   n   e   s       f   i   l   l   e   s       e   n                                                    
0000120   f   l   e   u   r   s  \n   T   o   m   e     342 205 242                                                    
0000140   :       L   e       C 303 264   t 303 251       d   e       G                                                
0000160   u   e   r   m   a   n   t   e   s  \n   T   o   m   e     342                                                
0000200 205 243       :       S   o   d   o   m   e       e   t       G                                                
0000220   o   m   o   r   r   h   e     342 205 240       e   t     342                                                
0000240 205 241  \n   T   o   m   e     342 205 245       :       A   l                                                
0000260   b   e   r   t   i   n   e       d   i   s   p   a   r   u   e                                                
0000300  \n   T   o   m   e     342 205 246       :       L   e       T                                                
0000320   e   m   p   s       r   e   t   r   o   u   v 303 251  \n   T                                                
0000340   o   m   e     342 205 244       :       L   a       P   r   i                                                
0000360   s   o   n   n   i 303 250   r   e  \n                                                                        
0000372

Dans la console, si je tape "Ⅳ Ⅴ Ⅵ" (bien affiché dans le navigateur), j'ai un trou entre Ⅳ et Ⅵ. Mais le copier-coller dans le navigateur est correct. Et le copier-coller dans xterm est correct aussi. Ma console par défaut est xfce4-terminal.

Ce caractère Ⅴ est chatouilleux. Je ne sais pas pourquoi.

26/05/2025, 16h27
N_BaH
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $ echo 'IV V VI II I X IX III' | LC_COLLATE=C sort I II III IV IX V VI X
8O
j'ai raté un truc, ou ça trie mes genoux ?

EDIT: d'accord. je suis passé à travers ça :

Citation:

Envoyé par CosmoKnacki

j'ai donc eu l'idée d'utiliser [...] les points de code de U+2160 à U+2169 (ROMAN NUMERAL x)
26/05/2025, 19h24
Flodelarab

Citation:

Envoyé par N_BaH

j'ai raté un truc, ou ça trie mes genoux ?

Oui, tu as raté que en fr_FR.UTF-8, un caractère sort du rang pour avoir son comportement propre. CosmoKnacki a déjà dit ce que tu dis.

[edit] Ah mais non. Tu ne prends pas les caractères unicode des chiffres romains. Trouves-tu normal d'avoir le 9 entre 2 chiffres inférieur ?[/edit]

@N_BaH et oui, il faut prendre les bons codes
Code:

1 2 echo -e "\u2160\n\u2161\n\u2162\n\u2163\n\u2164\n\u2165\n\u2166\n\u2167\n\u2168\n" | LC_COLLATE=C sort echo -e "\u2160\n\u2161\n\u2162\n\u2163\n\u2164\n\u2165\n\u2166\n\u2167\n\u2168\n" | LC_COLLATE=fr_FR.UTF-8 sort
Citation:

Mais le copier-coller .... Et le copier-coller ...

Je n'ai pas utilé et cela ne change rien, pas lui le coupable (comme le disait od -c)

Et donc dans le premier message la commande touch était ? (en bash) pas évident sur ce forum

Code:

touch "chapitre "$'\u2167'

ls ou sort, même punition
Code:

1 2 3 4 ls --sort=name 'chapitre Ⅰ' 'chapitre Ⅱ' 'chapitre Ⅲ' 'chapitre Ⅳ' 'chapitre Ⅸ' 'chapitre Ⅴ' 'chapitre Ⅵ' 'chapitre Ⅶ' 'chapitre Ⅷ' LC_COLLATE=C ls --sort=name 'chapitre Ⅰ' 'chapitre Ⅱ' 'chapitre Ⅲ' 'chapitre Ⅳ' 'chapitre Ⅴ' 'chapitre Ⅵ' 'chapitre Ⅶ' 'chapitre Ⅷ' 'chapitre Ⅸ'
Pas surprenant, même problème de tri en gui dans mon Dolphin

27/05/2025, 17h20
disedorgue

Vous avez essayé avec la locale italienne pour voir :aie:
:dehors:
27/05/2025, 20h40
papajoker
normalement il doit-être possible de modifier notre propre locale (je n'ai pas dis que c'est utile !)

/usr/share/i18n/locales/fr_FR
Code:

1 2 3 4 LC_COLLATE % Copy the template from ISO/IEC 14651 copy "iso14651_t1" END LC_COLLATE
on ne va pas modifier la norme iso14651 du code source de glibc :mouarf:

Dans le bloc "LC_COLLATE" on devrait pouvoir redéfinir l'ordre les charactères "ROMAN NUMERAL" de glibc

Citation:

Envoyé par CosmoKnacki

Pour quelle raison?

j'ai demandé a l'IA ... :

La raison la plus probable de cette anomalie (IX avant V) dans votre fr_FR.UTF-8 est que les règles de collation spécifiques pour les chiffres romains dans votre version de glibc peuvent être complexes et ne pas suivre un tri purement numérique pour tous les cas, ou il peut y avoir un niveau de collation qui donne la priorité à la "forme" (caractère initial) avant la "valeur numérique" complète.

Ce n'est pas une "erreur" de la norme, mais plutôt une implémentation spécifique ou une règle de priorité des niveaux de collation qui aboutit à ce résultat pour ces caractères Unicode particuliers. Pour une collation "naturelle" des nombres romains, on s'attendrait à I, II, III, IV, V, VI, VII, VIII, IX, X. L'ordre que vous obtenez suggère une règle de collation qui tente de les regrouper par un préfixe commun avant de considérer la valeur numérique complète.
27/05/2025, 22h10
Flodelarab

Vous avez bien travaillé. Prenez donc une collation.
:dehors:

Citation:
Envoyé par papajoker
normalement il doit-être possible de modifier notre propre locale (je n'ai pas dis que c'est utile !)

/usr/share/i18n/locales/fr_FR
Code:

1 2 3 4 LC_COLLATE % Copy the template from ISO/IEC 14651 copy "iso14651_t1" END LC_COLLATE
on ne va pas modifier la norme iso14651 du code source de glibc :mouarf:

Dans le bloc "LC_COLLATE" on devrait pouvoir redéfinir l'ordre les charactères "ROMAN NUMERAL" de glibc

j'ai demandé a l'IA ... :

La raison la plus probable de cette anomalie (IX avant V) dans votre fr_FR.UTF-8 est que les règles de collation spécifiques pour les chiffres romains dans votre version de glibc peuvent être complexes et ne pas suivre un tri purement numérique pour tous les cas, ou il peut y avoir un niveau de collation qui donne la priorité à la "forme" (caractère initial) avant la "valeur numérique" complète.

Ce n'est pas une "erreur" de la norme, mais plutôt une implémentation spécifique ou une règle de priorité des niveaux de collation qui aboutit à ce résultat pour ces caractères Unicode particuliers. Pour une collation "naturelle" des nombres romains, on s'attendrait à I, II, III, IV, V, VI, VII, VIII, IX, X. L'ordre que vous obtenez suggère une règle de collation qui tente de les regrouper par un préfixe commun avant de considérer la valeur numérique complète.
Pour moi, c'est juste le gars qui a mit cette collation en place à pris les chiffre romain pour des lettres au lieu de chiffres, en preuve:
la collation:
\u2160
\u2161
\u2162
\u2163
\u2168
\u216C
\u216F
\u2164
\u2165
\u2166
\u2167
\u2169
\u216A
\u216B

ce qui donne:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 $ echo -e '\u2160 \u2161 \u2162 \u2163 \u2168 \u216C \u216F \u2164 \u2165 \u2166 \u2167 \u2169 \u216A \u216B ' Ⅰ Ⅱ Ⅲ Ⅳ Ⅸ Ⅼ Ⅿ Ⅴ Ⅵ Ⅶ Ⅷ Ⅹ Ⅺ Ⅻ
c'est très alphabétique comme ordre je trouve...

28/05/2025, 12h06
Flodelarab

Je vous vois passer, encore et encore par \uxxxx, mais vous savez que vous pouvez écrire les caractères directement dans la commande en appuyant sur Ctrl+Shift+u puis tapant le code et Entrée. C'est comme refuser au zéro le pouvoir de désigner une quantité, dans le langage courant. La console est en unicode. Profitons-en.
28/05/2025, 12h22
N_BaH

Citation:

vous pouvez écrire les caractères directement dans la commande en appuyant sur Ctrl+Shift+u

ça ne fonctionne pas avec tous les terminauX (rxvt-unicode, par exemple), et pas du tout en mode texte.
28/05/2025, 15h19
Daïmanu

Citation:

Envoyé par disedorgue

Pour moi, c'est juste le gars qui a mit cette collation en place à pris les chiffre romain pour des lettres au lieu de chiffres

Ça a l'air d'être confirmé dans cette page du consortium : https://www.unicode.org/charts/collation/

Si on scroll au niveau des V (0076) ou des X (0078), on y voit bien les caractères romains Ⅴ / Ⅵ / Ⅶ et Ⅺ / Ⅻ en rouge.
Si je comprends bien, Ⅶ est considéré comme suivant V dans l'ordre de tri. Mais j'avoue je ne comprends pas ce que le rouge signifie.

D'ailleurs, la recherche de Tome V (caractère latin) dans cette page tombe sur Tome Ⅴ (caractère romain). Pareil pour Tome I / Tome Ⅰ.
28/05/2025, 15h20
papajoker

Citation:

en appuyant sur Ctrl+Shift+u

même chose pour moi, ce combo clavier n'existe pas par défaut sous kde plasma, apps qt donc konsole. Par contre, il fonctionne quand même bien dans la barre d'adresse ou éditeur d'un formulaire de mon navigateur web ou vscode (puisque gtk)...