Bonjour à tous,

Je n'arrive pas à régler deux problèmes (qui ont l'air liés) que j'ai depuis plusieurs mois avec Debian (testing, à jour).

Jusqu'à maintenant, je fais avec ces problèmes mais aujourd'hui je serais ravi de m'en débarrasser. J'ai fait des recherches sur le web en français et en anglais et sur la liste debian-french mais je n'ai pas trouvé de solutions. Je tente donc ma
chance ici sur la liste.


On m'a envoyé un fichier "référent.pdf" que je prends comme exemple mais les mêmes problèmes décrits ci-dessous se produisent avec les fichiers qu'on m'envoie, pas avec ceux que je créée.


Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la commande "ls".

Par contre, sous xfce4-terminal, il s'affiche bizarrement comme "référent.pdf" (notez les accents décalés sur la droite des "e").

Quand j'édite le nom du fichier en ligne de commande sous bash, un backspace efface le caractère de gauche, normal. Quand j'arrive à la position juste à droit des accents, chaque "e" s'efface en même temps que son accent "associé".

Mais quand j'édite le nom de fichier sous le gestionnaire de fichier ranger (programmé en python), si je me mets par exemple à droite du "t" et que j'appuie sur backspace pour effacer cette lettre, il efface le "e" de "ent", soit 2 lettres à gauche
de la position du curseur au lieu d'effacer le caractère juste à gauche. Le décalage similaire se produit quand j'utilise la touche DEL.

J'ai essayé d'autres émulateurs de terminal : gnome-terminal, terminator, et lxterminal. Je rencontre les mêmes problèmes.

Je pensais à un problème de locales. J'ai tenté un "sudo dpkg-reconfigure locales" mais sans que cela ne résolve aucun problème.
La commande "locale" me renvoie des informations qui m'ont l'air correctes, comme celles que j'ai trouvées sur le net.

LANG=fr_FR.UTF-8
LANGUAGE=fr_FR:en_US
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=


J'ai ensuite pensé à un problème de fonte. Mon xfce4-terminal utilisait "Monospace Regular", j'ai alors testé d'autres fontes. J'arrive à résoudre le problème d'affichage mais pas celui de l'effacement expliqué plus haut, il y a toujours un dé
calage de 2 caractères.


Sous Emacs 27.1, j'ai le même problème d'affichage et d'effacement de caractères sous dired. J'ai tenté de lancer "emacs -q" depuis le xterm puisqu'il n'y avait pas de problème sous xterm, mais je rencontre les mêmes problèmes sous dired.


J'ai aussi créé un nouvel utilisateur sous ma machine pour voir si cela ne viendrait d'un problème de configuration quelque part au niveau de mon profil utilisateur : les problèmes rencontrés sont les mêmes.


Si vous avez des idées de solution, je suis (très) preneur ! :-) Jean-Philippe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le Fri, Oct 28, 2022 at 12:50:19AM +0200, Jean-Philippe Georget a écrit :

Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la commande "ls".

Par contre, sous xfce4-terminal, il s'affiche bizarrement comme "référent.pdf" (notez les accents décalés sur la droite des "e").

Bonjour,

c'est un problème de prise en charge d'Unicode.

Sur mon terminal, je vois référent.pdf dans les deux cas. Mais voici
ce que je vois si je copie-colle le nom de ficher et le passe à hexdump.

echo référent.pdf | hexdump -C
00000000 72 c3 a9 66 c3 a9 72 65 6e 74 2e 70 64 66 0a |référent.pdf.| 0000000f

echo référent.pdf | hexdump -C
00000000 72 65 cc 81 66 65 cc 81 72 65 6e 74 2e 70 64 66 |re?.fe?.rent.pdf| 00000010 0a |.|
00000011

Pour un peu plus de contexte, voici une version pure ASCII sans accents:

echo referent.pdf | hexdump -C
00000000 72 65 66 65 72 65 6e 74 2e 70 64 66 0a |referent.pdf.| 0000000d

Et lettre par lettre:

printf é | hexdump -C
00000000 c3 a9 |é|
00000002

printf e | hexdump -C
00000000 65 |e|
00000001

