← Tous les articles

Compresser sur Mac pour Windows sans casser les noms

Si vous venez de compresser un dossier sur Mac pour Windows et que vos collègues vous répondent que les noms sont bizarres (« Hélène » devient « Helene » avec un accent qui se balade, 한글 se transforme en ㅎㅏㄴㄱㅡㄹ, ou Excel affirme que le fichier n'existe pas), l'archive elle-même n'est pas abîmée. Deux habitudes de macOS sont en cause : le système enregistre souvent les noms accentués, coréens ou japonais dans une forme Unicode dite décomposée (NFD) que Windows n'attend pas, et la commande « Compresser » du Finder ajoute un dossier caché __MACOSXrempli de copies._` de chaque fichier. La solution côté expéditeur consiste à normaliser les noms en NFC avant de compresser, puis à créer le ZIP avec un outil qui laisse de côté les métadonnées Mac. Cet article détaille cet ordre des opérations, et explique quoi faire si l'archive est déjà partie.

Pourquoi un ZIP créé sur Mac affiche des noms cassés sous Windows

Trois phénomènes distincts se mélangent, et il vaut mieux savoir lequel vous avez sous les yeux.

Les caractères décomposés (NFD). macOS écrit depuis longtemps les noms de fichiers en NFD : « é » est stocké sous la forme d'un « e » suivi d'un accent combinant séparé, « ç » devient « c » plus une cédille combinante, et une syllabe coréenne est stockée sous forme de jamo individuels. Windows, la plupart des serveurs web et la quasi-totalité des programmes Windows attendent la forme composée (NFC), où « é » est un seul caractère. L'Explorateur Windows dessine en général la lettre accentuée correctement, mais le nom est techniquement différent de ce que vous avez tapé. C'est pour cela qu'un collègue peut voir Facture_Hélène.xlsx à l'écran et obtenir quand même « fichier introuvable » quand une macro, un script ou un lien SharePoint cherche l'orthographe NFC. Avec les noms coréens et japonais, c'est plus visible : les syllabes se décomposent sous vos yeux, et les dakuten se détachent de leur kana (が devient か suivi de ゛).

Le dossier __MACOSX et les fichiers ._. Quand vous faites un clic droit puis « Compresser » dans le Finder, macOS range les resource forks et les métadonnées du Finder dans des entrées ._nomdufichier à l'intérieur d'un dossier __MACOSX. Windows n'en a aucun usage. Ces fichiers sont inoffensifs, mais ils doublent le nombre d'éléments, font croire à certains qu'il s'agit de versions corrompues, et déclenchent des refus sur certains formulaires d'envoi.

L'encodage, pas la normalisation. Si les noms arrivent sous la forme Hélène ou d'une série de points d'interrogation, c'est un autre problème : l'outil de décompression côté Windows a lu les noms avec le mauvais jeu de caractères. L'Explorateur Windows récent et 7-Zip gèrent correctement les noms UTF-8 des ZIP créés par un macOS actuel, donc cela ne se produit plus guère qu'avec de très vieux utilitaires. Cet article ne traite pas ce cas ; il porte sur le NFD et le dossier en trop.

Compresser un dossier sur Mac pour Windows : les étapes

Suivez-les dans l'ordre. Corriger les noms après compression oblige à refaire l'archive, donc normalisez d'abord.

1. Vérifier si vos noms sont vraiment en NFD

Le Finder ne permet pas de voir le NFD. Deux méthodes rapides :

  • Ouvrez le Terminal, faites un cd vers le dossier, puis lancez ls | python3 -c "import sys,unicodedata; [print(repr(n)) for n in sys.stdin.read().splitlines() if unicodedata.normalize('NFC', n) != n]". Tout nom affiché est en NFD.
  • Ou copiez un nom de fichier depuis la fenêtre « Lire les informations » du Finder et collez-le dans le convertisseur de texte de l'application web FilenameFixer. Si le texte converti diffère de ce que vous avez collé, le nom est décomposé.

Les noms purement ASCII (rapport_2026.pdf) ne sont jamais concernés. Seuls comptent les lettres latines accentuées (é, è, ç, à, ô…), le hangul, les kana avec dakuten ou handakuten et les caractères du même genre.

2. Normaliser les noms en NFC

Sur un Mac avec un disque APFS (tout Mac sous macOS 10.13 ou plus récent sur son disque interne), un fichier renommé conserve la forme que vous lui donnez. Plusieurs options :

  • Renommage par lot dans le navigateur. Glissez les fichiers sur l'application web FilenameFixer, vérifiez la liste avant/après, puis téléchargez les fichiers renommés. Le traitement se fait localement dans votre navigateur ; rien n'est envoyé sur un serveur. C'est la voie la plus simple pour un dossier mêlant des documents venus de collègues coréens ou japonais.
  • Terminal, une seule ligne. Dans le dossier, lancez python3 -c "import os,unicodedata; [os.rename(n, unicodedata.normalize('NFC', n)) for n in os.listdir('.') if unicodedata.normalize('NFC', n) != n]" Cette commande ne renomme que le premier niveau du dossier courant ; répétez-la dans les sous-dossiers, ou étendez-la avec os.walk si vous êtes à l'aise.
  • Les utilisateurs de Homebrew peuvent installer convmv et lancer convmv -f utf8 -t utf8 --nfc -r --notest . sur le dossier.

Attention : sur un volume HFS+ (anciens Mac, ou disque externe formaté en « Mac OS étendu »), le système de fichiers réimpose le NFD, et le renommage semble ne rien faire. Dans ce cas, passez directement à la section sur la correction du ZIP terminé.

3. Compresser sans le dossier __MACOSX

La commande « Compresser » du Finder ajoute toujours le dossier de métadonnées. Utilisez plutôt l'une de ces méthodes :

  • Terminal avec zip : zip -r -X archive.zip NomDuDossier. L'option -X supprime les attributs étendus. Pour écarter aussi les fichiers .DS_Store, utilisez zip -r -X archive.zip NomDuDossier -x "*.DS_Store".
  • Terminal avec ditto : ditto -c -k --norsrc --noextattr NomDuDossier archive.zip. C'est l'outil d'Apple, et il produit un ZIP propre, parfaitement lisible sous Windows.
  • Keka (archiveur gratuit tiers) propose dans ses Préférences une option pour exclure les resource forks Mac ; activez-la avant de compresser.

zip comme ditto écrivent des noms en UTF-8 avec le bon indicateur, donc l'Explorateur Windows actuel et 7-Zip les lisent correctement.

4. Vérifier avant d'envoyer

Lancez unzip -l archive.zip dans le Terminal. Vous ne devez voir que vos fichiers et dossiers, sans ligne __MACOSX ni entrée ._. Pour être rigoureux sur le NFD, faites passer cette liste dans la vérification Python de l'étape 1.

Si le ZIP est déjà parti, ou si votre disque est en HFS+

Il arrive que l'archive ait déjà été envoyée, ou que vous travailliez sur un volume HFS+ où le renommage ne tient pas. Dans les deux cas, vous pouvez corriger les noms à l'intérieur de l'archive terminée sans toucher aux fichiers d'origine.

L'outil de restauration des noms dans un ZIP accepte une archive jusqu'à 200 Mo, réécrit chaque nom d'entrée NFD en NFC et vous propose un ZIP corrigé à télécharger. Le contenu des fichiers n'est pas modifié et le traitement reste dans votre navigateur. Envoyez l'archive corrigée en remplacement, ou demandez au destinataire de passer l'original par la même page de son côté. L'outil ne retire pas le dossier __MACOSX ; si c'est important, recréez l'archive avec ditto ou zip -X comme décrit plus haut, une fois les noms normalisés.

Si vous préférez vous passer d'outils, le destinataire Windows peut tout simplement retaper les noms concernés après extraction. Pour une poignée de fichiers, c'est plus rapide que tout le reste. Pour un dossier de deux cents documents aux noms coréens, non.

Quoi dire à votre collègue sous Windows

Un petit mot évite bien des allers-retours. Par exemple :

  1. Décompresse avec « Extraire tout » dans l'Explorateur ou avec 7-Zip ; les deux lisent correctement les ZIP créés sur Mac.
  2. Supprime le dossier __MACOSX s'il y en a un. Les fichiers ._ qu'il contient ne sont pas des copies abîmées, juste des métadonnées Mac.
  3. Si un programme n'arrive toujours pas à ouvrir un fichier dont le nom paraît correct, c'est que le nom est en forme décomposée. Renomme-le à la main, ou dépose les fichiers extraits sur l'application web FilenameFixer pour les renommer par lot.

Les développeurs côté réception peuvent confirmer la cause dans PowerShell : [Text.Encoding]::UTF8.GetByteCount("café") renvoie 5 pour l'orthographe NFC et 6 pour le NFD. Node, Python et .NET exposent tous normalize("NFC") si un script doit accepter les deux formes.

Limites et problèmes voisins qui se ressemblent

  • Chemins trop longs. Windows limite les chemins complets à 260 caractères, sauf si la prise en charge des chemins longs est activée. Des dossiers Mac très imbriqués aux noms longs peuvent échouer à l'extraction, normalisation ou pas. Raccourcissez le nom du dossier racine avant de compresser.
  • Les archives de plus de 4 Go nécessitent ZIP64 ; zip et ditto sur un macOS récent le gèrent, mais certains vieux outils Windows non.
  • Les ZIP protégés par mot de passe créés avec zip -e utilisent un chiffrement ancien, que 7-Zip ouvre mais pas l'Explorateur Windows. Ce n'est pas un problème de nom, mais cela génère les mêmes courriels « ça ne marche pas sous Windows ».
  • Caractères interdits. Les noms contenant :, ?, *, |, <, > ou " sont autorisés sur macOS mais pas sur Windows, et l'Explorateur les refusera ou les renommera à l'extraction. La normalisation NFC n'y change rien ; vous devez les remplacer vous-même.
  • Aller-retour. Si l'utilisateur Windows modifie les fichiers et renvoie un ZIP, rien ne casse : les noms NFC sont conservés sur APFS. Le problème n'existe que dans le sens Mac vers Windows.

Normalisez d'abord, compressez avec ditto ou zip -X, vérifiez la liste, et les réponses « les noms sont cassés » s'arrêtent. Si l'archive est déjà dans la boîte de réception de quelqu'un, réécrire les noms à l'intérieur du ZIP reste le remplacement le plus rapide à envoyer.