STL ASCII ou binaire : quel format utiliser ?

Résumé

STL ASCII ou binaire est une comparaison entre deux encodages du même format de maillage triangulaire STL, et non entre deux systèmes de modélisation différents. STL possède deux sous-types, ASCII et binaire, qui utilisent tous deux couramment la même extension .stl. [1] [4]

Pour la plupart des flux de travail d’impression 3D, le STL binaire est le choix pratique par défaut, car les logiciels modernes l’utilisent couramment et qu’il est plus compact. Le STL ASCII reste utile lorsque vous souhaitez inspecter directement un fichier, résoudre des problèmes d’exportation ou enseigner la structure du format. Si les triangles et les coordonnées sont identiques, l’encodage ne modifie pas la qualité d’impression ; les variables les plus importantes sont la tessellation, la validité du maillage, la gestion de l’échelle, le tranchage et la combinaison imprimante-procédé-matériau. Aucun des deux encodages n’ajoute d’unités, d’assemblages, de matériaux ou de métadonnées fiables. [1] [2] [3] [5]

Réponse rapide : quel format STL utiliser pour l’impression 3D ?

Utilisez le STL binaire pour les flux de travail habituels avec un slicer. C’est l’encodage le plus compact dans la pratique moderne, il est plus couramment employé par les logiciels actuels et aucune extension de fichier distincte n’indique quel encodage utilise un fichier .stl. Le STL ASCII reste valide, mais il constitue aujourd’hui surtout un choix spécialisé ou destiné au débogage, plutôt que l’exportation par défaut pour l’impression au quotidien. [1] [4]

Le STL ASCII a été historiquement décrit comme étant principalement destiné aux tests, ce qui aide à comprendre pourquoi sa lisibilité s’accompagne de fichiers plus volumineux. À titre d’exemple de compatibilité plutôt que de règle universelle, la documentation de Prusa indique que ses logiciels prennent en charge les STL binaires et ASCII et préfèrent le 3MF pour les fichiers de projet. [3] [17]

• Choisissez le STL binaire pour le tranchage courant, les maillages plus volumineux, les téléversements et le partage de fichiers. [1] [4]
• Choisissez le STL ASCII pour le débogage, l’enseignement, de très petits fichiers de test, les flux de travail de diff textuel ou les cas particuliers hérités. [3]

Les encodages STL en une minute

STL a été documenté par 3D Systems en 1988, avec une seconde édition publiée en 1989. Les deux encodages décrivent le même modèle sous-jacent : une surface approximée par des facettes triangulaires. Chaque facette stocke un vecteur normal et trois sommets, soit un total de 12 valeurs numériques par facette. La validité d’un STL dépend aussi de règles d’orientation : la normale doit pointer vers l’extérieur, et les sommets doivent être ordonnés dans le sens antihoraire lorsqu’ils sont observés de l’extérieur, conformément à la règle de la main droite. [1] [5]

Ce qui change entre les encodages est la représentation, et non la géométrie. L’encodage STL ASCII écrit le maillage sous forme d’enregistrements textuels ligne par ligne, tels que solid, facet, outer loop, vertex, endloop, endfacet et endsolid. L’encodage STL binaire stocke les mêmes données de facette dans des enregistrements de longueur fixe après un en-tête court et un nombre de triangles. Cela affecte la lisibilité, la prévisibilité de la taille de fichier et certains comportements d’analyseurs, mais pas le concept même du maillage. [2] [3]

La règle de taille binaire indiquée dans le tableau découle de la structure du fichier : 80 octets pour l’en-tête, 4 octets pour le nombre de triangles et 50 octets par facette. Dans les deux encodages, le STL ne dispose toujours pas d’unités fiables, de métadonnées sûres, ni d’une prise en charge standard de la couleur ou des textures. [2] [5]

Comment déterminer si un STL est ASCII ou binaire (et pourquoi solid ne suffit pas)

