FfFilenameFixer
← Tous les articles

Noms de fichiers ZIP illisibles sous Windows (archive Mac)

Si les noms de fichiers d'une archive ZIP deviennent illisibles après un transfert d'un Mac vers Windows, il n'y a que deux causes probables, et les deux se corrigent sans modifier le contenu des fichiers. Soit l'archive stocke les noms dans un encodage que Windows lit mal (vous voyez des choses comme José.pdf), soit les noms sont enregistrés dans la forme Unicode décomposée utilisée par macOS, si bien que les accents et les syllabes coréennes ou japonaises apparaissent découpés en morceaux (Jose´.pdf, ㅂㅗㄱㅗㅅㅓ.docx). Le premier cas se règle en extrayant l'archive avec un autre outil ; le second en normalisant les noms en NFC, ce qui se fait dans le navigateur ou avec une courte commande PowerShell. Les étapes ci-dessous couvrent les deux cas.

Pourquoi les noms de fichiers ZIP deviennent illisibles entre Mac et Windows

Le format ZIP enregistre chaque nom de fichier sous forme d'octets bruts, accompagnés d'un petit indicateur qui précise si ces octets sont en UTF-8. Les données à l'intérieur des fichiers ne sont jamais touchées, ce qui explique que les documents s'ouvrent normalement une fois extraits. Seules les étiquettes sont cassées.

La situation type ressemble à ceci. Un collègue sur Mac sélectionne un dossier dans le Finder, choisit Compresser, puis vous envoie le .zip par e-mail ou sur Teams. Vous double-cliquez dessus dans l'Explorateur de fichiers, choisissez Extraire tout, et le dossier obtenu contient des noms comme :

  • Zoé¨_facture.xlsx au lieu de Zoë_facture.xlsx
  • Hélène´ Contrat.pdf au lieu de Hélène Contrat.pdf
  • ㅎㅏㄴㄱㅡㄹ.docx au lieu de 한글.docx
  • か゛いよう.pptx au lieu de がいよう.pptx

Dans l'autre cas de figure, le nom est carrément incompréhensible, par exemple José Contrat.pdf ou 한글.docx.

Il s'agit de deux problèmes distincts qui se ressemblent :

Problème d'encodage (texte brouillé, ou « mojibake »). L'outil de compression a écrit des octets UTF-8 sans les signaler comme tels, et l'extracteur de Windows les a interprétés avec la page de codes héritée du système. On obtient des suites de majuscules accentuées et de symboles sans rapport avec le nom d'origine. Le nom réel n'est pas abîmé : il a simplement été mal décodé.

Unicode décomposé (NFD). macOS enregistre de nombreux noms avec les accents et les signes diacritiques comme caractères séparés : le é devient un e suivi d'un accent aigu combinant, le 한 devient les jamos ㅎ + ㅏ + ㄴ, le が devient か + ゛. Le nom est techniquement correct en Unicode, et Windows l'accepte, mais Windows, la plupart des formulaires web et la plupart des serveurs attendent la forme composée (NFC). Les lettres s'affichent donc bizarrement, la recherche dans l'Explorateur ne les trouve pas, les scripts qui comparent des noms échouent, et les formulaires d'envoi peuvent rejeter ou dupliquer les fichiers. C'est le cas de Jose´ et de ㅎㅏㄴㄱㅡㄹ.

Pour les distinguer, il suffit de dix secondes. Commencez donc par là.

Étape 1 : identifier votre problème

Ouvrez le dossier extrait (ou affichez simplement le ZIP dans l'Explorateur sans l'extraire) et regardez l'un des noms défectueux.

  1. Si le nom contient des caractères qui ne font partie d'aucun mot réel (é, í•œ, ’), c'est un problème d'encodage. Passez directement à la correction B.
  2. Si le nom est lisible mais que les lettres et leurs accents semblent légèrement séparés, ou si le coréen apparaît sous forme de consonnes et voyelles isolées, c'est de la forme NFD. Vérifiez avec ce test rapide :
    • Faites un clic droit sur le fichier et choisissez Renommer.
    • Appuyez sur Fin, puis sur Retour arrière une seule fois.
    • Si seul l'accent (ou seule la voyelle, ou le dakuten) disparaît et que la lettre de base reste, le nom est décomposé. Dans un nom normal en NFC, un seul appui sur Retour arrière supprime le é entier ou la syllabe entière.

Si vous êtes à l'aise avec PowerShell, la commande suivante vous le dit directement :

Get-ChildItem -Recurse -File | Where-Object {
  -not $_.Name.IsNormalized([Text.NormalizationForm]::FormC)
} | Select-Object FullName

Chaque fichier listé est au format NFD.

Correction A : noms de fichiers ZIP abîmés par la forme NFD (accents séparés, syllabes coréennes découpées)

Vous avez deux solutions raisonnables. La première se fait entièrement dans le navigateur et conserve l'archive telle quelle ; la seconde renomme les fichiers après l'extraction.

Option 1 : réparer les noms à l'intérieur du ZIP dans le navigateur

