poor mans t sql formatter npm cli

Poor Man's T-SQL Formatter - 节点命令行格式化程序

一个命令行 SQL 格式化程序，几乎可以在任何环境中运行（只要安装了 Node.js）。

它基于 Poor Man 的 T-SQL Formatter NPM 包 (poor-mans-t-sql-formatter)，而后者又基于同名的 C# 库 ( https://github.com/TaoK/PoorMansTSqlFormatter ）。

此格式化程序在功能上应与已存在几年的 C# 命令行格式化程序相同（可在 http://architectshack.com/PoorMansTSqlFormatter.ashx 下载），但有两个主要区别：

• 它非常容易安装，尤其是在 unixey 环境中 - 只要 Node.js 可用

• 它比基于 .Net 的格式化程序慢很多。

安装

（假设安装了node.js）

npm install --global poor-mans-t-sql-formatter-cli

用法

管道/标准输入输入和标准输出输出：

echo "select a from b join c on b.id = c.id where abc = 123 and def = N'whatêver' " | sqlformat

文件输入输出：

echo "with a as (select 1 as b) select * from a cros join c" > testfile.sql
sqlformat -f testfile.sql -g testfile.sql
cat testfile.sql

选项

如果 SQL 解析“遇到麻烦”，此命令行格式化程序将以非 0 退出代码退出 - 例如，如果它遇到未完成的“IF”语句，表明有关 SQL 的某些内容未正确理解/解析，并且因此可能“结果是错误的”。如果已知 SQL 是可疑的，或者已知解析混淆是无害的，则可以选择禁用此行为。

如果解析被中止，任何指定的“输出文件”将保持不变。

命令行实用程序特定选项：

选项	描述	类型	默认
--输入文件	从文件而不是标准输入（键入或管道输入）读取要格式化的输入	细绳
--输出文件	将格式化输出写入文件 - 类似于 stdout 的 shell 重定向，除非出现错误，否则文件不会受到影响	细绳
--忽略错误	即使解析失败也返回 0（成功）退出代码（因此格式化输出是可疑的）	布尔值
--输入编码	使用节点支持的特定字符编码进行输入 - 基本上是 utf-16le 或 utf-8	细绳	UTF-8
--输出编码	使用节点支持的特定字符编码进行输出 - 基本上是 utf-16le 或 utf-8	细绳	UTF-8
--强制输出BOM	在输出的开头添加字节顺序标记 (BOM)	布尔值

标准格式化程序选项：

（请注意，库中通常默认为“true”的布尔选项已被翻转为“no”前缀，遵循 unixey 命令行参数约定）

选项	描述	类型	默认
--缩进	缩进单位 - 通常是制表符 (t) 或多个空格	细绳	t
--最大线宽	请求格式化程序将长行换行以避免超过此行长度	整数	999
--每个选项卡的空间	这用于测量行长度，并且仅适用于使用制表符的情况	整数	4
--语句中断	开始新语句时应添加多少换行符？	整数	2
--clauseBreaks	在语句中开始新子句时应添加多少换行符？	整数	1
--no-expand逗号列表	逗号分隔的列表（列、按参数分组等）是否应该分成新行？	布尔值
--无尾随逗号	当因为逗号而开始新行时，逗号是否应该位于行尾（VS 下一行的开头）？	布尔值
--扩展逗号后的空格	逗号后面需要加空格吗？ （如果它们是“尾随”，通常不会）	布尔值
--no-expand布尔表达式	布尔运算符（AND、OR）是否会导致换行？	布尔值
--no-expandCase语句	CASE 表达式的 WHEN 和 THEN 表达式是否应该换行？	布尔值
--no-expandBetween条件	BETWEEN 表达式中的 max 参数是否应该换行？	布尔值
--expandInLists 列表中展开	IN() 列表是否应该将每个参数放在新行上？	布尔值
--breakJoinOnSections	JOIN 子句的 ON 部分是否应该分成自己的行？	布尔值
--无大写关键字	T-SQL 关键字（如 SELECT、FROM）是否应该自动大写？	布尔值
--关键词标准化	不常见的 T-SQL 关键字是否应该替换为标准关键字？ （注意：仅对 T-SQL 安全！）	布尔值

混淆格式化程序（“min”命令）选项：

选项	描述	类型	默认
--randomize关键字大小写	关键字的大小写是否应该随机化，以尽量减少易读性？	布尔值
--随机化线长度	SQL 是否应该以任意间隔换行，以最大程度地降低易读性？	布尔值
--no-preserve注释	代码中的注释是否应该保留（而不是被删除）？	布尔值
--启用关键字替换	带有同义词的关键字是否应该使用不太常见的形式？ （注意：仅对 T-SQL 安全！）	布尔值

特征

请注意，此命令行工具当前不生成 HTML（语法突出显示）输出。这将是一个相当简单的功能，底层库肯定支持它，但我还没有看到任何实际的用例。如果您有，请告诉我（和/或分叉，添加选项，让我知道）。

该格式化程序有效地“继承”了 Poor Man 的 T-SQL 格式化程序库的所有功能：

• 完全支持 MS SQL Server T-SQL，（据我所知）没有解析失败 ** 包括完整的过程/批处理代码支持、DDL、DML 等。

• 对其他 SQL 方言的合理支持（通常用于格式化 PL/SQL、PostgreSql、MySQL 等查询） ** 特定构造可能无法正常工作，或者可能无法正确/忠实地保留其他方言 - 请在发现此类问题时提出问题

• 合理数量的格式化配置选项，还有更多。

地位

正如 JS 库包文档（https://github.com/TaoK/poor-mans-t-sql-formatter-npm-package）中所述，该格式化程序目前相当慢。在我的笔记本电脑上，格式化单个查询大约需要半秒。这表明，对于批量格式化工作负载，提供通配符/递归文件输入/输出选项可能是有意义的。

编码支持也非常有限——当我们使用 Node 的内置编码支持时，它只能支持 utf-8 或 utf-16le。可能值得使用 iconv-lite 库来解决这个问题，但添加更多代码来加载也会有其缺点。值得思考的事情。

除了这些事情之外，我不知道有任何重大的突出问题（例如，与可在 http://architectshack.com/PoorMansTSqlFormatter.ashx 下载的同一命令行格式化程序的 C# / .Net 版本相比），因此任何输入/功能欢迎提出要求！