La magie des caractères accentués entre Mac et Linux

Cet article a été publié il y a 6 ans 1 mois 25 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Ah, UTF-8… Pendant que tout le monde s’écharpe pour savoir quelle est la bonne recette d’hamburger sur l’émoji dédié, les techniciens, eux, doivent se débattre avec des choix étranges et des problèmes de compatibilité. De ceux que la norme Unicode était pourtant censé régler…

J’ai mis un peu de temps à mettre le doigt dessus, et à trouver le fond du problème. Quant à la solution, elle n’était pas forcément entre mes mains mais pas si loin. Mais reprenons depuis le début. Lors de la refonte du site d’un de mes clients, il se plaint que certains liens ne fonctionnent pas une fois le livrable déposé sur le serveur. En particulier, les liens vers des documents PDF qui contiennent des accents semblent contrariants.

Pourtant, sur le serveur, les documents sont là, avec les accents correctement placés et affichés. Je soupçonnais un problème d’encodage (genre ISO-8859-15 et UTF-8, la bataille du siècle dernier), ce n’était pas le cas mais je n’en étais pas loin. A force de recherches, de fouilles empiriques comme je peux en faire parfois, je mets le doigt sur quelque chose : en copiant le nom du fichier depuis ma console SSH pour le saisir dans mon navigateur, je découvre une chose :

Oui, on constate que les caractères accentués n’ont pas la même tête. Pourtant les deux s’affichent de la même façon à nos yeux. Comment est-ce possible ? Malheureusement, j’ai fait cette découverte juste avant de m’absenter pour me faire opérer, et après avoir transmis mes découvertes, nous n’avons pas eu de retour de l’agence. Mes collègues n’ont pas plus trouvé de détails supplémentaires sur les raisons de cet écart, et le dossier est un peu tombé aux oubliettes.

Mais pendant ma convalescence, à la faveur de ma veille habituelle, je lis une remarque sur les joies de l’encodage entre Mac et Linux, sans plus de détails. Pour une fois mon cerveau fait tilt et je repense à mon client. Je repars donc en mode recherche/lectures, pas évident, et pourtant les utilisateurs de Mac partagent souvent leur mésaventures avec leur univers fermé. Mais je finis par trouver quelques pistes.

MacOS le fourbe (enfin pas vraiment, mais ça fait du bien de le dire de temps en temps)

En effet, UTF-8 permet d’encoder les caractères accentués de deux façons différentes : soit un caractère accentué « direct » dit composé — U+00E9 pour être précis si on reprend notre « é »– ou format NFC pour Fully Composed; soit un caractère di décomposé, c’est à dire la lettre de base –U+0065 pour la lettre e–, accompagné d’un caractère dit combinant, dans l’exemple un accent aigu (U+0301), soit le format NFD pour Fully Decomposed. Évidemment il n’est pas recommandé de mixer les deux méthodes. Pour les plus furieux, et en anglais, vous pouvez lire cette page Wikipedia sur l’équivalence Unicode.

C’est MacOS le responsable, qui encode les caractères de manière particulière, et notamment les caractères accentués. Les ingénieurs d’Apple ont fait le choix du supporter le deuxième cas, mais le plus « pénible » n’est pas là. Les deux sont valides et pris en charge notamment par le système de fichiers ext4 sous Linux, et on ne verra pas de différence jusqu’à ce qu’on tombe sur un problème similaire à celui que j’ai rencontré. En fait le vrai problème vient surtout du fait que l’éditeur de code utilisé par le développeur qui s’était occupé de renommer les documents a encodé les liens, et plus généralement les fichiers, au format NFC, quand les fichiers sont proposés au format NFD.

Si c’est supporté, alors on peut corriger

On est sous Linux, on peut pratiquement tout faire, en l’occurrence c’est possible avec rsync :

On peut alors ensuite replacer le contenu converti au bon endroit. Peu après j’ai appris qu’il y avait un utilitaire dédié à cette tâche, qui s’appelle convmv :

Ça va traiter tous les fichiers du dossier indiqué, et on économise une duplication de fichiers. L’avantage d’rsync étant qu’on peut le faire à distance, donc directement depuis la source et non pas une fois le contenu versé à destination.

Une fois n’est pas coutume, je n’ai pas pu essayer

Malgré tout, quand j’ai eu l’occasion de reprendre le dossier, après mon retour, une solution un peu plus simpliste a été trouvée par l’agence de développement sans qu’on soit mis au courant : supprimer les accents sur les liens et fichiers problématiques. Bon ben tant pis, on essaiera de faire plus de bricolage une prochaine fois. Ça m’a toutefois donné l’occasion de vous apprendre un ou deux trucs sur Unicode 🙂