C'est la solution la moins contraignante si vous voulez renvoyer le ZIP à quelqu'un d'autre ou le conserver intact.

  1. Ouvrez l'outil de restauration des noms de fichiers ZIP dans votre navigateur.
  2. Glissez le .zip depuis votre dossier Téléchargements vers la page (les archives jusqu'à 200 Mo sont prises en charge).
  3. L'outil réécrit les noms de fichiers à l'intérieur de l'archive, de la forme NFD vers la forme NFC, et vous propose de télécharger un ZIP corrigé.
  4. Extrayez le nouveau ZIP avec Extraire tout comme d'habitude. Des noms comme José Contrat.pdf et 한글.docx s'affichent maintenant correctement, et la recherche dans l'Explorateur les retrouve.

Le traitement se fait localement dans votre navigateur : l'archive et ses noms ne sont pas envoyés vers un serveur, ce qui compte lorsque le ZIP contient des contrats clients ou des documents RH. L'outil est gratuit. Si vous avez déjà extrait les fichiers et n'avez plus que des fichiers isolés, le même site permet de les glisser-déposer pour un renommage par lot.

Option 2 : renommer après extraction avec PowerShell

Windows fournit tout ce qu'il faut pour normaliser les noms : .NET fait de la normalisation Unicode depuis des années. Travaillez d'abord sur une copie du dossier, car ce script renomme les fichiers sur place.

  1. Extrayez le ZIP normalement.
  2. Ouvrez le dossier extrait, cliquez dans la barre d'adresse, tapez powershell puis appuyez sur Entrée. Une fenêtre PowerShell s'ouvre dans ce dossier.
  3. Collez le code suivant et appuyez sur Entrée :
Get-ChildItem -Recurse -File | ForEach-Object {
  $nfc = $_.Name.Normalize([Text.NormalizationForm]::FormC)
  if ($nfc -ne $_.Name) {
    Rename-Item -LiteralPath $_.FullName -NewName $nfc
  }
}
  1. Relancez-le en remplaçant -File par -Directory si les noms de dossiers sont eux aussi touchés (renommez les dossiers après les fichiers qu'ils contiennent, sinon les chemins changent en cours de route).

Cette méthode convient aux cas ponctuels et aux développeurs qui veulent l'intégrer dans un script de build. Son inconvénient : elle ne touche pas au ZIP d'origine, et il est facile de l'exécuter dans le mauvais répertoire.

Correction B : noms de fichiers ZIP abîmés par un problème d'encodage

Si vous voyez un texte brouillé du type José, la normalisation ne servira à rien : il faut d'abord que les octets soient décodés en UTF-8.

  1. Installez 7-Zip (gratuit, sur 7-zip.org) ou un autre logiciel d'archivage tiers. Ces outils lisent en général correctement les noms en UTF-8, même lorsque l'indicateur UTF-8 manque, et c'est là que l'extracteur intégré de Windows échoue souvent.
  2. Faites un clic droit sur le ZIP et choisissez 7-Zip → Extraire ici (ou Extraire vers « nomdudossier\ »).
  3. Vérifiez les noms. S'ils sont maintenant lisibles, c'est terminé.
  4. S'ils sont lisibles mais que des accents ou des syllabes coréennes sont découpés, vous aviez les deux problèmes à la fois. Revenez à la correction A et normalisez les fichiers extraits.

Si un extracteur tiers produit encore du charabia, c'est que l'expéditeur a utilisé un encodage hérité et non l'UTF-8. Dans ce cas, le plus rapide est de demander à l'expéditeur de recompresser l'archive. Sur Mac, la commande Compresser intégrée et la plupart des applications tierces écrivent en UTF-8 ; le problème vient en général d'un outil ancien ou inhabituel, ou d'un ZIP qui a été recompressé sur un ordinateur Windows configuré avec une autre langue système.

Éviter le problème la prochaine fois

Quelques habitudes suffisent à éliminer la plupart de ces désagréments, des deux côtés de l'échange.

Si vous envoyez depuis un Mac : avant de compresser, vous pouvez passer le dossier dans un outil de normalisation pour que les noms soient déjà en NFC. Vous pouvez aussi éviter le ZIP et partager un lien vers votre espace de stockage en ligne. La plupart de ces services normalisent les noms à l'envoi, mais pas tous : vérifiez une fois avec un fichier test. Pour les fichiers envoyés par des formulaires web plutôt que dans un ZIP, l'extension Chrome FilenameFixer corrige automatiquement les noms de fichiers au moment de l'envoi sur les sites, ce qui évite que le formulaire du destinataire refuse un fichier Zoë.xlsx parce qu'il ne correspond pas au Zoë déjà présent chez lui.

Si vous recevez sous Windows : gardez 7-Zip ou un outil équivalent installé. Lorsqu'une archive créée sur Mac arrive avec des noms en coréen, en japonais ou avec des accents, faites le test de dix secondes avec Retour arrière avant de perdre du temps à renommer à la main. Le renommage manuel est particulièrement peu fiable ici : dans la plupart des polices, les noms décomposés et composés se ressemblent à s'y méprendre, et vous finirez avec deux fichiers qui semblent porter le même nom.

Si vous êtes développeur : normalisez en NFC à la frontière de votre application, que ce soit dans le gestionnaire d'envoi de fichiers, un script de synchronisation ou une étape de build. unicodedata.normalize("NFC", name) en Python, name.normalize("NFC") en Node et String.Normalize() en .NET font le travail. C'est bien moins coûteux que de chercher pourquoi un test passe sur macOS et échoue sur le runner Linux de votre CI, parce que deux noms de fichiers « identiques » sont en réalité deux suites d'octets différentes.

Rien de tout cela ne modifie les documents eux-mêmes : le contenu n'est pas en danger. Au pire, une mauvaise supposition vous obligera à extraire l'archive une seconde fois.