N’identifiez pas un STL uniquement en vérifiant si le fichier commence par solid. L’enregistrement IANA ne fait aucune distinction d’extension de fichier entre les deux variantes, et de véritables fichiers STL binaires peuvent commencer par un texte d’en-tête débutant par solid, ce qui met en échec une détection simpliste. L’étape initiale la plus sûre consiste à ouvrir le fichier dans une visionneuse ou un analyseur fiable qui gère déjà les deux variantes. [4] [10] [11]

Une liste de vérification pratique est la suivante :

1. Si le fichier est intégralement lisible sous forme de texte et que vous voyez les mots-clés STL attendus dans l’ordre, il est probablement en ASCII. [3]
2. Si vous le traitez comme un fichier binaire, lisez le nombre de triangles à l’offset d’octet 80 comme un entier 32 bits little-endian et vérifiez si la taille totale du fichier correspond à 84 + 50 × N octets. Utilisez cela comme heuristique de validation, et non comme signature formelle. [2] [10]
3. Si le résultat est ambigu, revenez à un analyseur fiable plutôt que de déduire le format à partir de l’en-tête. [10] [11]

Cette heuristique est utile parce que le STL binaire ne possède pas de nombre magique. Un exemple de spécification formalisée de 2019 utilise à la fois une vérification de cohérence de l’en-tête et l’équation de taille attendue, tandis qu’au moins un lecteur mature précise que le little-endian est la norme de facto tout en essayant de détecter l’ordre des octets dans les cas ambigus. Ensemble, la sortie de l’analyseur, la validation de taille et les contrôles de cohérence de base sont plus sûrs que toute règle unique portant sur l’en-tête. [10] [12]

Anatomie d’un fichier STL binaire

L’encodage STL binaire est suffisamment simple pour être décrit au niveau des octets. [2]

Un fichier STL binaire commence par un en-tête de 80 octets, suivi d’un nombre de triangles sur 4 octets, puis d’un enregistrement de 50 octets pour chaque triangle. L’en-tête peut contenir du texte, mais ce n’est pas une métadonnée standardisée ; il ne doit donc pas être considéré comme fiable pour les unités, l’auteur ou toute autre information de projet. [2]

Chaque enregistrement de triangle contient 12 valeurs float32 little-endian, soit 48 octets au total : 3 valeurs pour la normale de la facette et 9 valeurs pour les coordonnées des trois sommets. Ces 48 octets sont suivis d’un entier non signé de 2 octets, généralement appelé nombre d’octets d’attribut. Les recommandations historiques considèrent couramment ce champ comme nul, et le format n’y a jamais établi de mécanisme d’attribut général fiable. [2] [5]

D’après cette structure, la taille totale d’un STL binaire valide se déduit comme 84 + 50 × N octets. Le 84 provient de l’en-tête de 80 octets plus le nombre sur 4 octets ; le 50 provient de 48 octets de données de facette float32 plus le champ d’attribut de 2 octets. La documentation de la Library of Congress décrit les champs comme little-endian, et MOAB note que le little-endian est la norme de facto, bien que certains lecteurs recherchent encore l’ordre des octets. Les extensions de couleur binaires restent également ambiguës plutôt que standardisées. [2] [12]

Anatomie d’un fichier STL ASCII

L’encodage STL ASCII utilise des mots-clés et des enregistrements ligne par ligne plutôt que des blocs d’octets fixes. Un fichier commence par solid et se termine par endsolid ; dans cette enveloppe externe, chaque facette va de facet à endfacet. Une facette peut inclure une normale de longueur unitaire après normal, et ses trois sommets apparaissent entre outer loop et endloop sous forme de triplets de coordonnées (X, Y, Z). [3]

Une courte séquence d’enregistrements ressemble à ceci :

• solid name
• facet normal ...
• outer loop
• vertex ...
• vertex ...
• vertex ...
• endloop
• endfacet
• endsolid name

Comme le STL ASCII est du texte, sa taille de fichier varie selon les espaces, les fins de ligne, les noms facultatifs et le nombre de chiffres que l’exportateur écrit pour chaque nombre. C’est pourquoi il n’existe pas de ratio universel utile entre tailles ASCII et binaire. L’encodage STL ASCII a aussi été historiquement décrit comme principalement destiné aux tests, ce qui aide à expliquer pourquoi son principal avantage actuel est la transparence plutôt que la compacité. [3]

