Convertisseur SQL vers XML — Transformez INSERT et tables en XML

Collez le SQL à gauche et cliquez sur "Convertir" — on vous le transforme en XMLCollez le SQL

Ce que fait cet outil

Si vous avez déjà eu à vider un paquet de lignes de base dans un fichier XML pour un partenaire, un endpoint SOAP legacy ou un vieux job ETL qui attend encore du XML, vous connaissez la chanson — ouvrir un client SQL, lancer le SELECT, exporter, retoucher la sortie à la main, se battre avec les formats de date. Collez votre SQL ici et vous récupérez du XML bien formé d’un coup. Instructions INSERT multi-lignes, simples CREATE TABLE de schéma, ou un mélange des deux — même résultat.

Le convertisseur lit le SQL comme le ferait une base. Chaque ligne d’un INSERT multi-lignes devient un élément, et chaque colonne un élément enfant nommé d’après la colonne. Les valeurs NULL deviennent des éléments vides (comme ça la forme de chaque ligne reste identique). Les littéraux de type date — '2024-01-15 10:30:00', DATE '2024-01-15' ou timestamps bruts — sont émis en chaînes ISO-8601, pour que n’importe quel parser Java, .NET, Python ou autre les relise sans souci. Les numériques gardent leur précision ; les booléens sortent en true/false.

Les noms qualifiés par un schéma comme public.orders ou dbo.Orders sont réduits à orders ou Orders dans le nom d’élément, parce que les noms d’éléments XML ne peuvent pas contenir de points. Les identifiants entre guillemets, les backticks de MySQL et les noms entre doubles guillemets de PostgreSQL sont traités de la même façon. Collez un CREATE TABLE et vous obtenez un squelette XML pour ce schéma — un élément vide par colonne, pratique pour amorcer un XSD ou un payload d’exemple. Plusieurs tables dans la même requête ? Chacune apparaît dans la sortie comme sa propre section, dans l’ordre.

Comment l’utiliser

Trois étapes. Pareil que vous colliez une ligne ou un millier.

Collez votre SQL (ou essayez l’exemple)

Déposez le SQL tel quel dans l’éditeur de gauche. Instructions INSERT à une ligne ou à plusieurs, définitions CREATE TABLE, ou un mélange — tout passe. Cliquez sur Charger un exemple pour voir à quoi ressemble un vrai dump de commandes multi-tables.

Les commentaires (-- et /* ... */), les préfixes de schéma, les guillemets spécifiques au dialecte (backticks MySQL, doubles guillemets SQLite, crochets SQL Server) et les points-virgules en fin de ligne passent tous sans souci — pas besoin de faire le ménage.

Cliquez sur Convertir

Cliquez sur le bouton vert Convertir. L’outil parse le SQL, déplie chaque ligne d’un insert multi-lignes, normalise les dates et les booléens, et construit le XML en une passe. Un petit indicateur de chargement s’affiche pendant l’opération.

Copiez le XML

Le panneau de droite se remplit de XML indenté et bien formé, que n’importe quel parser XML conforme aux standards acceptera. Copiez-le direct dans un corps SOAP, une fixture de test, un dossier de drop ETL, ou là où vous en avez besoin.

Quand ça sert vraiment

Fixtures de seed pour la base

Vous avez un paquet d’<code>INSERT</code> issus d’un script de seed et il vous faut les mêmes données en XML pour un test d’intégration ou un mock server. Collez les inserts, récupérez le XML, fini — pas d’édition ligne par ligne.

SOAP et intégration legacy

Un vieux système partenaire attend un body XML qui reflète un ensemble de lignes de base. Sautez la couche intermédiaire qui stringifie les lignes une par une ; collez l’INSERT direct et copiez le XML dans votre requête SOAP.

Exports d’audit et de conformité

Les régulateurs et les auditeurs adorent encore le XML. Transformez les lignes que vous venez d’INSERT (ou celles sorties d’une requête sur les logs) en document XML signé et archivable sans monter un pipeline d’export.

Pipelines ETL à base de XML

Vous alimentez un ETL comme SSIS, Informatica ou un pipeline XSLT maison ? Convertissez l’échantillon SQL amont en XML pour prototyper la transformation avant que le vrai batch soit en place.

Questions fréquentes

Comment sont gérés les INSERT multi-lignes ?

Un INSERT INTO orders (...) VALUES (...), (...), (...); multi-lignes devient un élément conteneur pour la table, avec un enfant par ligne — chaque enfant prend la forme singulière du nom de la table (donc les lignes de orders deviennent des éléments <order> à l’intérieur d’un <orders>). Toutes les lignes ont les mêmes enfants de colonnes, dans le même ordre que la liste des colonnes, pour que la sortie reste prévisible même avec des centaines de lignes.

Qu’arrive-t-il aux valeurs NULL ?

Un NULL dans la liste de valeurs devient un élément vide (par exemple <middle_name/>) plutôt que d’être supprimé. Ça garde la forme de chaque ligne identique, ce qui compte pour les consommateurs qui parcourent les colonnes par position ou qui construisent un XSD à partir de l’échantillon. Si vous avez besoin de xsi:nil="true", enrobez la sortie d’un petit XSLT ou post-traitez — le convertisseur reste sur des éléments vides simples pour la portabilité.

Les dates et timestamps sont-ils en ISO-8601 ?

Oui. Les littéraux SQL comme '2024-01-15 10:30:00', DATE '2024-01-15', TIMESTAMP '2024-01-15 10:30:00+00' et le '2024-01-15T10:30:00' façon MySQL sortent tous en chaînes ISO-8601 (2024-01-15T10:30:00Z si un fuseau est présent, ou 2024-01-15T10:30:00 sinon). C’est le format que la stack XML de tous les langages majeurs parse sans broncher.

Je peux coller juste un CREATE TABLE — sans lignes ?

Oui. Un CREATE TABLE tout seul produit un squelette XML : un élément par colonne, vide, dans l’ordre de déclaration des colonnes. C’est un bon point de départ pour un payload d’exemple, un brouillon de XSD ou une fixture de test à remplir à la main. Les types du CREATE TABLE sont lus comme indices (les dates restent des dates, les numériques restent numériques) mais les éléments vides ne transportent pas d’info de type dans la sortie.

Et si ma requête contient plusieurs tables ?

Chaque instruction INSERT ou CREATE TABLE produit sa propre section de premier niveau dans la sortie, dans l’ordre où vous l’avez écrite. Un script mixte qui crée orders, insère trois commandes puis six order_items devient un document avec trois sections de table, chacune dans un conteneur. Le parser n’essaie pas de les joindre ou de les relier — il préserve juste la structure que vous avez collée.

Est-ce que les préfixes de schéma comme public.orders ou dbo.Orders sont supprimés ?

Oui. Les noms d’éléments XML ne peuvent pas contenir de points, donc public.orders devient <orders>, dbo.Orders devient <Orders> et my_schema."User Table" devient <User_Table> (les espaces deviennent des underscores parce que les noms XML ne peuvent pas contenir d’espaces non plus). Les backticks MySQL, les doubles guillemets PostgreSQL et les crochets SQL Server sont tous retirés de la même manière.

Autres outils qui peuvent servir

SQL vers XML n’est qu’une pièce du puzzle. Ces outils vont bien avec :