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 版本相比），因此任何輸入/功能歡迎提出要求！