关于格式化 SQL

SQL 往往以一整行巨大的文本出现。来自 ORM 的日志，来自一份缺陷报告，来自某人的剪贴板。它跑得好好的，却完全没法读，而你要找的那一小段，就藏在中间某处。

粘贴进来，它就排好版回来了 — 每个子句一行，列在 SELECT 下缩进，JOIN 和它的 ON 条件对齐排列，让查询的结构一眼可见。

使用方法

没有需要按下的「格式化」按钮。真正会改变结果的只有格式化和压成一行两个按钮，

它们决定你看到的是哪一种。

输出的着色，是把排版时用的同一个分词器再跑一遍成品文本得到的 — 关键字青色，字符串

黄色，数字橙色，注释灰色，标点粉色，而你自己的表名和列名保持原色，好让它们从周围的

SQL 中凸显出来。

这不只是好看的问题。因为对查询的同一次解析同时产生了排版和配色，两者绝不可能互相矛盾：

被涂成字符串的部分，正是格式化器当作字符串处理的部分。如果哪里的引号没有配对，颜色就会

一路蔓延，把位置指给你看 — 这通常比用眼睛找快得多。

复制和下载交出的是纯文本，绝不是带颜色的标记。

多数快速的 SQL 格式化工具靠正则表达式工作，而这两点正是那种做法崩掉的地方。

绝不窥探字符串和注释内部。 一条包含 WHERE note = 'from a, b' 的查询，字符串字面量里就有关键字、逗号和空格。基于正则的格式化会在那里断行，从而改变查询的含义。这个工具先把查询读成词元，所以字面量的内容会原封不动地出来 — 连空格都一样
标识符保持你写的大小写。 只有关键字会被转成大写或小写。在区分大小写的服务器上，userId 和 userid 是两个不同的列，而一个把它们「整理」掉的格式化工具，是为了好看而弄坏了查询

各种引用写法都能理解：用 '' 转义的 '字符串'、"带引号的标识符"、MySQL 的反引号、SQL Server 的 [方括号]，以及 PostgreSQL 的 $$ 美元引用 $$。

压缩会把查询收回成单独一行。只有在去掉空格会改变含义或产生新词元的地方才保留空格，所以结果在安全范围内已经尽可能短。

行注释会被丢弃，因为一旦全部挤到一行，-- 像这样的注释就会吞掉后面的一切。块注释则原样保留。