Formateur SQL
Indentez une requête SQL pour la relire, entièrement dans votre navigateur. Rien n'est exécuté et aucune base de données n'est contactée.
Fonctionne entièrement dans votre navigateur. Rien n'est envoyé, journalisé ni conservé.
Collez une requête arrivée sur une seule ligne interminable et relisez-la correctement. Le formatage a lieu dans votre navigateur : la requête, les noms de tables et la valeur qui traîne dans la clause WHERE ne quittent jamais votre machine.
Comment ça marche
La requête est découpée en éléments — chaînes, commentaires, noms entre guillemets, nombres, mots, opérateurs — puis réécrite avec des retours à la ligne et une indentation choisis à partir de cette suite. Les clauses commencent une ligne, les conditions s'alignent sous la clause à laquelle elles appartiennent, et une sous-requête est indentée dans ses parenthèses.
Chaque élément est réécrit exactement tel qu'il est arrivé. Seuls les espaces entre eux, et la casse des mots que l'outil reconnaît, peuvent changer — ce qui signifie que la requête qui sort est la requête qui est entrée. Cette propriété est vérifiée par les tests plutôt que laissée à l'inspection.
Une parenthèse qui contient une requête à part entière est éclatée sur plusieurs lignes ; un appel de fonction, une liste IN ou une parenthèse qui ne fait que grouper une expression restent sur une ligne, parce que les éclater rend la requête plus haute sans la rendre plus claire.
Exemples
| Cas | Saisie | Résultat |
|---|---|---|
| Une requête sur une ligne | select id, name from users where active = 1 order by name | SELECT id, name FROM users WHERE active = 1 ORDER BY name |
Questions fréquentes
Ma requête est-elle envoyée quelque part ?
Non. Le formateur est du JavaScript qui s'exécute dans cette page. Rien n'est téléversé, rien n'est journalisé et rien n'est stocké — vous pouvez couper votre connexion réseau, l'outil fonctionne toujours.
Vérifie-t-il que mon SQL est valide ?
Non, et il vaut mieux être clair là-dessus. Il réorganise les espaces. Il n'a ni schéma, ni grammaire de dialecte, ni base de données : il indentera donc volontiers une requête qu'aucun serveur n'accepterait. Les seules choses qu'il refuse sont une chaîne ou un commentaire qui ne se referment pas, parce qu'ils l'empêchent de distinguer le code du texte.
Quel dialecte comprend-il ?
Il reconnaît les styles de citation des dialectes courants — apostrophes pour les chaînes, guillemets, accents graves ou crochets pour les noms — et ne défigurera donc ni MySQL, ni PostgreSQL, ni SQLite, ni SQL Server. Il ne vérifie pas la grammaire du dialecte, parce qu'il n'analyse pas.
À quoi sert l'option antislash ?
MySQL traite un antislash dans une chaîne comme un échappement. La norme SQL — et PostgreSQL, SQLite, SQL Server et Oracle — ne le fait pas, et le même texte y est une chaîne suivie d'autre chose. Rien dans la requête ne permet de trancher, et deviner corromprait un dialecte ou l'autre : c'est donc un interrupteur. Laissez-le décoché sauf si vous travaillez sous MySQL.
Pourquoi la casse de ma colonne a-t-elle changé ?
Parce qu'elle s'écrit comme un mot-clé. L'option de casse touche les mots que l'outil reconnaît, et il ne peut pas distinguer une colonne nommée « key » du mot-clé. Les noms qui suivent immédiatement TABLE, INTO, FROM, JOIN ou UPDATE sont laissés tels quels, puisque ce sont les positions où la casse d'un nom peut réellement compter. Si vous préférez que rien ne bouge, réglez l'option des mots-clés sur « Laisser tel quel », ou mettez le nom entre guillemets.
Bon à savoir
- Rien sur cette page n'exécute de SQL ni ne se connecte à une base de données. La requête est du texte, et elle est traitée comme du texte.
- La mise en forme est déterministe : la même requête et les mêmes options produisent toujours la même sortie, et reformater une requête déjà formatée ne change rien.
- Les expressions CASE, les jointures, les sous-requêtes et les listes de colonnes d'un CREATE TABLE ont chacune une règle. Ce que les règles ne couvrent pas est laissé sur la ligne où il tombe plutôt que deviné.