Compromis entre performances et représentation

Le STL binaire est généralement plus petit, car il stocke chaque triangle dans un enregistrement fixe de 50 octets au lieu d’écrire la même structure avec des mots-clés textuels répétés et des chaînes décimales. Pour les fichiers binaires valides, la taille est déterministe dès lors que le nombre de triangles est connu. Le STL ASCII n’a pas de règle de taille fixe équivalente, car son coût de stockage change selon les choix de formatage textuel. C’est pourquoi le binaire est devenu le choix par défaut dans la pratique moderne, sans pour autant constituer un modèle de maillage différent ou « meilleur ». [1] [2] [3]

La vitesse d’analyse dépend davantage du contexte. De nombreuses implémentations peuvent parcourir efficacement les données binaires, car la longueur des enregistrements est fixe, tandis que les lecteurs ASCII doivent découper le texte en jetons et analyser les nombres à partir de chaînes. Néanmoins, les détails d’implémentation, les systèmes d’exploitation, la taille des fichiers et la conception des bibliothèques influent tous sur les résultats ; aucun chiffre universel fiable n’a donc été trouvé. La vitesse est ainsi une considération secondaire raisonnable, mais pas une valeur à généraliser sans benchmark contrôlé. [2] [3]

La précision est facile à surestimer. L’encodage STL binaire stocke les valeurs de facette en float32, tandis que l’encodage STL ASCII stocke des représentations textuelles de nombres. Cela ne signifie pas que l’ASCII offre automatiquement une « qualité supérieure », ni que le binaire dégrade à lui seul la qualité d’impression. Si les mêmes triangles atteignent le slicer, le résultat d’impression dépend de la qualité de la tessellation, de la validité du maillage, de l’interprétation de l’échelle, des paramètres de tranchage et du contexte imprimante-procédé-matériau. [2] [5] [8]

Flux de travail de la CAO au slicer

Le STL se situe généralement au milieu de la chaîne d’outils, et non à sa fin. L’IANA décrit la séquence habituelle ainsi : en 3D, des données de modèle sont créées par un logiciel de modélisation, puis envoyées à un logiciel de préparation pour l’impression 3D, qui produit des instructions spécifiques à la machine et au matériau. En ce sens, le STL est un maillage d’échange plutôt qu’un package de fabrication complet. [4]

Un flux de travail pratique est le suivant :

1. Modélisez la pièce dans un logiciel de CAO ou de maillage.
2. Exportez le STL et choisissez délibérément les paramètres de tessellation, car la densité de triangles contrôle l’approximation des surfaces courbes.
3. Préférez le binaire, sauf si vous avez spécifiquement besoin de l’encodage STL ASCII pour l’inspection ou le débogage.
4. Importez le fichier dans le slicer et vérifiez l’échelle, le caractère manifold et les défauts évidents.
5. Tranchez en instructions machine telles que le G-code ou une autre sortie spécifique à l’imprimante. [4]

À titre d’exemple de compatibilité plutôt que de règle universelle, Prusa documente la prise en charge des deux encodages STL et préfère le 3MF pour les fichiers de projet. [17]

Limites et cas particuliers

Les limites les plus importantes du STL s’appliquent aux deux encodages. Le STL ne contient pas d’informations d’échelle fiables ; les coordonnées sont donc de simples unités arbitraires jusqu’à ce qu’un autre outil leur attribue une signification. C’est pourquoi un même maillage peut être importé à une mauvaise taille lorsque l’exportateur et l’importateur supposent des unités différentes. Le STL ne fournit pas non plus de métadonnées descriptives fiables ; même l’en-tête binaire n’est qu’un champ de commentaire, et non un bloc de métadonnées standardisé. [2] [5]

