Win11下PowerShell批量将GBK/ANSI文件转为UTF-8编码

1. 为什么要折腾这么一件小事：乱码问题的根源

先说个我实际遇到的场景。上个月接手一个老项目的文档整理工作，同事发过来一个压缩包，里面是一百多个.txt、.ini、.sql文件，说是从旧服务器上导出来的。我随手用记事本打开一个，满屏的“锟斤拷”“烫烫烫”直接把我劝退了。再打开几个，有的能正常显示中文，有的全是乱码，同一个文件夹里居然混着好几种编码。这种事儿干过活的人应该都不陌生：ANSI 编码下的中文文本，换到现代 Windows 11 环境里打开，编码不对就是一团糟。

其实这里头有个很典型的历史包袱。ANSI 在简体中文 Windows 环境下，实际指的就是GBK/GB2312 编码体系，它用两个字节表示一个汉字，在当年 Windows XP、Windows 7 时代是绝对的默认编码。而 UTF-8 是后来互联网和跨平台场景下的主流编码，用可变长度字节表示字符，对中英文混合内容更友好。问题是，现代编辑器（VS Code、Notepad++、甚至 Windows 11 自带的记事本）默认对无 BOM 的文本几乎都按 UTF-8 处理。于是老文件里那些 GBK 编码的中文内容，被按 UTF-8 去解读，立刻就花了。

如果只是几个文件，用记事本另存为、或者 VS Code 里重新打开再改编码，几秒钟就搞定。但当我面对的是一个文件夹里嵌套多个子文件夹、里面有几百个文本文件的情况时，手工转换基本等于自虐。这个活儿真正高效的做法，就是用命令行批量处理。标题里说的这件事，本质上是三个关键词的组合：Win11 环境、命令行工具链、批量编码转换。这篇文章我把自己实际验证过的方案完整梳理一遍，包括踩过的坑和最终可用的脚本，给你一条不走弯路的路径。

2. 方案选型：为什么偏偏是命令行，以及哪个命令行

2.1 转换编码的常见思路，以及各自的局限性

先说说除了命令行之外常见的几种思路，方便你判断自己到底需不需要继续往下看。

思路一：用编辑器手动另存为。这个就不用多说了，文件少可以，文件多就是灾难。哪怕 VS Code 能一次打开多个文件，每个文件都得手动改编码、保存、再切换下一个，上百个文件下来手都得抽筋。而且这种方式没法递归处理子文件夹，你得自己一层层翻目录。

思路二：用 Notepad++ 的“批量转换”插件。Notepad++ 确实有 Convert Encoding 相关的功能，但“批量对指定文件夹内所有文件递归转换”这件事，需要额外装插件、配置菜单，而且它本质上还是一个图形界面工具，没法直接嵌入到你自己的自动化流程里。如果你只是想临时转一批文件，它确实能用；但如果你想把这套逻辑写成脚本、以后定时跑或者换个电脑照样跑，它就撂挑子了。

思路三：用第三方小工具。网上确实有人做了专门的编码转换 GUI 工具，但这类小工具的来源和质量参差不齐，有的还捆绑广告。我反正不太敢把几百个项目文件交给一个来历不明的 exe 去处理。更关键的是，这类工具很多不支持“只转换指定扩展名”“跳过某些子目录”这种精细控制，一旦转错了，想批量改回来反而更麻烦。

思路四：用命令行。这才是适合批量、可重复、可脚本化的解法。Windows 下原生的命令行环境有两种：一个是老的CMD（命令提示符），一个是PowerShell。老实说，CMD 做这事很别扭，它的编码处理和循环能力都太弱了。真正好用的是 PowerShell，既有完整的循环、管道、过滤机制，又能直接调用 .NET 底层 API，读写文件时指定编码是分分钟的事。而且在 Win11 上，PowerShell 5.1 是系统自带的，不用装任何额外的东西（PowerShell 7 需要单独装，但也不是必须）。

所以我的结论是：用 Windows PowerShell 脚本来做这件事，是效率和灵活性的最佳平衡点。

2.2 PowerShell 5.1 和 PowerShell 7 的区别，这个必须先搞清楚

写脚本之前有一个特别容易踩的坑，必须先讲明白：PowerShell 5.1 和 PowerShell 7，对“编码”的处理逻辑完全不同。

PowerShell 5.1 是 Win11 预装的老版本，它有一个非常“远古”的设定——Get-Content命令的-Encoding参数里有一个Default选项，这个Default在简体中文系统上指的就是ANSI（GBK）。你用Get-Content -Encoding Default去读一个 GBK 文件，读出来的字符串是正确的，再配合Out-File -Encoding UTF8写回去，就能完成转换。这套逻辑在 5.1 里很顺手。