printf é | hexdump -C
00000000 65 cc 81 |e?.|
00000003

Le dernier é, c'est un e auquel on ajoute ensuite un accent aigu.

Le caractère Unicode U+0301 COMBINING ACUTE ACCENT est encodé cc81 en UTF-8.

Je dois m'arrêter là car mon train arrive en gare, mais une solution
pour contourner le problème pourrait être:

mv r?f?rent.pdf référent.pdf

Ceci change le nom de fichier pour utiliser la représentation la plus habituelle.

D'autres abonnés à cette liste pourront t'indiquer des outils pour le
faire automatiquement.

Amicalement,

Charles Plessy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Merci beaucoup pour cette première piste ! Oui, je pourrais renommer le fichier, c'est parfois ce que je fais, mais c'est assez fastidieux à faire à chaque fichier reçu ;-)


Comme proposé, j'ai essayé "mv r?f?rent.pdf référent.pdf", mais cela ne fonctionne pas.

Un simple "ls r?f?rent.pdf" m'indique "ls: impossible d'accéder à 'r?f?rent.pdf': Aucun fichier ou dossier de ce type" alors que "ls r*.pdf" me renvoie bien le fichier.


Dans mon précédent message, j'avais copié-collé l'affichage obtenu dans chaque terminal.
Du coup, j'ai repris l'idée d'utiliser hexdump avec le même fichier dans un répertoire. Pour comparer, j'ai ajouté un fichier que j'ai créé moi-même avec la commande "touch référent.pdf".

Avec "ls | hexdump -C", j'obtiens :

00000000 72 65 cc 81 66 65 cc 81 72 65 6e 74 2e 70 64 66 |re..fe..rent.pdf| 00000010 0a 72 c3 a9 66 c3 a9 72 65 6e 74 2e 70 64 66 0a |.r..f..rent.pdf.| 00000020

La deuxième ligne (fichier que j'ai créé) me semble assez bizarre avec un espace devant le premier "r" !

Autre bizarrerie, un affichage du contenu du répertoire sous midnight commander (mc) affiche les deux noms de fichiers correctement. J'ai l'impression que les "é" sont affichés de la même manière à moins que ls différences soient très subtiles.



Le ven. 28 oct. 2022 11:10, Charles Plessy <plessy@debian.org> a écrit:

From: Charles Plessy <plessy@debian.org>
Subject: Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)
To: debian-user-french@lists.debian.org
Mail-Followup-To: debian-user-french@lists.debian.org
Resent-From: debian-user-french@lists.debian.org

Le Fri, Oct 28, 2022 at 12:50:19AM +0200, Jean-Philippe Georget a écrit :

Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la commande "ls".

Par contre, sous xfce4-terminal, il s'affiche bizarrement comme "référent.pdf" (notez les accents décalés sur la droite des "e").

Bonjour,

c'est un problème de prise en charge d'Unicode.

Sur mon terminal, je vois référent.pdf dans les deux cas. Mais voici
ce que je vois si je copie-colle le nom de ficher et le passe à hexdump.

echo référent.pdf | hexdump -C
00000000 72 c3 a9 66 c3 a9 72 65 6e 74 2e 70 64 66 0a |référent.pdf.| 0000000f

echo référent.pdf | hexdump -C
00000000 72 65 cc 81 66 65 cc 81 72 65 6e 74 2e 70 64 66 |re?.fe?.rent.pdf|
00000010 0a |.|
00000011

Pour un peu plus de contexte, voici une version pure ASCII sans accents:

echo referent.pdf | hexdump -C
00000000 72 65 66 65 72 65 6e 74 2e 70 64 66 0a |referent.pdf.| 0000000d

Et lettre par lettre:

printf é | hexdump -C
00000000 c3 a9 |é|
00000002

printf e | hexdump -C
00000000 65 |e|
00000001

printf é | hexdump -C
00000000 65 cc 81 |e?.|
00000003

Le dernier é, c'est un e auquel on ajoute ensuite un accent aigu.

Le caractère Unicode U+0301 COMBINING ACUTE ACCENT est encodé cc81 en UTF-8.

Je dois m'arrêter là car mon train arrive en gare, mais une solution
pour contourner le problème pourrait être:

mv r?f?rent.pdf référent.pdf

Ceci change le nom de fichier pour utiliser la représentation la plus habituelle.

D'autres abonnés à cette liste pourront t'indiquer des outils pour le
faire automatiquement.

Amicalement,

Charles Plessy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

Pour des raisons de commodités, je vous conseille de
passer par "detox" pour les noms de fichiers...

Documentation :

https://linux.die.net/man/1/detox

https://forum.ubuntu-fr.org/viewtopic.php?id=282633


Merci pour votre aimable attention

Bien à vous

Bernard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

Le 2022-10-28 06:51, Jean-Philippe Georget a écrit :

Autre bizarrerie, un affichage du contenu du répertoire sous midnight commander (mc) affiche les deux noms de fichiers correctement. J'ai l'impression que les "é" sont affichés de la même manière à moins que
ls différences soient très subtiles.

Pareil ici en lisant ton e-mail via Roundcube dans Firefox. Mais ce
n'est que de l'affichage car si
je copie les noms de fichier et les passe dans `hexdump`, alors on voit
bien que les caractères sont
différents.

Tu pourrais peut-être essayer `convmv` : https://packages.debian.org/bookworm/convmv

Sébastien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le Fri, 28 Oct 2022 07:55:47 +0200 (CEST),
Bernard Schoenacker <bernard.schoenacker@free.fr> a écrit :

Bonjour,

Pour des raisons de commodités, je vous conseille de
passer par "detox" pour les noms de fichiers...

Oui et non. C'est très bien pour mettre sur un serveur web pas UTF8
dans les URL, mais je dois être trop bête pour comprendre comment ne pas
se retrouver avec des fichiers ____.txt au lieu de файл.txt et la romanisation de mes fichiers locaux ne m'arrange pas du tout !

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 28/10/2022 10:30:41, S�bastien NOBILI a �crit�:

Pareil ici en lisant ton e-mail via Roundcube dans Firefox.

Pareil avec Balsa.

nicolas patrois : pts noir asocial
--
R�ALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous consid�re comme des humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

Tout d'abord, je remercie tous les participants à ce fil de discussion qui m'ont permis de trouver une solution seulement aujourd'hui et après une bonne petite heure de recherche et de tests (car, oui, je n'ai pas trouvé tout de suite la solution ;-)


*Le problème*

Des caractères accentués de certains noms de fichiers sont codés sur deux caractères malgré le fait que ce soient des caractères Unicode.
Par exemple "é" est codé avec "e" et un accent aigu, "à" est codé avec "a" et un accent grave.

Cela cause des bizarreries quand on veut les renommer (il faut effacer deux caractères au lieu d'un, le curseur ne se positionne pas au bon endroit) ou les rechercher (on ne les retrouve pas, par exemple r?f.pdf ne permet pas de retrouver réf.pdf alors
que r??f.pdf permet le retrouver).


*Une solution*

Convertir le nom du fichier de utf-8 à utf-8 en respectant la norme NFC

convmv -f utf-8 -t utf-8 --nfc --notest filename


On peut aussi traiter récursivement une hiérarchie de dossiers/fichiers en ajoutant un "-r".

convmv -r -f utf8 -t utf8 --nfc --notest path/



*Une explication*

Les noms de fichier avec lesquels j'ai des problèmes proviennent d'ordinateurs fonctionnant sous MacOs.

Effectivement, le système de fichiers HFS (ou HFS+) de MacOs utilise une forme d'Unicode spécifique (no comment :-]), la forme NFD (NFC normalization form D). Or Linux utilise la forme NFC (normalization form C).