La topologie est une autre limite essentielle. Le NIST indique que le STL stocke une collection de facettes sans informations de connectivité ; le logiciel peut donc devoir reconstruire les adjacences avant que des tâches telles que le tranchage puissent se poursuivre efficacement. En pratique, la santé du maillage importe généralement davantage que le choix entre ASCII et binaire. Si le modèle présente des trous, des facettes manquantes ou des adjacences rompues, l’encodage seul ne sauvera pas le travail. [8]

Les modes de défaillance courants comprennent des normales incohérentes ou inversées, des facettes dégénérées et des trous dus à des surfaces ou facettes manquantes. Le NIST distingue la dégénérescence topologique, où les sommets coïncident, de la dégénérescence géométrique, où les sommets sont distincts mais colinéaires. La couleur et la texture sont aussi problématiques : la spécification STL documentée ne les prend pas en charge de manière standard, et les conventions de couleur binaire utilisées sont incompatibles entre elles. Pour l’impression quotidienne, ces problèmes sont plus susceptibles de causer des difficultés que le choix entre ASCII et binaire lui-même. [2] [8]

Lorsque les limites du STL comptent : alternatives rapides

Les formats alternatifs importent surtout lorsque les omissions du STL deviennent un problème réel. Si vous avez besoin d’unités explicites, de métadonnées plus riches, d’informations d’apparence ou d’une sémantique de modèle plus étendue, c’est à ce moment qu’un autre format commence à avoir du sens. La spécification 3MF Core attribue à <model> un attribut unit dont la valeur par défaut est le millimètre et dont les valeurs autorisées comprennent micron, millimeter, centimeter, inch, foot et meter. [14]

Il ne s’agit pas d’affirmer que 3MF, STEP ou AMF remplacent universellement le STL. Il s’agit d’un point plus restreint sur les capacités. Le 3MF est désormais publié sous la norme ISO/IEC 25422:2025, avec l’édition 1 publiée en juin 2025, et le résumé de la norme AMF présente explicitement le STL comme un format limité aux maillages de surface, sans dispositions pour la couleur, la texture, le matériau, la sous-structure et les propriétés associées. [15] [16]

Note de niche : flux de travail médicaux

Une exception spécialisée concerne l’échange de données médicales. Le supplément 205 de DICOM encapsule des modèles STL pour la fabrication 3D, mais le document encapsulé est un flux d’octets STL binaire ; le STL ASCII n’est pas pris en charge dans cette voie. Il s’agit d’un choix de norme de niche, et non d’une raison d’exporter différemment en binaire pour le travail ordinaire de loisir ou de la CAO au slicer. [13]

Conclusion : quel format STL utiliser pour l’impression 3D ?

Pour la plupart des utilisateurs, STL ASCII ou binaire est un choix de représentation, et non un choix géométrique. Si vous vous demandez quel format STL utiliser pour l’impression 3D, la réponse courte est le binaire par défaut, l’ASCII étant réservé à la lisibilité, au débogage ou aux flux de travail texte hérités. Si vous avez besoin d’unités, de métadonnées, d’apparence ou d’une sémantique de modèle plus riche, la meilleure solution consiste généralement à choisir 3MF, STEP ou AMF plutôt qu’à basculer entre les encodages STL. [1] [2] [5]

FAQ

Quelle est la différence entre les encodages STL ASCII et binaire ?

Ce sont deux encodages du même modèle de maillage STL. L’encodage STL ASCII écrit les facettes sous forme d’enregistrements textuels lisibles par l’humain, tandis que l’encodage STL binaire stocke le même type de données de facette dans des enregistrements binaires de taille fixe. La différence est opérationnelle — lisibilité, comportement de la taille de fichier et traitement par les analyseurs — et ne constitue pas une modification du concept géométrique. [1] [2] [3]

Le STL binaire est-il plus petit que le STL ASCII, et pourquoi ?

Généralement, oui. Un STL binaire valide utilise un enregistrement fixe de 50 octets par triangle, plus un en-tête de 80 octets et un nombre de triangles de 4 octets ; sa taille est donc prévisible. Le STL ASCII doit stocker des mots-clés, des espaces, des retours à la ligne et des chaînes décimales ; sa taille change donc selon le formatage. C’est pourquoi le binaire est généralement plus compact, mais aucun ratio universel ne s’applique à tous les fichiers. [1] [2] [3]

