Analyse

Un analyseur (parser) est le composant qui lit du texte en entrée et en construit une représentation structurée avec laquelle un programme peut réellement travailler. Le texte brut n'est qu'une séquence de caractères sans signification intrinsèque pour le logiciel ; l'analyseur est l'étape qui transforme ce flux plat en quelque chose doté de forme et de hiérarchie. Il se situe à la frontière entre le texte écrit par un humain ou généré par une machine et les données structurées dont le reste d'un programme a besoin.

Deux étapes : tokeniser, puis construire un arbre

La plupart des analyseurs fonctionnent en deux étapes distinctes. La première étape, un tokeniseur ou lexeur, regroupe les caractères en unités significatives — balises, mots, nombres, opérateurs, symboles — de sorte que l'entrée n'est plus des caractères individuels mais une séquence de jetons. La seconde étape, la construction de l'arbre, agence ces jetons en une hiérarchie selon une grammaire, produisant un arbre structuré. Séparer ces deux tâches garde chacune plus simple, et c'est un schéma que vous reverrez encore et encore.

La tokenisation à elle seule résout beaucoup d'ambiguïté. Considérez comment les caractères qui forment une balise ouvrante, un nom d'attribut et une valeur entre guillemets doivent être reconnus comme des choses distinctes avant qu'aucune structure ne puisse être construite ; le tokeniseur est ce qui établit ces distinctions. Ce n'est qu'une fois que l'entrée est un flux propre de jetons que l'étape de construction de l'arbre peut raisonner sur la façon dont ils s'imbriquent et se relient les uns aux autres.

Les parseurs sont partout

Les analyseurs sont véritablement partout dès qu'on commence à regarder. Les compilateurs analysent le code source en un arbre syntaxique abstrait avant de générer des instructions machine ; les navigateurs analysent le HTML et le CSS pour construire les structures qu'ils rendent ; et les applications ordinaires analysent du JSON, du XML, du YAML et des fichiers de configuration à chaque démarrage. Presque tout programme qui accepte du texte en entrée a un analyseur quelque part en son sein, même si l'auteur ne le pense jamais sous ce nom.

Pourquoi le résultat est un arbre

La sortie d'un analyseur est généralement un arbre, et le type d'arbre dépend du domaine. Pour un langage de programmation, c'est un arbre syntaxique abstrait qui capture la structure des expressions et des instructions ; pour une page web, c'est le DOM, l'arbre d'éléments et de nœuds de texte que le navigateur construit à partir du HTML. Dans les deux cas, c'est l'arbre, et non le texte d'origine, sur lequel opèrent les étapes suivantes.

La raison pour laquelle un arbre est la sortie naturelle, c'est que la plupart des langages et des formats de documents sont intrinsèquement imbriqués. Une expression contient des sous-expressions, un élément contient des éléments enfants, un bloc de configuration contient des blocs imbriqués. Une liste plate de jetons ne peut pas capturer cette imbrication, mais un arbre l'exprime directement, ce qui explique pourquoi l'analyse est si souvent décrite comme la transformation d'un flux unidimensionnel en une structure à plusieurs niveaux.

Ce qui rend le parsing HTML si particulier

Ce qui rend l'analyse du HTML inhabituelle parmi tous ces exemples, c'est sa récupération d'erreurs standardisée. Le balisage du monde réel est plein d'erreurs — balises non fermées, éléments mal placés, attributs en positions étranges — et pourtant les pages doivent tout de même s'afficher. La spécification HTML répond à cela en définissant exactement comment un analyseur doit traiter chaque type d'entrée malformée, plutôt que de laisser chaque implémentation deviner.

La conséquence de cette spécification précise est une interopérabilité remarquable. Parce que les règles de récupération d'erreurs sont détaillées dans le menu, chaque navigateur moderne construit le même arbre DOM à partir de la même entrée cassée, au lieu que chacun improvise différemment. C'est pourquoi une page malformée s'affiche de manière cohérente entre navigateurs, et cela contraste avec des formats plus stricts comme XML, qui rejettent simplement une entrée non bien formée plutôt que d'essayer de la réparer.

Tolérant ou strict, par conception

Ce contraste met en lumière un compromis de conception délibéré. Un analyseur indulgent comme celui du HTML privilégie la résilience et le fait que l'utilisateur voie toujours quelque chose, au prix de laisser passer silencieusement les erreurs. Un analyseur strict comme celui du XML privilégie la correction et la prévisibilité, au prix de rejeter d'emblée une entrée imparfaite. Aucun n'est universellement meilleur ; chacun convient à la tâche pour laquelle il a été conçu, et reconnaître quelle philosophie suit un format vous en dit long sur son comportement.

Un modèle mental pour toute la stack

Dès que l'on commence à voir le logiciel comme une série d'analyseurs transformant du texte en structure, une grande partie de la pile web devient plus facile à raisonner. Le navigateur analysant le HTML en DOM, le moteur analysant le JavaScript en arbre syntaxique, le serveur analysant un corps de requête JSON — ce sont toutes la même idée appliquée à différents endroits. Ce prisme unique, du texte devenant des données structurées via un analyseur, est l'un des modèles mentaux les plus utiles de toute la programmation.