Testeur XPath

Qu'est-ce qu'un testeur XPath ?

XPath est le langage qui sert à désigner des parties d'un document XML : un chemin comme //a[@class='external'] sélectionne tous les liens portant cette classe, où qu'ils se trouvent dans l'arbre. C'est ce qu'emploient les bibliothèques de scraping, les feuilles XSLT, les outils d'automatisation de navigateur et bon nombre de formats de configuration lorsqu'ils doivent désigner un élément.

Un testeur XPath vous laisse écrire une expression, l'exécuter sur un document que vous fournissez et voir ce qu'elle renvoie avant de la porter dans du code. C'est utile parce que XPath échoue silencieusement dans les deux sens : une expression qui ne sélectionne rien ressemble beaucoup à une expression fausse, et une expression en erreur vous parle de syntaxe alors que le vrai problème est que la fonction employée n'existe pas.

Celui-ci exécute l'expression dans le moteur XPath de votre propre navigateur, celui-là même qu'utiliseraient les scripts de votre page. Il lit aussi l'expression et vous indique quelles fonctions et quels axes y sont réellement disponibles — la partie que la plupart des testeurs vous laissent découvrir à la dure.

Comment l'utiliser

1. Écrivez votre expression. Du chemin le plus simple à celui truffé de prédicats. L'analyse en dessous se met à jour à mesure que vous tapez, avant même l'exécution.
2. Collez le XML à parcourir. Un fragment du document réel est l'idéal. Il est analysé comme du XML, il doit donc être bien formé : une balise non fermée est signalée comme erreur d'analyse plutôt qu'ignorée en silence.
3. Lisez les deux panneaux. Les résultats sont ce qu'a renvoyé le moteur de votre navigateur. En dessous, chaque fonction et chaque axe de votre expression apparaissent comme disponibles ou non, avec le remplacement XPath 1.0 lorsqu'il en existe un.

Les navigateurs ne parlent que XPath 1.0

Le XPath intégré à tout navigateur est celui de 1999, et rien de postérieur. Cette spécification définit une bibliothèque de base de vingt-sept fonctions exactement et de treize axes exactement : voilà tout le langage du point de vue d'un navigateur. XPath 2.0 et 3.1 ont beaucoup ajouté, et rien de tout cela n'est disponible ici ; cela vit dans les processeurs XSLT 2.0 et dans les bibliothèques qui embarquent leur propre moteur.

Le manque n'a pas la forme nette qu'on attendrait. starts-with() figure parmi les vingt-sept. contains() aussi. ends-with() non — elle est arrivée avec XPath 2.0 — ce qui signifie que la façon la plus naturelle de sélectionner des liens vers des fichiers PDF est précisément celle qui ne peut pas s'exécuter, et l'erreur que renvoie le navigateur parle de l'expression et non de la version. Cette asymétrie piège constamment, et c'est la raison d'être de cette page plutôt qu'une énième boîte qui exécute des requêtes.

Et il en va de même partout. Aucune prise en charge des expressions régulières : matches(), replace() et tokenize() sont des ajouts ultérieurs, et vous ne pouvez pas les reconstruire avec ce qui reste. Pas de lower-case() ni de upper-case(). Pas de min(), max(), avg() ni abs(). Ce ne sont pas des recoins obscurs : ce sont les fonctions vers lesquelles on se tourne en premier.

Certaines ont d'honnêtes remplaçantes en XPath 1.0 et d'autres non, et savoir lesquelles vous épargne un après-midi. ends-with() se réécrit exactement, avec substring() et string-length(), en se rappelant que XPath compte les caractères à partir de un et non de zéro. Le changement de casse s'approche avec translate() si vous détaillez les deux alphabets, ce qui couvre l'ASCII et rien d'autre. Les expressions régulières n'ont aucun équivalent et doivent quitter la requête pour le code qui l'entoure.

Limites assumées

Votre document est analysé comme du XML, pas comme du HTML. C'est le plus strict des deux, et c'est délibéré : XPath est défini sur un arbre XML, et analyser avec souplesse vous laisserait écrire ici des expressions qui se comportent autrement face à un vrai document. En pratique, un fragment de HTML réel comportant une balise non fermée sera rejeté, et il faudra le corriger d'abord.

Les espaces de noms sont l'arête la plus vive de XPath et cette page ne l'adoucit pas. Si votre document déclare un espace de noms par défaut, un simple //title ne sélectionnera rien du tout, car en XPath 1.0 un nom sans préfixe signifie aucun espace de noms et non l'espace par défaut. Le langage lui-même n'offre aucun contournement : il faut soit un résolveur d'espaces de noms, qui est une fonction et ne peut donc pas se taper dans un champ de texte, soit le détour par local-name().

La vérification que cette page effectue sur votre expression la lit au lieu de l'exécuter : elle identifie donc les fonctions et les axes par leur nom. Une expression peut passer cette vérification et rester fausse pour des raisons qu'aucune analyse ne détecte — un argument du mauvais type, ou un prédicat qui ne dit pas ce que vous croyiez. Le panneau de résultats est la réponse ; l'analyse sert à expliquer un échec que le navigateur décrit mal.

Une chose est délibérément mesurée plutôt que supposée : l'axe namespace fait partie de XPath 1.0 et reste pourtant l'élément sur lequel les navigateurs ont divergé. Plutôt que de vous dire ce que fait le vôtre, la page effectue la vérification dans votre navigateur et rapporte ce qu'elle constate — d'où le fait que cette ligne puisse différer de celle d'un collègue.

Pourquoi est-ce gratuit ?

Le moteur est celui que votre navigateur possède déjà : il n'y a donc rien à faire tourner ni rien à facturer. Évaluer une expression XPath ne coûte pas plus que n'importe quel autre bout de script de la page.

Rien de ce que vous collez n'est envoyé, conservé ni journalisé. Le XML que vous déboguez est le plus souvent un fragment de données réelles appartenant à quelqu'un, et la façon fiable de garder cela privé est de ne jamais le recevoir.