UTF-8 BOM 導致 SQL 腳本在 Linux 下執行報錯 SP2-0734 完整排查與解決

Windows 編寫的 SQL 文件放到 Linux 執行，明明編碼都是 UTF-8，卻拋出 SP2-0734: unknown command beginning "?--create ..."。罪魁禍首是 UTF-8 with BOM。本文完整記錄排查過程、原理分析與兩種修復方案。

現象重現

--create tablespace
declare
v_tbs_name varchar2(200):='hytpdtsmsshistorydb';
begin
...

錯誤：

SP2-0734: unknown command beginning "?--create ..." - rest of line ignored.
PL/SQL procedure successfully completed.

文件頭幾行明明是註釋或 declare，卻被識別為未知命令「?--create」。

根因分析

• BOM (Byte Order Mark)：UTF-8 文件開頭可選的 3 字節 EF BB BF，用於標識字節序。
• Windows 記事本、部分 IDE 默認保存為 UTF-8 with BOM。
• Linux 下 Oracle SQL*Plus、Shell、Python 等工具不識別 BOM，將其視為普通字符，導致第一行開頭出現隱形字符 ?（或亂碼），解析器以為是非法命令開頭。
• file 命令可鑒別：

  $ file *.sql
  crt_tab_xxx.sql: UTF-8 Unicode (with BOM) text
  normal.sql:      UTF-8 Unicode text

解決方案

方法一：Linux 下用 vi/vim 轉碼（推薦，無需下載）

vim crt_tab_xxx.sql
:set fileencoding=utf-8
:set nobomb
:wq

• :set fileencoding=utf-8 確保目標編碼。
• :set nobomb 移除 BOM 標記。
• :wq 保存退出。

方法二：Windows 下 UltraEdit / Notepad++ / VS Code 另存為

• UltraEdit：文件 → 轉換 → 「UTF-8 - 無 BOM」 → 保存。
• Notepad++：編碼 → 選「UTF-8」而非「UTF-8-BOM」 → 保存。
• VS Code：右下角編碼欄點擊 → 「以編碼保存」 → 選「UTF-8」 → 確認狀態欄顯示「UTF-8」而非「UTF-8 with BOM」。

驗證修復

$ file crt_tab_xxx.sql
crt_tab_xxx.sql: UTF-8 Unicode text  # 不再顯示 with BOM
$ sqlplus user/pass @crt_tab_xxx.sql
-- 正常執行，無 SP2-0734

最佳實踐建議

1. 團隊統一規範：項目 .editorconfig 設置 insert_final_newline = true、charset = utf-8、bom = false。
2. CI/CD 攔截：構建腳本加入 file 或 grep -r $'\xEF\xBB\xBF' 檢查，發現 BOM 直接失敗。
3. IDE 全局設置：IDEA/Eclipse/VS Code 設置默認保存為無 BOM UTF-8。
4. 跨平台協作：文檔、腳本、配置文件一律無 BOM，避免「在我機器上好使」的陷阱。

一個隱形的 BOM，能讓整條部署鏈路卡住半天。養成「無 BOM UTF-8」習慣，是跨平台開發的基本功。