但 PowerShell 7（以前叫 PowerShell Core）就完全不一样了。它对标的是跨平台，所以默认编码几乎一律是 UTF-8 无 BOM，-Encoding Default选项直接被移除了，你不能再指望“Default”代表 ANSI。在 PowerShell 7 里，如果你直接用Get-Content（不指定编码）去读一个 GBK 文件，读出来的内容照样是乱码。

所以，百度一搜“PowerShell 批量转码”，你可能会看到两种截然不同的答案，根源就在这里。我在下面给出的脚本，分成了两套版本：一套是给系统自带的 5.1 用的，一套是给 7+ 用的（如果你已经升级过的话）。用之前先跑一下$PSVersionTable.PSVersion确认版本，就不会出错。

2.3 为什么 .NET 方法比 Get-Content 更可靠

如果你在网上搜索过相关代码，会发现有人推荐直接用 .NET 的方法，而不是用 PowerShell 的Get-Content/Set-Content，我最终给出来的方案也确实主要用 .NET 库。为什么？

最核心的原因是：Get-Content在读取文件时会把每行当成一个对象来处理，对于超大文件或者没有结尾换行符的文件，偶尔会出现莫名其妙的边界问题。而 .NET 的[System.IO.File]::ReadAllText()直接把整个文件作为字符串读入内存，再用[System.IO.File]::WriteAllText()一次性写出去，整个过程更接近“无脑搬运”，对编码的掌控也更精确。

当然，它的代价是，如果文件特别大（比如几十 MB 的日志文件），一次性读入内存会有一定压力。但我实际测试过，普通文本文件（几百 KB 到几 MB）压根没压力。后面我会提到，如果确实遇到超大文件，怎么用流式读取来规避内存问题。

提示：转换前建议先备份。一次性写坏几百个文件再想恢复原样，那才真的是欲哭无泪。

3. 核心脚本实操：从零到一完成批量转换

3.1 环境确认与安全准备

在敲命令之前，先花两分钟做三件事：确认 PowerShell 版本、创建测试目录、备份。

打开 Win11 的“开始”菜单，搜索 “PowerShell”，右键选择“以管理员身份运行”。这里不强制要求管理员权限，PowerShell 默认权限也能读写大部分目录，但如果你要处理的文件夹在C:\Program Files这种受保护路径下，还是用管理员省心。

接着确认版本：

$PSVersionTable.PSVersion

看到Major是 5 就是系统自带的 5.1，看到Major是 7 就是新版，这会决定你后面用哪套脚本。

然后，我强烈建议你先在本地建一个测试文件夹，里面放三到五个用“ANSI（GBK）”编码保存的中文文本文件，这样转码之后可以直观地验证效果，不用一上来就动真正的业务文件。

备份这一步，推荐最笨但最可靠的方式——直接复制整个文件夹到另一个位置。或者如果你习惯用命令行，PowerShell 里一条命令就行：

Copy-Item -Path "D:\SourceFolder" -Destination "D:\BackupFolder" -Recurse

3.2 最简版本：Win11 自带 PowerShell 5.1 一键转换

如果你用的是系统自带的 PowerShell 5.1，那代码可以写得非常简洁。脚本中最关键的参数有三个：目标文件夹路径、文件扩展名过滤器、是否递归子目录。

