Discussion :

[CosmoKnacki]

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 bash :

Sélectionner tout - Visualiser dans une fenêtre à part

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 txt :

Sélectionner tout - Visualiser dans une fenêtre à part

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 bash :

Sélectionner tout - Visualiser dans une fenêtre à part

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 txt :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[CosmoKnacki]

Même avec de simples lettres accentuées (NFC), l'ordre n'est pas respecté:

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

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é

[Flodelarab]

Bonjour

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[N_BaH]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

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

j'ai donc eu l'idée d'utiliser [...] les points de code de U+2160 à U+2169 (ROMAN NUMERAL x)

[Flodelarab]

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]

[papajoker]

@N_BaH et oui, il faut prendre les bons codes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

touch "chapitre "$'\u2167'

ls ou sort, même punition

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[disedorgue]

Vous avez essayé avec la locale italienne pour voir

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

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.

[Flodelarab]

Vous avez bien travaillé. Prenez donc une collation.

[disedorgue]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

[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.

[N_BaH]

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.

[Daïmanu]

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 Ⅰ.

[papajoker]

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)...