1. 為什么要折騰這么一件小事亂碼問題的根源先說個(gè)我實(shí)際遇到的場景。上個(gè)月接手一個(gè)老項(xiàng)目的文檔整理工作同事發(fā)過來一個(gè)壓縮包里面是一百多個(gè).txt、.ini、.sql文件說是從舊服務(wù)器上導(dǎo)出來的。我隨手用記事本打開一個(gè)滿屏的“錕斤拷”“燙燙燙”直接把我勸退了。再打開幾個(gè)有的能正常顯示中文有的全是亂碼同一個(gè)文件夾里居然混著好幾種編碼。這種事兒干過活的人應(yīng)該都不陌生ANSI 編碼下的中文文本換到現(xiàn)代 Windows 11 環(huán)境里打開編碼不對就是一團(tuán)糟。其實(shí)這里頭有個(gè)很典型的歷史包袱。ANSI 在簡體中文 Windows 環(huán)境下實(shí)際指的就是GBK/GB2312 編碼體系它用兩個(gè)字節(jié)表示一個(gè)漢字在當(dāng)年 Windows XP、Windows 7 時(shí)代是絕對的默認(rèn)編碼。而 UTF-8 是后來互聯(lián)網(wǎng)和跨平臺場景下的主流編碼用可變長度字節(jié)表示字符對中英文混合內(nèi)容更友好。問題是現(xiàn)代編輯器VS Code、Notepad、甚至 Windows 11 自帶的記事本默認(rèn)對無 BOM 的文本幾乎都按 UTF-8 處理。于是老文件里那些 GBK 編碼的中文內(nèi)容被按 UTF-8 去解讀立刻就花了。如果只是幾個(gè)文件用記事本另存為、或者 VS Code 里重新打開再改編碼幾秒鐘就搞定。但當(dāng)我面對的是一個(gè)文件夾里嵌套多個(gè)子文件夾、里面有幾百個(gè)文本文件的情況時(shí)手工轉(zhuǎn)換基本等于自虐。這個(gè)活兒真正高效的做法就是用命令行批量處理。標(biāo)題里說的這件事本質(zhì)上是三個(gè)關(guān)鍵詞的組合Win11 環(huán)境、命令行工具鏈、批量編碼轉(zhuǎn)換。這篇文章我把自己實(shí)際驗(yàn)證過的方案完整梳理一遍包括踩過的坑和最終可用的腳本給你一條不走彎路的路徑。2. 方案選型為什么偏偏是命令行以及哪個(gè)命令行2.1 轉(zhuǎn)換編碼的常見思路以及各自的局限性先說說除了命令行之外常見的幾種思路方便你判斷自己到底需不需要繼續(xù)往下看。思路一用編輯器手動(dòng)另存為。這個(gè)就不用多說了文件少可以文件多就是災(zāi)難。哪怕 VS Code 能一次打開多個(gè)文件每個(gè)文件都得手動(dòng)改編碼、保存、再切換下一個(gè)上百個(gè)文件下來手都得抽筋。而且這種方式?jīng)]法遞歸處理子文件夾你得自己一層層翻目錄。思路二用 Notepad 的“批量轉(zhuǎn)換”插件。Notepad 確實(shí)有 Convert Encoding 相關(guān)的功能但“批量對指定文件夾內(nèi)所有文件遞歸轉(zhuǎn)換”這件事需要額外裝插件、配置菜單而且它本質(zhì)上還是一個(gè)圖形界面工具沒法直接嵌入到你自己的自動(dòng)化流程里。如果你只是想臨時(shí)轉(zhuǎn)一批文件它確實(shí)能用但如果你想把這套邏輯寫成腳本、以后定時(shí)跑或者換個(gè)電腦照樣跑它就撂挑子了。思路三用第三方小工具。網(wǎng)上確實(shí)有人做了專門的編碼轉(zhuǎn)換 GUI 工具但這類小工具的來源和質(zhì)量參差不齊有的還捆綁廣告。我反正不太敢把幾百個(gè)項(xiàng)目文件交給一個(gè)來歷不明的 exe 去處理。更關(guān)鍵的是這類工具很多不支持“只轉(zhuǎn)換指定擴(kuò)展名”“跳過某些子目錄”這種精細(xì)控制一旦轉(zhuǎn)錯(cuò)了想批量改回來反而更麻煩。思路四用命令行。這才是適合批量、可重復(fù)、可腳本化的解法。Windows 下原生的命令行環(huán)境有兩種一個(gè)是老的CMD命令提示符一個(gè)是PowerShell。老實(shí)說CMD 做這事很別扭它的編碼處理和循環(huán)能力都太弱了。真正好用的是 PowerShell既有完整的循環(huán)、管道、過濾機(jī)制又能直接調(diào)用 .NET 底層 API讀寫文件時(shí)指定編碼是分分鐘的事。而且在 Win11 上PowerShell 5.1 是系統(tǒng)自帶的不用裝任何額外的東西PowerShell 7 需要單獨(dú)裝但也不是必須。所以我的結(jié)論是用 Windows PowerShell 腳本來做這件事是效率和靈活性的最佳平衡點(diǎn)。2.2 PowerShell 5.1 和 PowerShell 7 的區(qū)別這個(gè)必須先搞清楚寫腳本之前有一個(gè)特別容易踩的坑必須先講明白PowerShell 5.1 和 PowerShell 7對“編碼”的處理邏輯完全不同。PowerShell 5.1 是 Win11 預(yù)裝的老版本它有一個(gè)非?！斑h(yuǎn)古”的設(shè)定——Get-Content命令的-Encoding參數(shù)里有一個(gè)Default選項(xiàng)這個(gè)Default在簡體中文系統(tǒng)上指的就是ANSIGBK。你用Get-Content -Encoding Default去讀一個(gè) GBK 文件讀出來的字符串是正確的再配合Out-File -Encoding UTF8寫回去就能完成轉(zhuǎn)換。這套邏輯在 5.1 里很順手。但 PowerShell 7以前叫 PowerShell Core就完全不一樣了。它對標(biāo)的是跨平臺所以默認(rèn)編碼幾乎一律是 UTF-8 無 BOM-Encoding Default選項(xiàng)直接被移除了你不能再指望“Default”代表 ANSI。在 PowerShell 7 里如果你直接用Get-Content不指定編碼去讀一個(gè) GBK 文件讀出來的內(nèi)容照樣是亂碼。所以百度一搜“PowerShell 批量轉(zhuǎn)碼”你可能會(huì)看到兩種截然不同的答案根源就在這里。我在下面給出的腳本分成了兩套版本一套是給系統(tǒng)自帶的 5.1 用的一套是給 7 用的如果你已經(jīng)升級過的話。用之前先跑一下$PSVersionTable.PSVersion確認(rèn)版本就不會(huì)出錯(cuò)。2.3 為什么 .NET 方法比 Get-Content 更可靠如果你在網(wǎng)上搜索過相關(guān)代碼會(huì)發(fā)現(xiàn)有人推薦直接用 .NET 的方法而不是用 PowerShell 的Get-Content/Set-Content我最終給出來的方案也確實(shí)主要用 .NET 庫。為什么最核心的原因是Get-Content在讀取文件時(shí)會(huì)把每行當(dāng)成一個(gè)對象來處理對于超大文件或者沒有結(jié)尾換行符的文件偶爾會(huì)出現(xiàn)莫名其妙的邊界問題。而 .NET 的[System.IO.File]::ReadAllText()直接把整個(gè)文件作為字符串讀入內(nèi)存再用[System.IO.File]::WriteAllText()一次性寫出去整個(gè)過程更接近“無腦搬運(yùn)”對編碼的掌控也更精確。當(dāng)然它的代價(jià)是如果文件特別大比如幾十 MB 的日志文件一次性讀入內(nèi)存會(huì)有一定壓力。但我實(shí)際測試過普通文本文件幾百 KB 到幾 MB壓根沒壓力。后面我會(huì)提到如果確實(shí)遇到超大文件怎么用流式讀取來規(guī)避內(nèi)存問題。提示轉(zhuǎn)換前建議先備份。一次性寫壞幾百個(gè)文件再想恢復(fù)原樣那才真的是欲哭無淚。3. 核心腳本實(shí)操從零到一完成批量轉(zhuǎn)換3.1 環(huán)境確認(rèn)與安全準(zhǔn)備在敲命令之前先花兩分鐘做三件事確認(rèn) PowerShell 版本、創(chuàng)建測試目錄、備份。打開 Win11 的“開始”菜單搜索 “PowerShell”右鍵選擇“以管理員身份運(yùn)行”。這里不強(qiáng)制要求管理員權(quán)限PowerShell 默認(rèn)權(quán)限也能讀寫大部分目錄但如果你要處理的文件夾在C:\Program Files這種受保護(hù)路徑下還是用管理員省心。接著確認(rèn)版本$PSVersionTable.PSVersion看到Major是 5 就是系統(tǒng)自帶的 5.1看到Major是 7 就是新版這會(huì)決定你后面用哪套腳本。然后我強(qiáng)烈建議你先在本地建一個(gè)測試文件夾里面放三到五個(gè)用“ANSIGBK”編碼保存的中文文本文件這樣轉(zhuǎn)碼之后可以直觀地驗(yàn)證效果不用一上來就動(dòng)真正的業(yè)務(wù)文件。備份這一步推薦最笨但最可靠的方式——直接復(fù)制整個(gè)文件夾到另一個(gè)位置?；蛘呷绻懔?xí)慣用命令行PowerShell 里一條命令就行Copy-Item -Path D:\SourceFolder -Destination D:\BackupFolder -Recurse3.2 最簡版本W(wǎng)in11 自帶 PowerShell 5.1 一鍵轉(zhuǎn)換如果你用的是系統(tǒng)自帶的 PowerShell 5.1那代碼可以寫得非常簡潔。腳本中最關(guān)鍵的參數(shù)有三個(gè)目標(biāo)文件夾路徑、文件擴(kuò)展名過濾器、是否遞歸子目錄。$targetDir D:\TargetFolder $extension *.txt $recurse $true Get-ChildItem -Path $targetDir -Filter $extension -Recurse:$recurse | ForEach-Object { $filePath $_.FullName # 讀取 ANSI即 GBK內(nèi)容到字符串 $contentText Get-Content -LiteralPath $filePath -Encoding Default -Raw # 以 UTF-8 無 BOM 格式寫回 [System.IO.File]::WriteAllText( $filePath, $contentText, [System.Text.UTF8Encoding]::new($false) ) Write-Host Converted: $filePath }逐個(gè)拆解一下免得你復(fù)制完心里沒底Get-ChildItem -Path $targetDir -Filter $extension -Recurse:$recurse這一步負(fù)責(zé)把指定目錄下所有符合條件的文件都找出來。-Filter支持通配符*.txt就只轉(zhuǎn)文本文件如果你要轉(zhuǎn).sql就改成*.sql想轉(zhuǎn)所有文件就改成*.*非常靈活。-Recurse參數(shù)決定是否深入子文件夾。Get-Content -LiteralPath $filePath -Encoding Default -Raw這一行的重點(diǎn)是-Encoding Default。在 PowerShell 5.1 里Default就是 ANSI。加-Raw是為了讓整個(gè)文件內(nèi)容作為一個(gè)整體字符串返回而不是拆成行數(shù)組這樣寫回去的時(shí)候不會(huì)因?yàn)樾形卜柌町惗冃巍System.IO.File]::WriteAllText($filePath, $contentText, [System.Text.UTF8Encoding]::new($false))這一行把讀出來的字符串用 UTF-8 編碼寫回原文件。new($false)里的布爾值代表“不帶 BOM”。BOM 是文件開頭的一段特殊字節(jié)序標(biāo)記某些老程序不認(rèn)它所以更多時(shí)候我們選擇不帶 BOM 的 UTF-8。寫完腳本保存成.ps1文件或者在 PowerShell 窗口里直接粘貼逐行執(zhí)行都能跑通。3.3 通用版本兼容 PowerShell 5.1 和 7 的寫法剛才說過了PowerShell 7 里沒有-Encoding Default。所以如果你的機(jī)器裝的是 PowerShell 7或者你想寫一個(gè)“任何版本都能跑”的腳本需要用 .NET 的編碼類來手動(dòng)指定 ANSI。$targetDir D:\TargetFolder $extension *.txt $recurse $true # 關(guān)鍵顯式指定 GBK 編碼 $ansiEncoding [System.Text.Encoding]::GetEncoding(GBK) $utf8Encoding [System.Text.UTF8Encoding]::new($false) Get-ChildItem -Path $targetDir -Filter $extension -Recurse:$recurse | ForEach-Object { $filePath $_.FullName # 用 .NET 方法讀取顯式指定 ANSI 編碼 $contentText [System.IO.File]::ReadAllText($filePath, $ansiEncoding) # 寫入 UTF-8 無 BOM [System.IO.File]::WriteAllText($filePath, $contentText, $utf8Encoding) Write-Host Converted: $filePath }這一版的關(guān)鍵區(qū)別就在[System.Text.Encoding]::GetEncoding(GBK)。注意這里我寫的是GBK而不是GB2312。原因是GBK 是 GB2312 的超集它向下兼容 GB2312同時(shí)能處理更多生僻字。在簡體中文 Windows 上ANSI 指的實(shí)際就是 GBK所以用 GBK 去讀是在兼容性上最穩(wěn)的。如果你處理的是繁體中文環(huán)境那得改成GetEncoding(BIG5)如果是日文環(huán)境對應(yīng)的編碼名是EUC-JP或Shift_JIS。這一點(diǎn)后面講排錯(cuò)的時(shí)候還會(huì)再提到。3.4 按需擴(kuò)展只處理特定目錄層級、跳過特殊文件夾實(shí)際操作中經(jīng)常會(huì)遇到“只需要轉(zhuǎn)某個(gè)子目錄下的文件其他子目錄不要?jiǎng)印钡男枨?。不用急著改腳本結(jié)構(gòu)Get-ChildItem本身就支持路徑過濾你可以把整個(gè)Get-ChildItem換成兩次調(diào)用或者用Where-Object做二次過濾。舉例說明假設(shè)目錄結(jié)構(gòu)是這樣的D:\Project ├── docs\ ├── src\ # 只轉(zhuǎn)這里面的 .java 文件 ├── test\ └── include\那么你的目標(biāo)路徑直接寫成D:\Project\src把$extension改成*.java就行。如果不想遞歸到某些子目錄一個(gè)比較笨但有效的做法是先枚舉目錄再在腳本里判斷Get-ChildItem -Path $targetDir -Recurse -Directory | Where-Object { $_.Name -notin (node_modules, .git, dist) } | ForEach-Object { Get-ChildItem -Path $_.FullName -Filter $extension | ForEach-Object { # 轉(zhuǎn)碼邏輯和上面一樣 } }這個(gè)寫法會(huì)把指定目錄下所有子目錄都列出來過濾掉node_modules、.git這類你絕對不想碰的文件夾然后再逐層處理文件。雖然代碼多了一點(diǎn)但在真實(shí)項(xiàng)目里非常實(shí)用。3.5 高級參數(shù)說明UTF-8 到底要不要 BOM關(guān)于 BOM 這個(gè)問題值得單獨(dú)說一段。BOMByte Order Mark是 Unicode 規(guī)范里用來標(biāo)識文本編碼和字節(jié)序的一組特殊字節(jié)。UTF-8 的 BOM 在文件開頭是EF BB BF這三個(gè)字節(jié)。很多從 Windows 老環(huán)境出來的人習(xí)慣了帶 BOM 的 UTF-8因?yàn)橛浭卤灸芤谎圩R別。但放到 Linux、Git、或者某些命令行工具里BOM 反而會(huì)被當(dāng)成特殊字符導(dǎo)致一些莫名其妙的報(bào)錯(cuò)。比如在 Linux 下用grep匹配文件內(nèi)容第一個(gè)字符如果帶 BOM你可能匹配不上再比如有的編譯工具鏈會(huì)因?yàn)槟阍创a開頭多了三個(gè)字節(jié)直接給你報(bào)錯(cuò)。我的做法是**如果這個(gè)文件要被程序讀取源碼、配置、腳本一律轉(zhuǎn)成無 BOM 的 UTF-8如果只是給人看的文檔帶不帶 BOM 其實(shí)無所謂。**上面腳本里寫new($false)就是無 BOM如果你想改成帶 BOM把$false換成$true就行。4. 常見問題與排查實(shí)錄那些年我踩過的坑4.1 轉(zhuǎn)完之后文件反而變成亂碼了是怎么回事這是最讓人崩潰的問題轉(zhuǎn)之前源文件好歹在記事本里還能看轉(zhuǎn)完之后直接全花。十有八九是你讀取的時(shí)候編碼就用錯(cuò)了。舉一個(gè)我實(shí)際遇到的例子。同事給我的文件用 Notepad 看右下角顯示的是 “ANSI”我當(dāng)時(shí)就直接用Get-Encoding(GBK)去讀了。轉(zhuǎn)完一部分之后我發(fā)現(xiàn)有幾個(gè)文件出現(xiàn)少量錯(cuò)別字個(gè)別生僻字直接變成了“?”。排查了一下發(fā)現(xiàn)這些文件不是標(biāo)準(zhǔn) GBK而是GB18030編碼保存的里面包含了超出 GBK 字符集的擴(kuò)展?jié)h字。解決辦法是把編碼讀取參數(shù)換成GB18030。GB18030 是 GBK 的進(jìn)一步擴(kuò)展理論上能表示幾乎所有中文字符而且它是向下兼容 GBK 的。換句話說用 GB18030 去讀 GBK 文件沒問題但用 GBK 去讀 GB18030 文件就可能丟字。如果你不確定源文件到底是哪種直接統(tǒng)一用GetEncoding(GB18030)是最穩(wěn)的選擇。4.2 轉(zhuǎn)換后中文正常但英文和數(shù)字旁邊多了一個(gè)“?”這個(gè)癥狀我一開始碰到還以為是文件里原來就有的東西后來才發(fā)現(xiàn)問題出在編碼轉(zhuǎn)換器遇到無法映射的字符時(shí)的默認(rèn)替代行為。當(dāng)你用某種編碼讀文件時(shí)如果遇到該編碼無法表示的字符比如 GBK 里沒有某個(gè)特殊符號或者編碼聲明與實(shí)際內(nèi)容不符.NET 會(huì)把那個(gè)位置替換成一個(gè)默認(rèn)的替代字符——通常就是“?”。排查思路隨便取一個(gè)出問題的文件先用十六進(jìn)制編輯器看一下原始字節(jié)再對比轉(zhuǎn)換后的字節(jié)看看多出來的“?”在哪些位置。如果“?”出現(xiàn)的規(guī)律和某些特殊字符比如€、?對得上那說明源文件其實(shí)不是純中文 ANSI里面混了其他編碼的字符。這時(shí)候你得先確認(rèn)這些文件的真實(shí)編碼再?zèng)Q定讀的時(shí)候用什么編碼。在腳本層面你可以顯式指定替換策略$ansiEncoding [System.Text.Encoding]::GetEncoding( GBK, [System.Text.EncoderFallback]::ExceptionFallback, [System.Text.DecoderFallback]::ExceptionFallback )這樣設(shè)置之后一旦遇到無法解碼的字節(jié)會(huì)直接拋出異常提示你而不是靜默地替換成“?”。4.3 PowerShell 腳本執(zhí)行時(shí)提示“因?yàn)樵诖讼到y(tǒng)上禁止運(yùn)行腳本”Win11 默認(rèn)的 PowerShell 執(zhí)行策略是Restricted只允許運(yùn)行單個(gè)命令不允許執(zhí)行.ps1腳本文件。這時(shí)候你直接執(zhí)行腳本文件會(huì)報(bào)錯(cuò)。解決方法有幾個(gè)臨時(shí)開放當(dāng)前會(huì)話的執(zhí)行策略只對當(dāng)前窗口有效關(guān)掉就恢復(fù)Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass用-ExecutionPolicy Bypass參數(shù)直接啟動(dòng) PowerShellpowershell -ExecutionPolicy Bypass -File D:\Script\convert.ps1如果你是 Win11 系統(tǒng)自帶終端Windows Terminal也可以在配置文件里把默認(rèn)執(zhí)行策略改寬。提示Set-ExecutionPolicy改的是系統(tǒng)級的執(zhí)行策略改完記得用Get-ExecutionPolicy檢查確認(rèn)。如果你只是臨時(shí)用一下用-Scope Process就夠了別動(dòng)全局。4.4 文件被占用或者無權(quán)限寫入怎么處理如果你的目標(biāo)文件夾在系統(tǒng)目錄或者有一個(gè)程序正好打開了某個(gè)文件比如數(shù)據(jù)庫服務(wù)正在讀一個(gè).sql文件WriteAllText就會(huì)拋 “UnauthorizedAccessException” 或 “IOException”。處理方式有兩個(gè)維度一是權(quán)限維度用管理員身份運(yùn)行 PowerShell或者給當(dāng)前用戶添加目標(biāo)文件夾的“修改”權(quán)限。二是文件占用維度腳本里加一層容錯(cuò)遇到占用就跳過并記錄日志try { [System.IO.File]::WriteAllText($filePath, $contentText, $utf8Encoding) Write-Host Converted: $filePath } catch { Write-Warning Failed: $filePath - $($_.Exception.Message) }4.5 超大文件轉(zhuǎn)換時(shí)內(nèi)存飆升怎么辦前面說過的ReadAllText會(huì)把整個(gè)文件讀入內(nèi)存如果碰到一個(gè)幾百 MB 的超大文件內(nèi)存占用會(huì)非常難看。遇到這種極端場景用流式讀寫的思路更穩(wěn)。簡單的實(shí)現(xiàn)思路用StreamReader按塊讀取再用StreamWriter按塊寫入。你可以把整個(gè)腳本里的核心轉(zhuǎn)換部分替換成$readEncoding [System.Text.Encoding]::GetEncoding(GB18030) $writeEncoding [System.Text.UTF8Encoding]::new($false) $reader [System.IO.StreamReader]::new($filePath, $readEncoding) $writer [System.IO.StreamWriter]::new($filePath, $false, $writeEncoding) try { while ($null -ne ($line $reader.ReadLine())) { $writer.WriteLine($line) } } finally { $writer.Dispose() $reader.Dispose() }這里有個(gè)注意事項(xiàng)用ReadLineWriteLine的方式會(huì)保證行尾統(tǒng)一為當(dāng)前系統(tǒng)的換行符。如果你的源文件是 Linux 風(fēng)格的LF換行轉(zhuǎn)完后可能變成 Windows 風(fēng)格的CRLF內(nèi)容不變格式變了。要是你特別在意這個(gè)可以考慮用StreamReader.ReadBlock配合緩沖區(qū)原樣復(fù)制不過常規(guī)場景下這種差異基本無感。4.6 常見問題速查表癥狀可能原因解決辦法轉(zhuǎn)換后全是“?”讀取編碼不對GBK 無法覆蓋某些字符改用 GB18030 讀取轉(zhuǎn)換后文件變亂碼源文件其實(shí)是 UTF-8被當(dāng)成 ANSI 讀了一遍先確認(rèn)源文件真實(shí)編碼不亂套“ANSI 一律是 GBK”腳本報(bào)錯(cuò)“禁止運(yùn)行”執(zhí)行策略限制Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass寫入時(shí)提示文件被占用文件被其他程序鎖定用 try/catch 跳過并記錄或關(guān)閉占用程序轉(zhuǎn)換后換行符變了用 ReadLine/WriteLine 導(dǎo)致用流式按塊復(fù)制或接受換行符變化個(gè)別文件轉(zhuǎn)出來是空的原文件本身就是空文件或純 ASCII 無字符腳本里加個(gè)文件長度判斷空文件直接跳過5. 從腳本到工具如何把這套邏輯固化成日常可用的命令5.1 保存成 .ps1 腳本文件最直接的固化方式就是把上面通用版腳本保存成一個(gè).ps1文件比如命名為Convert-ToUtf8.ps1。這樣以后要用的時(shí)候直接打開 PowerShell 執(zhí)行一遍即可。如果你連打開 PowerShell 都嫌麻煩可以做一個(gè).bat文件來調(diào)起它。比如你的腳本放在D:\Scripts\Convert-ToUtf8.ps1在同一個(gè)目錄下建一個(gè)run_convert.bat內(nèi)容如下echo off powershell -ExecutionPolicy Bypass -File D:\Scripts\Convert-ToUtf8.ps1 pause這樣雙擊.bat文件就能執(zhí)行轉(zhuǎn)換。腳本里的目標(biāo)路徑改一次就行下次有同樣需求直接雙擊。5.2 把腳本設(shè)計(jì)得更通用傳參而不是改代碼上面這種做法有一個(gè)缺點(diǎn)每次目標(biāo)路徑變了你得改腳本內(nèi)容。如果你經(jīng)常需要處理不同文件夾更合理的做法是把腳本變成一個(gè)“帶參數(shù)的函數(shù)”。在 PowerShell 里這很容易實(shí)現(xiàn)腳本開頭定義參數(shù)param( [Parameter(Mandatory$true)] [string]$TargetDir, [string]$Filter *.txt, [switch]$Recurse $true ) $ansiEncoding [System.Text.Encoding]::GetEncoding(GB18030) $utf8Encoding [System.Text.UTF8Encoding]::new($false) Get-ChildItem -Path $TargetDir -Filter $Filter -Recurse:$Recurse | ForEach-Object { $filePath $_.FullName $contentText [System.IO.File]::ReadAllText($filePath, $ansiEncoding) [System.IO.File]::WriteAllText($filePath, $contentText, $utf8Encoding) Write-Host Converted: $filePath }然后調(diào)用方式就變成.\Convert-ToUtf8.ps1 -TargetDir D:\NewProject -Filter *.sql -Recurse這樣你就不用每次編輯腳本了路徑、擴(kuò)展名、是否遞歸都通過參數(shù)控制。甚至可以在.bat文件里用%1包裝成“拖拽文件夾到批處理圖標(biāo)上就能轉(zhuǎn)換”的效果echo off powershell -ExecutionPolicy Bypass -File D:\Scripts\Convert-ToUtf8.ps1 -TargetDir %1 pause把文件夾拖到這個(gè)批處理文件上它就會(huì)自動(dòng)讀取%1這個(gè)路徑直接開轉(zhuǎn)。我這兩年處理外部交付的項(xiàng)目文件都是這么干的效率提升非常明顯。5.3 什么情況下你需要額外注意源文件的編碼識別腳本是無腦的但真實(shí)文件系統(tǒng)是混亂的。你可能會(huì)遇到一個(gè)文件夾里既有 ANSI 文件又有本來已經(jīng)是 UTF-8 的文件。你又想只把 ANSI 的轉(zhuǎn)換掉不碰已經(jīng)是 UTF-8 的那些怎么辦方法一轉(zhuǎn)換前檢測文件是否包含非法 UTF-8 序列。思路是用 UTF-8 編碼去讀取文件如果拋出異常說明它大概率不是 UTF-8function Test-IsValidUtf8($path) { try { $null [System.IO.File]::ReadAllText($path, [System.Text.UTF8Encoding]::new($false, $true)) return $true } catch { return $false } }這里[System.Text.UTF8Encoding]::new($false, $true)的第二個(gè)參數(shù)$true表示啟用嚴(yán)格校驗(yàn)遇到非法字節(jié)就拋異常。實(shí)際用的時(shí)候先把所有文件過一遍這個(gè)函數(shù)把返回$false的文件收集起來再批量轉(zhuǎn)換。方法二直接全量統(tǒng)一轉(zhuǎn)換。如果你的應(yīng)用場景能接受“所有文件都變成 UTF-8”那就無所謂了反正 UTF-8 文件再轉(zhuǎn)一遍 UTF-8 也不會(huì)壞。這種方法省事唯一的風(fēng)險(xiǎn)是文件里如果有其他特殊編碼比如 UTF-16你拿 ANSI 去讀就會(huì)讀錯(cuò)然后寫回之后文件就真的壞了。所以我的建議還是如果文件夾來源復(fù)雜先用方法一篩一遍。5.4 與 Win11 自帶功能的時(shí)間線為什么不用記事本批量處理有人可能會(huì)問Win11 的記事本不是已經(jīng)能識別各種編碼了嗎確實(shí)新版記事本在打開文件時(shí)能自動(dòng)識別編碼右下角狀態(tài)欄還能顯示當(dāng)前編碼甚至另存為時(shí)能選擇“UTF-8 with BOM”“UTF-8”“UTF-16 LE”等選項(xiàng)。但這里的關(guān)鍵是記事本沒有批量處理能力它一次只能打開一個(gè)文件。對上百個(gè)文件來說打開一個(gè)、轉(zhuǎn)換一個(gè)、保存一個(gè)、關(guān)掉一個(gè)這個(gè)流程重復(fù)一百遍任何正常人都受不了。命令行方案的真正價(jià)值是“一次性處理”而且你把腳本寫好了以后它就是一件順手拈來的工具不需要每次重新思考。6. 實(shí)際體會(huì)與盡可能少走的彎路最后想聊兩句不扯技術(shù)純經(jīng)驗(yàn)。做這類批量轉(zhuǎn)換最忌諱的就是上來就動(dòng)手。我第一次給別人處理項(xiàng)目文件的時(shí)候沒做備份也沒驗(yàn)證直接跑腳本結(jié)果把一個(gè)本來就好的 UTF-8 文件用 ANSI 讀了一遍寫完直接報(bào)廢最后用了半天時(shí)間去還原。從那以后我給自己定了一個(gè)鐵律凡是批量操作第一件事永遠(yuǎn)是備份第二件事永遠(yuǎn)是先拿兩三個(gè)文件做小范圍測試確認(rèn)沒問題了再全量執(zhí)行。另外源文件的編碼識別不能想當(dāng)然。很多工具顯示“ANSI”其實(shí)指的是“系統(tǒng)當(dāng)前默認(rèn) ANSI 代碼頁”簡體中文系統(tǒng)上是 GBK繁體系統(tǒng)上可能是 BIG5如果你把這些文件拿到一個(gè)日文系統(tǒng)的 Win11 上去跑同樣是“ANSI”讀出來的內(nèi)容完全不一樣。所以如果你的工作環(huán)境涉及到其他語言版本的 Windows或者文件可能來自不同地區(qū)的同事寫腳本時(shí)盡量用明確的編碼名GB18030、Big5、Shift_JIS不要依賴“Default”這種模糊概念。這套腳本我現(xiàn)在還用著每隔一段時(shí)間就會(huì)因?yàn)椴煌枨蠹右稽c(diǎn)小功能比如支持把編碼信息輸出到一個(gè)日志文件、支持把轉(zhuǎn)換結(jié)果統(tǒng)計(jì)匯總。本質(zhì)上它已經(jīng)不是一個(gè)“一次性腳本”而是一個(gè)不斷積累的小工具箱。你只要把基礎(chǔ)版本跑通后續(xù)按需擴(kuò)展它會(huì)越來越順手。希望這篇文章能讓你少走幾步彎路直接把這件事一次做對。