Quel format STL utiliser pour l’impression 3D ?

Pour les flux de travail habituels avec un slicer, utilisez le binaire, sauf raison précise de ne pas le faire. C’est le choix courant moderne car il est plus compact et largement pris en charge. L’encodage STL ASCII est surtout utile lorsque vous souhaitez inspecter directement le fichier, le comparer sous forme de texte ou résoudre un problème d’exportation. Certains slicers prennent explicitement en charge les deux, mais cela doit être considéré comme une confirmation propre à un produit, et non comme une règle universelle. [1] [3] [17]

STL ASCII ou binaire affecte-t-il la qualité d’impression ?

Pas en soi. Si le slicer reçoit les mêmes triangles et coordonnées, changer uniquement l’encodage n’améliore ni la fidélité des surfaces ni la précision de l’imprimante. Les résultats d’impression dépendent bien davantage de la tessellation, de l’état de réparation du maillage, de l’interprétation des unités, des paramètres de tranchage et de la combinaison imprimante-procédé-matériau. Le choix d’encodage est généralement une décision de flux de travail, et non un contrôle de la qualité d’impression. [2] [5] [8]

Comment déterminer de manière fiable si un STL est ASCII ou binaire ?

Ne vous fiez pas à solid seul. De véritables fichiers STL binaires commencent parfois par ce texte dans l’en-tête ; l’identification par en-tête peut donc échouer. Utilisez d’abord un analyseur ou une visionneuse fiable. Si vous devez réaliser un contrôle manuel de cohérence, traitez le fichier comme binaire, lisez le nombre de triangles little-endian à l’offset d’octet 80 et vérifiez si la taille totale correspond à 84 + 50 × N octets. Il s’agit d’une heuristique, pas d’une signature formelle. [2] [10] [11]

Expert : qu’est-ce qui est exactement stocké par triangle dans un STL binaire ?

Chaque enregistrement de triangle fait 50 octets. Les premiers 48 octets correspondent à 12 valeurs float32 little-endian : 3 pour la normale de facette et 9 pour les coordonnées des trois sommets. Les 2 derniers octets constituent un champ d’entier non signé appelé nombre d’octets d’attribut. Répétés N fois après l’en-tête et le nombre de triangles, ces enregistrements définissent le maillage. [2]

Expert : qu’est-ce que le nombre d’octets d’attribut, et pourquoi la couleur est-elle peu fiable en STL binaire ?

Le nombre d’octets d’attribut correspond aux 2 derniers octets de chaque enregistrement de triangle binaire. Les recommandations historiques le fixent couramment à zéro, et la documentation d’origine n’a pas établi de mécanisme d’attribut général interopérable. Certains logiciels ont ensuite utilisé des extensions de STL binaire pour la couleur, mais leurs conventions sont contradictoires ; un logiciel ne peut donc pas savoir automatiquement quelle interprétation privilégier à partir du seul fichier. [2] [5]

Sources

1. Library of Congress — Famille de formats de fichiers STL (STereoLithography)
2. Library of Congress — Format de fichier STL (STereoLithography), binaire
3. Library of Congress — Format de fichier STL (STereoLithography), ASCII
4. IANA — Type de média model/stl
5. Fabbers — Le format StL
6. NISTIR 6216 — Évaluation des exigences de données et des formats de transfert de données pour la fabrication par couches
7. Article CEUR-WS Vol-2406 — Sur l’utilisation de spécifications de formats de fichiers binaires…
8. Problème meshio — Impossible de lire un fichier STL binaire avec un en-tête commençant par solid
9. Documentation MOAB — Référence de classe moab::ReadSTL
10. DICOM / NEMA — Supplément 205 : encapsulation de modèles STL pour la fabrication 3D
11. 3MF Consortium — Spécification 3MF Core
12. ISO — ISO/IEC 25422:2025 (suite de spécifications 3MF)
13. ISO — Résumé ISO/ASTM 52915:2013
14. Base de connaissances Prusa — Formats de fichiers pris en charge