$targetDir = "D:\TargetFolder" $extension = "*.txt" $recurse = $true Get-ChildItem -Path $targetDir -Filter $extension -Recurse:$recurse | ForEach-Object { $filePath = $_.FullName # 读取 ANSI（即 GBK）内容到字符串 $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" }

逐个拆解一下，免得你复制完心里没底：

• Get-ChildItem -Path $targetDir -Filter $extension -Recurse:$recurse：这一步负责把指定目录下所有符合条件的文件都找出来。-Filter支持通配符，*.txt就只转文本文件，如果你要转.sql就改成*.sql，想转所有文件就改成*.*，非常灵活。-Recurse参数决定是否深入子文件夹。
• Get-Content -LiteralPath $filePath -Encoding Default -Raw：这一行的重点是-Encoding Default。在 PowerShell 5.1 里，Default就是 ANSI。加-Raw是为了让整个文件内容作为一个整体字符串返回，而不是拆成行数组，这样写回去的时候不会因为行尾符号差异而变形。
• [System.IO.File]::WriteAllText($filePath, $contentText, [System.Text.UTF8Encoding]::new($false))：这一行把读出来的字符串用 UTF-8 编码写回原文件。new($false)里的布尔值代表“不带 BOM”。BOM 是文件开头的一段特殊字节序标记，某些老程序不认它，所以更多时候我们选择不带 BOM 的 UTF-8。

写完脚本，保存成.ps1文件，或者在 PowerShell 窗口里直接粘贴逐行执行，都能跑通。

3.3 通用版本：兼容 PowerShell 5.1 和 7 的写法

刚才说过了，PowerShell 7 里没有-Encoding Default。所以如果你的机器装的是 PowerShell 7，或者你想写一个“任何版本都能跑”的脚本，需要用 .NET 的编码类来手动指定 ANSI。

$targetDir = "D:\TargetFolder" $extension = "*.txt" $recurse = $true # 关键：显式指定 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" }

这一版的关键区别就在[System.Text.Encoding]::GetEncoding("GBK")。注意，这里我写的是GBK而不是GB2312。原因是GBK 是 GB2312 的超集，它向下兼容 GB2312，同时能处理更多生僻字。在简体中文 Windows 上，ANSI 指的实际就是 GBK，所以用 GBK 去读是在兼容性上最稳的。如果你处理的是繁体中文环境，那得改成GetEncoding("BIG5")；如果是日文环境，对应的编码名是"EUC-JP"或"Shift_JIS"。这一点后面讲排错的时候还会再提到。

3.4 按需扩展：只处理特定目录层级、跳过特殊文件夹

实际操作中，经常会遇到“只需要转某个子目录下的文件，其他子目录不要动”的需求。不用急着改脚本结构，Get-ChildItem本身就支持路径过滤，你可以把整个Get-ChildItem换成两次调用，或者用Where-Object做二次过滤。

举例说明，假设目录结构是这样的：

D:\Project ├── docs\ ├── src\ # 只转这里面的 .java 文件 ├── test\ └── include\

那么你的目标路径直接写成D:\Project\src，把$extension改成*.java就行。如果不想递归到某些子目录，一个比较笨但有效的做法是先枚举目录，再在脚本里判断：

Get-ChildItem -Path $targetDir -Recurse -Directory | Where-Object { $_.Name -notin @("node_modules", ".git", "dist") } | ForEach-Object { Get-ChildItem -Path $_.FullName -Filter $extension | ForEach-Object { # 转码逻辑，和上面一样 } }

这个写法会把指定目录下所有子目录都列出来，过滤掉node_modules、.git这类你绝对不想碰的文件夹，然后再逐层处理文件。虽然代码多了一点，但在真实项目里非常实用。

3.5 高级参数说明：UTF-8 到底要不要 BOM

关于 BOM 这个问题，值得单独说一段。BOM（Byte Order Mark）是 Unicode 规范里用来标识文本编码和字节序的一组特殊字节。UTF-8 的 BOM 在文件开头是EF BB BF这三个字节。

很多从 Windows 老环境出来的人，习惯了带 BOM 的 UTF-8，因为记事本能一眼识别。但放到 Linux、Git、或者某些命令行工具里，BOM 反而会被当成特殊字符，导致一些莫名其妙的报错。比如在 Linux 下用grep匹配文件内容，第一个字符如果带 BOM，你可能匹配不上；再比如有的编译工具链会因为你源码开头多了三个字节，直接给你报错。

我的做法是：**如果这个文件要被程序读取（源码、配置、脚本），一律转成无 BOM 的 UTF-8；如果只是给人看的文档，带不带 BOM 其实无所谓。**上面脚本里写new($false)，就是无 BOM；如果你想改成带 BOM，把$false换成$true就行。

4. 常见问题与排查实录：那些年我踩过的坑

4.1 转完之后文件反而变成乱码了，是怎么回事

这是最让人崩溃的问题：转之前源文件好歹在记事本里还能看，转完之后直接全花。十有八九是你读取的时候编码就用错了。

举一个我实际遇到的例子。同事给我的文件，用 Notepad++ 看右下角显示的是 “ANSI”，我当时就直接用Get-Encoding("GBK")去读了。转完一部分之后，我发现有几个文件出现少量错别字，个别生僻字直接变成了“?”。排查了一下，发现这些文件不是标准 GBK，而是GB18030编码保存的，里面包含了超出 GBK 字符集的扩展汉字。

解决办法是：把编码读取参数换成"GB18030"。GB18030 是 GBK 的进一步扩展，理论上能表示几乎所有中文字符，而且它是向下兼容 GBK 的。换句话说，用 GB18030 去读 GBK 文件，没问题；但用 GBK 去读 GB18030 文件，就可能丢字。如果你不确定源文件到底是哪种，直接统一用GetEncoding("GB18030")是最稳的选择。

4.2 转换后中文正常，但英文和数字旁边多了一个“?”

这个症状我一开始碰到还以为是文件里原来就有的东西，后来才发现问题出在编码转换器遇到无法映射的字符时的默认替代行为。当你用某种编码读文件时，如果遇到该编码无法表示的字符（比如 GBK 里没有某个特殊符号，或者编码声明与实际内容不符），.NET 会把那个位置替换成一个默认的替代字符——通常就是“?”。

排查思路：随便取一个出问题的文件，先用十六进制编辑器看一下原始字节，再对比转换后的字节，看看多出来的“?”在哪些位置。如果“?”出现的规律和某些特殊字符（比如€、™）对得上，那说明源文件其实不是纯中文 ANSI，里面混了其他编码的字符。这时候你得先确认这些文件的真实编码，再决定读的时候用什么编码。在脚本层面，你可以显式指定替换策略：

$ansiEncoding = [System.Text.Encoding]::GetEncoding( "GBK", [System.Text.EncoderFallback]::ExceptionFallback, [System.Text.DecoderFallback]::ExceptionFallback )

这样设置之后，一旦遇到无法解码的字节，会直接抛出异常提示你，而不是静默地替换成“?”。

4.3 PowerShell 脚本执行时提示“因为在此系统上禁止运行脚本”

Win11 默认的 PowerShell 执行策略是Restricted，只允许运行单个命令，不允许执行.ps1脚本文件。这时候你直接执行脚本文件会报错。

解决方法有几个：

1. 临时开放当前会话的执行策略（只对当前窗口有效，关掉就恢复）：

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

2. 用-ExecutionPolicy Bypass参数直接启动 PowerShell：

powershell -ExecutionPolicy Bypass -File "D:\Script\convert.ps1"

3. 如果你是 Win11 系统自带终端（Windows Terminal），也可以在配置文件里把默认执行策略改宽。

提示：Set-ExecutionPolicy改的是系统级的执行策略，改完记得用Get-ExecutionPolicy检查确认。如果你只是临时用一下，用-Scope Process就够了，别动全局。

4.4 文件被占用或者无权限写入，怎么处理

如果你的目标文件夹在系统目录，或者有一个程序正好打开了某个文件（比如数据库服务正在读一个.sql文件），WriteAllText就会抛 “UnauthorizedAccessException” 或 “IOException”。

处理方式有两个维度：

一是权限维度，用管理员身份运行 PowerShell，或者给当前用户添加目标文件夹的“修改”权限。

二是文件占用维度，脚本里加一层容错，遇到占用就跳过并记录日志：

try { [System.IO.File]::WriteAllText($filePath, $contentText, $utf8Encoding) Write-Host "Converted: $filePath" } catch { Write-Warning "Failed: $filePath - $($_.Exception.Message)" }

4.5 超大文件转换时内存飙升怎么办

前面说过的ReadAllText会把整个文件读入内存，如果碰到一个几百 MB 的超大文件，内存占用会非常难看。遇到这种极端场景，用流式读写的思路更稳。

简单的实现思路：用StreamReader按块读取，再用StreamWriter按块写入。你可以把整个脚本里的核心转换部分替换成：

$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() }

这里有个注意事项：用ReadLine+WriteLine的方式会保证行尾统一为当前系统的换行符。如果你的源文件是 Linux 风格的LF换行，转完后可能变成 Windows 风格的CRLF，内容不变，格式变了。要是你特别在意这个，可以考虑用StreamReader.ReadBlock配合缓冲区原样复制，不过常规场景下这种差异基本无感。

4.6 常见问题速查表

5. 从脚本到工具：如何把这套逻辑固化成日常可用的命令

5.1 保存成 .ps1 脚本文件

最直接的固化方式，就是把上面通用版脚本保存成一个.ps1文件，比如命名为Convert-ToUtf8.ps1。这样以后要用的时候，直接打开 PowerShell 执行一遍即可。如果你连打开 PowerShell 都嫌麻烦，可以做一个.bat文件来调起它。

比如你的脚本放在D:\Scripts\Convert-ToUtf8.ps1，在同一个目录下建一个run_convert.bat，内容如下：

@echo off powershell -ExecutionPolicy Bypass -File "D:\Scripts\Convert-ToUtf8.ps1" pause

这样双击.bat文件就能执行转换。脚本里的目标路径改一次就行，下次有同样需求直接双击。

5.2 把脚本设计得更通用：传参而不是改代码

上面这种做法有一个缺点：每次目标路径变了，你得改脚本内容。如果你经常需要处理不同文件夹，更合理的做法是把脚本变成一个“带参数的函数”。

在 PowerShell 里这很容易实现，脚本开头定义参数：

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" }

然后调用方式就变成：

.\Convert-ToUtf8.ps1 -TargetDir "D:\NewProject" -Filter "*.sql" -Recurse

这样你就不用每次编辑脚本了，路径、扩展名、是否递归都通过参数控制。甚至可以在.bat文件里用%1包装成“拖拽文件夹到批处理图标上就能转换”的效果：

@echo off powershell -ExecutionPolicy Bypass -File "D:\Scripts\Convert-ToUtf8.ps1" -TargetDir "%1" pause

把文件夹拖到这个批处理文件上，它就会自动读取%1这个路径，直接开转。我这两年处理外部交付的项目文件，都是这么干的，效率提升非常明显。

5.3 什么情况下你需要额外注意源文件的编码识别

脚本是无脑的，但真实文件系统是混乱的。你可能会遇到一个文件夹里既有 ANSI 文件，又有本来已经是 UTF-8 的文件。你又想只把 ANSI 的转换掉，不碰已经是 UTF-8 的那些，怎么办？

方法一：转换前检测文件是否包含非法 UTF-8 序列。思路是用 UTF-8 编码去读取文件，如果抛出异常，说明它大概率不是 UTF-8：

function 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)的第二个参数$true表示启用严格校验，遇到非法字节就抛异常。实际用的时候，先把所有文件过一遍这个函数，把返回$false的文件收集起来再批量转换。

方法二：直接全量统一转换。如果你的应用场景能接受“所有文件都变成 UTF-8”，那就无所谓了，反正 UTF-8 文件再转一遍 UTF-8 也不会坏。这种方法省事，唯一的风险是文件里如果有其他特殊编码（比如 UTF-16），你拿 ANSI 去读就会读错，然后写回之后文件就真的坏了。所以我的建议还是：如果文件夹来源复杂，先用方法一筛一遍。

5.4 与 Win11 自带功能的时间线：为什么不用记事本批量处理

有人可能会问，Win11 的记事本不是已经能识别各种编码了吗？确实，新版记事本在打开文件时能自动识别编码，右下角状态栏还能显示当前编码，甚至另存为时能选择“UTF-8 with BOM”“UTF-8”“UTF-16 LE”等选项。但这里的关键是：记事本没有批量处理能力，它一次只能打开一个文件。对上百个文件来说，打开一个、转换一个、保存一个、关掉一个，这个流程重复一百遍，任何正常人都受不了。

命令行方案的真正价值是“一次性处理”，而且你把脚本写好了以后，它就是一件顺手拈来的工具，不需要每次重新思考。

6. 实际体会与尽可能少走的弯路

最后想聊两句，不扯技术，纯经验。

做这类批量转换，最忌讳的就是上来就动手。我第一次给别人处理项目文件的时候，没做备份也没验证，直接跑脚本，结果把一个本来就好的 UTF-8 文件用 ANSI 读了一遍，写完直接报废，最后用了半天时间去还原。从那以后我给自己定了一个铁律：凡是批量操作，第一件事永远是备份；第二件事永远是先拿两三个文件做小范围测试；确认没问题了，再全量执行。

另外，源文件的编码识别不能想当然。很多工具显示“ANSI”其实指的是“系统当前默认 ANSI 代码页”，简体中文系统上是 GBK，繁体系统上可能是 BIG5，如果你把这些文件拿到一个日文系统的 Win11 上去跑，同样是“ANSI”，读出来的内容完全不一样。所以如果你的工作环境涉及到其他语言版本的 Windows，或者文件可能来自不同地区的同事，写脚本时尽量用明确的编码名（GB18030、Big5、Shift_JIS），不要依赖“Default”这种模糊概念。

这套脚本我现在还用着，每隔一段时间就会因为不同需求加一点小功能，比如支持把编码信息输出到一个日志文件、支持把转换结果统计汇总。本质上它已经不是一个“一次性脚本”，而是一个不断积累的小工具箱。你只要把基础版本跑通，后续按需扩展，它会越来越顺手。希望这篇文章能让你少走几步弯路，直接把这件事一次做对。