Salut, On Thu, Apr 18, 2024 at 07:55:41AM +0200, felix via gull wrote: > Attention! L'UTF8 de Apple n'est pas forcement le même que celui de Linux... > > voire: > Général Bâtiment > Général Bâtiment
C'est juste. En fait, il s'agit ici de la normalisation Unicode: > 00000000 47 65 cc 81 6e 65 cc 81 72 61 6c 20 42 61 cc 82 |Ge..ne..ral Ba..| > 00000000 47 c3 a9 6e c3 a9 72 61 6c 20 42 c3 a2 74 69 6d |G..n..ral B..tim| é = U+0065 U+0301 = en UTF8: 0x65 0xcc 0x81 (normalisation NFD) é = U+00E9 = en UTF-8: 0xc3 0xa9 (normalisation NFC) En bref, et sans entrer dans les détails, Unicode encode des caractères sous forme de point(s) de code(s): soit sous la forme d'un seul point de code (un seul caractère), soit sous la forme de deux points de code. En effet "é" est U+00E9 (donc 0xc3 0xa9 en UTF-8) en normalisation composée (NFC) ou U+0065 U+0301 en normalisation décomposée (NFD, ce qui se traduit en 0x65 0xcc 0x81 en UTF-8). Sous macOS X, il semblerait que parfois la normalisation NFD est utilisée lorsque l'utilisateur a tapé pomme , e ou une séquence équivalente de composition pour un clavier qui ne dispose pas forcément d'une touche "é". Il est en théorie possible de produire ces 2 encodages différents même sous macOS X. Que veut en fait dire U+0065 U+0301? Le point de code ASCII pour le e, suivi du point de code de contrôle "ajouter un accent aigu diacritique sur le caractère précédent". Il semblerait, sous macOS X, que si l'on ne tape pas la lettre "é" directement sur le clavier, mais la séquence de composition pomme , e (ou approchant), on ait plus de chance de produire un caractère en normalisation NFD. L'avantage de la normalisation décomposée est que c'est trivial d'enlever tous les accents pour ne conserver que l'ASCII. La NFC est plus compacte, et compter les points de code donne le nombre de caractères. Evidemment les 2 chaînes UTF-8 sont différentes en comparaison octet par octet, ce qui explique le symptôme macOS X voit deux fichiers. Pour assurer l'interopérabilité, les implémentations devraient probablement tout convertir à l'entrée dans leur représentation préférée, par exemple NFC. Une vieille règle réseau était: soyez souple dans ce que vous acceptez, et strict dans ce que vous émettez (dans certains cas, dont la sécurité, cette vieille règle est décriée). A ce sujet, je vous recommande la documentation de la plateforme -- dont le nouveau nom et logo ressemblent à un protocole de système de fenêtrage bien plus connu -- sur les limites en nombre de "caractères" de cette plateforme, qui donne déjà quelques pistes sur le fait que ma description ci-dessus est bien trop simple pour refléter la complexité magnifique d'Unicode :) [1] Malheureusement, la plupart des systèmes de fichiers, ext4 y compris, sont agnostiques face au jeu de caractère (*): il ne traite que des flots d'octets. En conséquence, les interfaces utilisateurs, en particulier graphiques, devraient probablement marquer le 2e fichier au nom "identique" dans une même normalisation comme duplicat, en avertissant l'utilisateur, vu que ces duplicats peuvent se créer dans le fs. De fait, ce qu'on observe dans le GUI Linux, c'est que 2 fichiers sont présentés avec le même nom. Sous Microsoft et macOS X, souvent seulement un des deux fichiers est accessible, respectivement montré. [1] https://developer.twitter.com/en/docs/counting-characters (*) ce qui a l'avantage de confiner Unicode en user-space et d'éviter le kernel-bloat. PS: il semblerait que l'outil convvm, disponible sous Debian dans le package du même nom, permette de faciliter les conversions de normalisation en masse; je signale également le module fuse-convmfs qui est un système de fichier en couche (layering filesystem) pour convertir des noms de fichiers. _______________________________________________ gull mailing list gull@forum.linux-gull.ch https://forum.linux-gull.ch/mailman/listinfo/gull