https://fr.wikipedia.org/wiki/Normalisation_Unicode
- Norme NFD (MacOs) : les caractères diacritiques sont codés sous une forme décomposée ("é" est en fait "e" + l'accent aigu)
- Norme NFC (Linux) : les caractères diacritiques sont codés sous une forme composée ("é" est un seul caractère unicode)


Quand on enregistre sur un ordinateur Linux un fichier créé sur MacOs, il n'y a pas de conversion entre les normes. Le nom de fichier codé en NFD reste en NFD, il n'est pas transformé en NFC. En particulier, deux noms de fichiers identiques à l'
affichage peuvent donc cohabiter dans le même dossier alors que ces noms sont différents puisque codés avec des caractères différents.

Intérêt des deux normes (pour ce que j'ai compris ;-)
NFC : un code par caractère affiché, pratique pour identifier de manière unique des lettres, des mots, etc.

NFD : pratique pour faire des recherches/comparaisons sans tenir compte des caractères diacritiques (accents, trémas, etc.). Une recherche sur le mot "education" (sans accent) permet aussi de retrouver "éducation".


Linus Torvalds déplore l'utilisation de la NFD pour le système de fichier HFS+
https://www.cio.com/article/251059/linus-torvalds-apples-hfs-is-probably-the-worst-file-system-ever.html


Et moi aussi, je le déplore ! ;-)
Jean-Philippe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

Le 2022-11-23 08:50, Jean-Philippe Georget a écrit :

*Une explication*

Merci pour l'explication :)

Sébastien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le mercredi 23 novembre 2022 à 08:50 +0100, Jean-Philippe Georget a écrit :

Bonjour,

Tout d'abord, je remercie tous les participants à ce fil de discussion qui m'ont permis de trouver une solution seulement aujourd'hui et après une bonne petite heure de recherche et de tests (car, oui, je n'ai pas trouvé tout de suite la solution ;-)

*Le problème*

Des caractères accentués de certains noms de fichiers sont codés sur deux caractères malgré le fait que ce soient des caractères Unicode.
Par exemple "é" est codé avec "e" et un accent aigu, "à" est codé avec "a" et un accent grave.

Cela cause des bizarreries quand on veut les renommer (il faut effacer deux caractères au lieu d'un, le curseur ne se positionne pas au bon endroit) ou les rechercher (on ne les retrouve pas, par exemple r?f.pdf ne permet pas de retrouver réf.pdf

alors que r??f.pdf permet le retrouver).

*Une solution*

Convertir le nom du fichier de utf-8 à utf-8 en respectant la norme NFC

convmv -f utf-8 -t utf-8 --nfc --notest filename

On peut aussi traiter récursivement une hiérarchie de dossiers/fichiers en ajoutant un "-r".

convmv -r -f utf8 -t utf8 --nfc --notest path/

*Une explication*

Les noms de fichier avec lesquels j'ai des problèmes proviennent d'ordinateurs fonctionnant sous MacOs.

Effectivement, le système de fichiers HFS (ou HFS+) de MacOs utilise une forme d'Unicode spécifique (no comment :-]), la forme NFD (NFC normalization form D). Or Linux utilise la forme NFC (normalization form C).

https://fr.wikipedia.org/wiki/Normalisation_Unicode
- Norme NFD (MacOs) : les caractères diacritiques sont codés sous une forme décomposée ("é" est en fait "e" + l'accent aigu)
- Norme NFC (Linux) : les caractères diacritiques sont codés sous une forme composée ("é" est un seul caractère unicode)

Quand on enregistre sur un ordinateur Linux un fichier créé sur MacOs, il n'y a pas de conversion entre les normes. Le nom de fichier codé en NFD reste en NFD, il n'est pas transformé en NFC. En particulier, deux noms de fichiers identiques à l'

affichage peuvent donc cohabiter dans le même dossier alors que ces noms sont différents puisque codés avec des caractères différents.

Intérêt des deux normes (pour ce que j'ai compris ;-)
NFC : un code par caractère affiché, pratique pour identifier de manière unique des lettres, des mots, etc.

NFD : pratique pour faire des recherches/comparaisons sans tenir compte des caractères diacritiques (accents, trémas, etc.). Une recherche sur le mot "education" (sans accent) permet aussi de retrouver "éducation".

Linus Torvalds déplore l'utilisation de la NFD pour le système de fichier HFS+
https://www.cio.com/article/251059/linus-torvalds-apples-hfs-is-probably-the-worst-file-system-ever.html

Et moi aussi, je le déplore ! ;-)
Jean-Philippe

En tout cas, ton explication claire et détaillée t'honore.... Merci.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)