[gull] exfat - inconsistence du catalogue sous Linux et macOS

[Marc SCHAEFER]

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.