SQL Server / T-SQL 是否支持行繼續來分解長字元串?
我有時有一個 SQL 腳本,其中包含一個或多個超長(有時甚至是愚蠢的長)字元串。通常這些是
VARBINARY
代表文件/程序集的文字/常量,但有時它們是文本。真正長字元串的主要問題是一些文本編輯器不能很好地處理它們。例如,我有一個
VARBINARY
在語句中使用的文字CREATE ASSEMBLY [AssemblyName] FROM 0x....
,而程序集本身的大小剛剛超過 1 MB,這相當於文本文件中超過 200 萬個字元,因為每個字節需要兩個字元以十六進製表示法表示(例如0x1F
= a1
和 anF
)。SQL Server Management Studio (SSMS) 不能很好地處理這個問題,並在我嘗試滾動該行時掛起幾秒鐘。事實上,某些版本(不確定是否仍然會發生這種情況)甚至會在打開至少有一行超過一定長度的腳本時顯示關於長行的警告。第二個問題是,當在沒有啟用自動換行的編輯器中使用或線上發佈時,它會使格式複雜化。這裡的問題是水平捲動條的滑塊非常窄,即使移動它一點點通常也會將非超長文本滾動到視野之外。
現在,T-SQL 不會用換行符甚至分號來終止命令(儘管從 SQL Server 2005 開始,分號是首選/推薦的)。因此,由於 SQL Server 知道如何解析每條語句以使其知道何時結束,因此似乎將長行拆分為多行,僅由
newline
/carriage-return
+分隔line-feed
,這似乎並不合理。但這在任何一種情況下都不起作用。PRINT 'Line1 Line2';
返回(在“消息”選項卡中):
Line1 Line2
這很有意義,因為換行符在文字/常量內。但是這樣做
VARBINARY
也行不通。PRINT 0x1234 5678;
給我一個錯誤。
\
值得慶幸的是,在 T-SQL 中通過(反斜杠)字元支持行繼續。只需將其放在行尾,就在newline
/carriage-return
+之前line-feed
,換行符將被忽略。對於文本字元串,其行為如下:
PRINT 'Line1\ Line2';
返回(在“消息”選項卡中):
Line1Line2
對於二進制/十六進製字元串,其行為如下:
PRINT 0x1234\ 5678;
返回(在“消息”選項卡中):
0x12345678;
為了將二進製文件(程序集、證書)格式化為十六進製文本字元串以用於 SQL 腳本,我編寫了一個名為BinaryFormatter的命令行實用程序,我已在 GitHub 上作為開源發布。它不僅將二進製文件轉換為文本表示形式,而且還
VARBINARY
根據每行要使用的指定字元數,使用行延續將長文字分散到所需的多行中。結果是這樣的:4D5A09DE34F178313345A4\ 00007F4E39782EFC48D842\ 00000000
然後我將其複制並粘貼到我的腳本中,如下面的
{...}
區域所示:CREATE ASSEMBLY [AssemblyName] FROM 0x\ {output from BinaryFormatter} ;
有關此主題的更多詳細資訊,請參閱我的部落格文章: T-SQL 中的行繼續