Windows 批次檔令人崩潰的特殊字元處理

有時我們需要對大量的檔案、資料夾分別做壓縮處理。壓縮很簡單，但如果要壓的檔案多達數十數百，一個一個做就太沒效率了。身為專業的程序猿，當然要想點法子偷懶。

我們利用優秀開源綠色軟體 7-Zip 搭配 Windows 內建的批次指令檔來達成偷懶的草根目的。

不過，由於 Windows 的 CMD 對特殊字元超凡入聖的處理能力，我們可以在過程中深切體會到 Windows 批次檔有多麼反人類……。

將多個檔案、資料夾分別壓縮成 7z

我們先從簡單的範例開始：

@echo off
chcp 65001
set "ZIP=%ProgramFiles%\7-Zip\7z.exe"
for %%F in (%*) do (
  "%ZIP%" a -t7z "%%~F.7z" "%%~F" -mx9 -xr!desktop.ini -xr!Thumb.db
)

假設把以上檔案儲存成 Compress7zMax.cmd，之後只要用滑鼠選取多個檔案和資料夾，拖放到這個 Compress7zMax.cmd 批次檔上面，就會分別以最大固實模式壓縮成 7z 檔案。

我們還可以到 %AppData%\Microsoft\Windows\SendTo 資料夾為這個批次檔建立捷徑，取個好聽的名字，例如 最大固實壓縮為 7z，以後選擇檔案與資料夾後就能用右鍵選單的「傳送到」子選單操作。

箇中原理都差不多：把多個檔案或資料夾拖放到或「傳送到」可執行檔或批次檔，就會執行可執行檔或批次檔，並且把每個選取的檔案或資料夾當做參數傳遞進去。

咦？這樣就完成了？不是很簡單嗎？

嗯……你可以試試用這個批次檔壓縮名為 G:\Users\IamGod\Downloads\我是欸漫(神人出品) 的資料夾試試，保證出錯。

這當然不是因為 Windows CMD 內建偵測及阻擋成人內容的功能，而是因為 for...in 會先把輸入的變數展開，變數展開是在執行前完成，因此原程式跑到第 3 行時會執行：

for %%F in (G:\Users\IamGod\Downloads\我是欸漫(神人出品)) do (...)

由於括號對 CMD 有特殊語義，因此程式會找不到真正的資料夾而出錯。

要解決以上問題，一個做法是延遲變數展開，如下：

@echo off
chcp 65001
set "ZIP=%ProgramFiles%\7-Zip\7z.exe"
set ARGS=%*
setlocal EnableDelayedExpansion
for %%F in (!ARGS!) do (
  "%ZIP%" a -t7z "%%~F.7z" "%%~F" -mx9 -xr!desktop.ini -xr!Thumb.db
)
endlocal

這樣程式就會等執行到 !ARGS! 再取出變數值，不會造成 for 迴圈辨識上的混亂。於是我們解決了這問題。

BUT...如果真的這樣改，你會發現程式還是不能跑，而且這次連處理一般檔案都會出錯了！

這是因為 EnableDelayedExpansion 模式下會把 ! 視為特殊字元，而很不幸地我們的 for...in 迴圈在執行到 do 那行時會把裡面的驚歎號當做變數解析，於是在 ...!desktop.ini -xr!... 這個地方出錯。

就算把 -xr!desktop.ini -xr!Thumb.db 刪掉，程式可以正常執行了。但是當要處理的檔案或資料夾含有驚歎號，比如 超刺激神人出品!，還是會出錯，因為執行到 do 時先展開變數的結果是像這樣：

"C:\Program Files\7-Zip\7z.exe" a -t7z "G:\Users\IamGod\Downloads\超刺激神人出品!.7z" "G:\Users\IamGod\Downloads\超刺激神人出品!" -mx9

於是執行時程式就在驚歎號的地方出錯給你看惹！

要解決這問題，我們只好在執行含有驚歎號的程式碼時關掉 EnableDelayedExpansion 模式。於是成為以下的華麗版本：

@echo off
chcp 65001
set "ZIP=%ProgramFiles%\7-Zip\7z.exe"
set ARGS=%*
setlocal EnableDelayedExpansion
for %%F in (!ARGS!) do (
  endlocal
  "%ZIP%" a -t7z "%%~F.7z" "%%~F" -mx9 -xr!desktop.ini -xr!Thumb.db
  setlocal
)
endlocal

如果執行一次 setlocal 卻執行多次 endlocal，可能會在某些情境下發生不可預期的後果，因此我們在每次迴圈後再加上對應的 setlocal。

這次終於解決了吧？

嗯……你可以試試看處理另一個神作：G:\Users\IamGod\Downloads\我是欸漫^神作^，大概會發現結果又怪怪的了……。

這是因為 CMD 在展開 %1、%2、%* 之類的參數後會先解析特殊字元再執行指令，而 ^ 是有特殊意義的字元（為下一個字元脫義，本身則消失），因此執行到第 4 行 set ARGS=%* 時的內容是這樣：

set ARGS=G:\Users\IamGod\Downloads\我是欸漫神作

於是程式又找不到檔案了。

把第 4 行改成 set "ARGS=%*" 也無濟於事，因為 CMD 是先展開變數、解析特殊字元、再執行指令，因此這麼做只是讓執行時變成看到這樣的內容：

set "ARGS=G:\Users\IamGod\Downloads\我是欸漫神作"

結果一樣是找不到檔案。而且 set "ARGS=%*" 有其他副作用──如果參數本來就含有雙引號，加入的雙引號會導致本來的雙引號夾到錯誤的地方。

這問題不會發生在絕對路徑含有空白字元的檔案上，因為 Windows 會自動為含有空白的參數加上雙引號，而 ^ 字元在雙引號中不具有特殊意義。假設我們把上述檔案放到 G:\Users\IamGod\Downloads\my subfolder\我是欸漫^神作^，自動加上雙引號後，執行到第 4 行 set ARGS=%* 時的內容是這樣：

set ARGS="G:\Users\IamGod\Downloads\my subfolder\我是欸漫^神作^"

於是就安全通關，可喜可賀^^

和 ^ 字元一樣在同一時機被處理的特殊字元還包括 "、<LF>、&、|、<、>、(、)，不過 Windows 不允許檔名含有 "、<LF>、|、<、>，而剩下的 &、(、) 本身不像 ^ 會在解析時讓自己消失，set 後放到雙引號裡就能避掉特殊意義安全通關。

這問題除非微軟修，否則理論上是無解，因為一開始傳遞的參數就錯了。

小結

注意變數展開，以及在用批次檔搭配拖放處理大量檔案時，請確保檔名不含 ^ 字元或檔案的絕對路徑含有空白，以保安全。

參考資料

• How does the Windows Command Interpreter (CMD.EXE) parse scripts? -- 詳細解釋 CMD 解析傳入參數的流程

2017/12/02 後記：

感謝 Ranlempow 分享，此程式可利用 goto 搭配 shift 寫成更精簡的版本：

@echo off
chcp 65001
set ZIP="%ProgramFiles%\7-Zip\7z.exe"

:loop
%ZIP% a -t7z "%~1.7z" "%~1" -mx9 -xr!desktop.ini -xr!Thumb.db
shift
if not "%~1" == "" goto loop