Vérificateur de noms de pièces jointes MIME
Collez la source brute .eml (RFC 822 / MIME) ou sélectionnez un fichier .eml pour repérer les noms de pièces jointes déclarés qui ne pourraient pas être enregistrés, seraient modifiés silencieusement ou différeraient selon les clients sous Windows, macOS ou Linux.
Traitement effectué localement dans votre navigateur. Votre fichier n’est jamais téléversé.
Comment utiliser cet outil outil
- Collez la source .eml brute ou sélectionnez un fichier .eml ; rien ne quitte votre navigateur.
- Sélectionnez « Vérifier les noms des pièces jointes ».
- Examinez chaque nom signalé et les systèmes ou clients concernés.
- Utilisez les réécritures proposées : substitution de caractères, suffixe aux noms de périphériques réservés, suppression des points/espaces finaux et encodage RFC 2231 sont mécaniques. Les divergences d'en-têtes et heuristiques sont expliquées, pas corrigées par supposition.
Hypothèses
- Reconnaît huit problèmes : caractères réservés Windows, noms de périphériques réservés Windows, points/espaces finaux, absence de repli de nom simple pour la forme étendue RFC 2231, noms dépassant la limite courante de 255 octets, divergence de nom entre Content-Disposition/Content-Type, motif de double extension et octets non ASCII sans encodage RFC 2231/2047.
- Réutilise l'analyseur .eml/MIME limité du microsite pour localiser les noms déclarés de chaque partie ; l'analyse MIME n'est pas réimplémentée.
- Quand filename de Content-Disposition et name de Content-Type sont tous deux présents et concordent, filename est considéré comme le nom généralement utilisé par le client pour enregistrer le fichier. En cas de divergence, les deux sont affichés et signalés.
- Un message sans pièce jointe (sans Content-Disposition: attachment et sans paramètre filename/name) donne zéro problème ; ce n'est pas un défaut à signaler.
Sources et données de référence
Méthodologie
Le texte brut est interprété comme arbre de parties MIME ; les paramètres filename/name de Content-Disposition et Content-Type sont examinés. Chaque nom est comparé aux règles documentées des systèmes Windows/macOS/Linux et aux exigences RFC 2183/2231/6266. Une réécriture n'est proposée que pour un changement mécanique sans ambiguïté : remplacer des caractères réservés, suffixer un nom de périphérique réservé, retirer les points/espaces finaux, ajouter une solution de repli simple pour un nom RFC 2231 étendu décodé en ASCII et encoder un nom non ASCII avec RFC 2231. Les divergences d'en-têtes et le double suffixe sont seulement signalés : l'outil ne devine ni le nom voulu ni ne renomme selon une heuristique.
Exemple détaillé
Nom PDF contenant deux-points et point d'interrogation
Données d’entrée: Content-Disposition: attachment; filename="Q3 report: draft?.pdf"
Résultat: Windows (NTFS/exFAT) refuse < > : " / \ | ? *, même s'ils sont permis sous Linux/macOS. Erreur ; remplacement sûr de chaque caractère réservé par `_`.
Pièce jointe .txt nommée exactement `con.txt`
Données d’entrée: Content-Disposition: attachment; filename="con.txt"
Résultat: Windows réserve CON, PRN, AUX, NUL, COM1-COM9 et LPT1-LPT9 quelle que soit l'extension. Erreur avec ajout sûr d'un souligné : `con_.txt`.
Exécutable dissimulé derrière une extension de document
Données d’entrée: Content-Disposition: attachment; filename="invoice.pdf.exe"
Résultat: Une extension apparemment sûre suivie d'une extension exécutable est un motif connu de dissimulation de logiciel malveillant. Avertissement heuristique, pas certitude ; aucun renommage automatique, cette décision appartient au destinataire.
Conseils pratiques
- Évitez dans les noms contrôlés les caractères réservés Windows (< > : " / \ | ? *) et les noms de périphériques réservés (CON, PRN, AUX, NUL, COM1-COM9, LPT1-LPT9) ; l'enregistrement échouera sous Windows quel que soit le client expéditeur.
- Pour un nom non ASCII, utilisez la forme étendue RFC 2231 (`filename*=UTF-8''percent-encoded`) et ajoutez un repli ASCII simple `filename=` pour les clients anciens ou simples.
- Ne faites jamais confiance au seul Content-Type pour identifier sûrement une pièce jointe ; une extension sûre suivie d'une extension exécutable est une technique documentée de dissimulation.
- Gardez les noms bien en dessous de 255 octets UTF-8 ; certaines passerelles et certains systèmes anciens tronquent plus tôt.
Erreurs fréquentes
- Supposer qu'un nom affiché correctement par le client expéditeur s'enregistrera partout : caractères ou noms réservés ne posent problème qu'à la création du fichier chez le destinataire.
- Traiter `filename*=` et `filename=` comme équivalents : un client ne comprenant pas la forme RFC 2231 étendue peut afficher un nom vide ou illisible sans valeur de repli simple.
Questions fréquentes
Pourquoi un caractère réservé est-il une erreur et une divergence d'en-têtes un avertissement ?
Un caractère ou nom de périphérique réservé échouera à l'enregistrement sous Windows ; il n'y a pas d'ambiguïté. Une divergence Content-Disposition/Content-Type est ambiguë : les clients réels peuvent choisir l'un ou l'autre, donc risque réel mais échec non garanti.
Pourquoi l'outil ne renomme-t-il pas un fichier signalé par le contrôle de double extension ?
C'est une heuristique avec de faux positifs possibles, par exemple un fichier légitime nommé `summary.pdf.bak`. Renommer une vraie pièce jointe sur une supposition relève du destinataire.
L'outil décode-t-il ou affiche-t-il le contenu des pièces jointes ?
Non. Il inspecte seulement Content-Disposition et Content-Type pour lire le nom déclaré ; le corps réel des pièces jointes n'est ni décodé ni affiché.
Pourquoi le nom d'une pièce jointe semble-t-il illisible ou change-t-il à l'enregistrement ?
Les clients traitent différemment les paramètres MIME, notamment les noms RFC 2231, l'absence de repli simple, le texte non ASCII brut ou des déclarations filename contradictoires dans Content-Disposition et Content-Type. Ce vérificateur examine ces problèmes de portabilité déclarés ; il n'inspecte pas le contenu et ne prédit pas le nom exact enregistré par chaque client.
Dernière vérification : 2026-09-26
Vérifie uniquement les noms déclarés, pas le contenu des pièces jointes ; réutilise un analyseur .eml/MIME spécialisé et limité, pas une bibliothèque complète. Les structures MIME très inhabituelles au-delà de l'imbrication multipart courante ne sont pas analysées. La limite courante de 255 octets est approchée par comptage UTF-8 ; certains systèmes et passerelles tronquent plus tôt sans être signalés individuellement.
Cet outil fournit une estimation indicative fondée sur les hypothèses indiquées ci-dessus.
Les préférences de thème et d’outils, ainsi que les listes enregistrées et récemment utilisées, sont stockées uniquement dans ce navigateur.