La conversion SQL (SQL Conversion) consiste à extraire les données d'un script SQL et à les réorganiser dans d'autres formats de données tels que JSON, CSV, XML, YAML, HTML ou Markdown. SQL (Structured Query Language, langage de requête structuré) est le langage de requête standard des bases de données relationnelles. Les outils d'export de base de données (mysqldump, pg_dump) produisent généralement les données sous forme d'instructions INSERT dans un script SQL. Ce format, bien pratique pour les imports en base, est malcommode pour la lecture par programme, l'analyse de données ou l'échange entre systèmes, d'où la nécessité de le convertir en formats plus universels.
Les scripts d'export de données SQL courants contiennent deux types d'instructions : CREATE TABLE sert à définir la structure de la table (noms de colonnes, types de données, contraintes), et INSERT INTO ... VALUES (...) insère les données proprement dites. Cet outil analyse ces deux types d'instructions : il extrait les définitions de colonnes et les informations de type de CREATE TABLE, et les lignes de données réelles de INSERT, puis réorganise la sortie dans le format choisi par l'utilisateur. L'ensemble du processus d'analyse s'effectue localement dans le navigateur, sans aucun service backend.
Pourquoi convertir le SQL en d'autres formats ? Le SQL, bien qu'universel, s'avère peu pratique dans les scénarios suivants : premièrement, un programme frontend lit beaucoup plus facilement du JSON que du SQL, sans avoir à intégrer un analyseur SQL ; deuxièmement, les tableurs comme Excel ou Google Sheets prennent nativement en charge le CSV, pas le SQL ; troisièmement, YAML et Markdown sont plus lisibles que le SQL dans les scénarios de configuration et de documentation ; quatrièmement, l'échange de données entre systèmes utilise souvent XML ou JSON comme format neutre. Une fois converti en ces formats universels, les données peuvent être consommées directement par davantage d'outils et de langages.
L'analyseur SQL de cet outil est écrit à la main et se concentre sur les instructions INSERT et CREATE TABLE. Pour les INSERT, il prend en charge les tuples à valeur unique (INSERT INTO t (a,b) VALUES (1,2)) et les tuples à valeurs multiples (INSERT INTO t (a,b) VALUES (1,2), (3,4), (5,6)), en mappant automatiquement les données aux noms de colonnes. Pour CREATE TABLE, il analyse les définitions de colonnes, les types de données (VARCHAR(255), INT, DECIMAL(10,2) etc., avec longueur entre parenthèses), ainsi que les contraintes et clauses NOT NULL, PRIMARY KEY, IF NOT EXISTS, en gérant correctement les parenthèses imbriquées pour éviter les splits erronés.
La reconnaissance des types est essentielle à la conversion SQL. L'outil détermine automatiquement le type à partir de la forme littérale de la valeur : les chaînes simples ou doubles guillemets sont des chaînes de caractères ; NULL (sans tenir compte de la casse) est la valeur nulle ; TRUE/FALSE sont des booléens ; 0x..., X'...', B'...' sont des littéraux hexadécimaux ; et les nombres purs (avec signe, séparateur décimal, notation scientifique) sont des nombres. Cette reconnaissance automatique garantit que les formats convertis (JSON, CSV, etc.) conservent la sémantique des données d'origine (par exemple le nombre 1 et non la chaîne "1"), afin que les programmes en aval traitent correctement les valeurs.
Les différences de styles de guillemets d'identifiants entre dialectes sont un piège fréquent de l'analyse SQL. MySQL utilise par défaut l'accent grave (`) pour entourer les identifiants (noms de tables, de colonnes), PostgreSQL les guillemets doubles ("), SQL Server/T-SQL les crochets ([]), et le SQL standard utilise également les guillemets doubles. La fonction unquoteIdentifier de cet outil reconnaît et supprime automatiquement ces guillemets, en traitant aussi les échappements internes (par exemple `` → `, "" → "). En mode reconstruction SQL, INSERT peut être régénéré dans le style de guillemets du dialecte cible.
L'échappement des chaînes SQL est un autre point technique majeur. La norme SQL prévoit que les simples guillemets à l'intérieur d'une chaîne sont échappés par dédoublement ('It''s' représente It's). MySQL prend en plus en charge l'échappement par antislash (\n, \t, \', \", \\, \0, \Z). L'analyseur de chaînes de cet outil gère les deux mécanismes et restitue correctement le contenu original. Lors de la conversion en CSV, les champs contenant virgule, guillemet ou saut de ligne sont rééchappés conformément à RFC 4180 ; lors de la conversion en XML/HTML, les caractères spéciaux &, <, >, ", ' sont échappés.
Le traitement purement frontend est un principe de conception fondamental de cet outil. Toutes les étapes d'analyse SQL et de conversion de données s'exécutent dans le moteur JavaScript du navigateur, sans aucune donnée envoyée à un serveur. Cela signifie que même si le script SQL contient des informations personnelles, des données commerciales sensibles ou la structure interne d'une base de données, rien ne fuite à l'extérieur. Cette approche convient particulièrement aux exports de bases de production, sans souci de conformité des données. Le traitement frontend élimine aussi la latence réseau ; la vitesse de conversion ne dépend que du processeur et de la mémoire de l'appareil.
Par rapport aux outils traditionnels de conversion SQL en ligne de commande (sql2csv, sqlparser), cet outil présente plusieurs avantages : aucune installation ni configuration d'environnement, utilisation directe depuis la page web ; interface visuelle avec aperçu en temps réel du résultat ; bascule en un clic entre plusieurs formats de sortie ; données d'exemple et documentation intégrées ; conception responsive mobile utilisable partout. En contrepartie, l'outil est centré sur l'extraction de données et ne traite pas les différences complexes entre dialectes (opérateurs JSONB de PostgreSQL, ON DUPLICATE KEY UPDATE de MySQL) ni les fonctionnalités avancées (procédures stockées, fonctions, déclencheurs). Pour ce type de besoins, utilisez des outils natifs de base de données ou des plateformes ETL spécialisées.
Lors de l'utilisation de l'outil de conversion SQL, quelques bonnes pratiques méritent d'être suivies : premièrement, vérifier avant conversion que le script SQL contient des données complètes (instructions INSERT) et non uniquement des requêtes (SELECT), car SELECT n'est pas analysé ; deuxièmement, pour les scripts SQL multi-tables, activer « Sortie séparée multi-tables » afin de conserver les informations de structure de table ; troisièmement, pour le SQL contenant des caractères chinois, activer « Inclure BOM » dans la sortie CSV pour qu'Excel reconnaisse l'encodage ; quatrièmement, pour les gros dumps SQL, désactiver « sortie mise en forme » afin de réduire le volume de sortie ; cinquièmement, pour une migration entre bases de données, utiliser le mode « Reconstruction SQL » pour changer de dialecte, sachant que les types complexes (tableaux PostgreSQL, JSONB) peuvent nécessiter des ajustements manuels.
