装完 KB5132061 之后，以前能正常运行的已签名 PowerShell 脚本，突然提示签名验证失败？先说结论：多半是脚本的文本编码有问题，被更新后更严格的校验拦住了。微软为此提供了一个修复工具，咱们按“先扫描、再转换、最后重新签名”的顺序处理。
微软在 2026 年 11 月 10 日为 Windows 11 推送了 KB5132061，对 PowerShell 的签名验证和签名过程做了更严格、更精确的安全检查。受影响最多的，是含有畸形 UTF-8 数据的脚本，或者被 Windows 用错误编码解读的文件，所以开发者和管理员在签名或运行原来没问题的脚本时可能碰壁。想了解这次更新的整体内容，可以看 Windows 11 KB5132061 十一月更新。
签名验证为什么会失败
PowerShell 靠数字签名确认脚本没被改动、来自可信发布者。更新后，Windows 在验证和签名时对编码的要求更严，以前能用替代字符“凑合”读出来的畸形 UTF-8 数据，现在会直接读取失败。常见的情形有三种：
- 脚本里含有无效的 UTF-8 字节；
- 没有字节顺序标记（BOM）的 UTF-8 文件，被按系统代码页来解读；
- 原本保存为 Shift-JIS 等编码的脚本，被误当成 UTF-8 读取。
需要提醒的是，并非所有签名失败都是这次更新造成的，文件可能真的被改过，或者签名证书本身就不可信。所以别一上来就断定是编码问题。
常见症状
- Get-AuthenticodeSignature 对原来已签名的脚本报告 NotSigned；
- Set-AuthenticodeSignature 返回 UnknownError；
- PowerShell 提示“No mapping for the Unicode character exists in the target multi-byte code page”；
- 在启用了“企业应用控制”（App Control for Business）的设备上，受影响的脚本可能以受限语言模式（ConstrainedLanguage）运行。
光凭这些现象还不能确定就是编码问题，微软建议先扫描受影响的文件，再决定怎么修。
第一步：下载微软的修复脚本
微软提供了一个叫 Repair-SignedPowerShellUtf8.ps1 的工具，用来识别并修复这类编码问题。请从微软官方支持页面获取脚本内容，完整保存为同名文件。然后在 FullLanguage 模式的 Windows PowerShell 5.1 中运行，并遵守所在组织的执行策略和应用控制规则，千万别为了图方便而关掉安全策略。
第二步：先用 Scan 模式扫描
在改动或替换任何脚本之前，先用扫描模式，它只检查文件，不会改动它们。在放着工具的目录下打开 PowerShell，运行：
.\Repair-SignedPowerShellUtf8.ps1 -Mode Scan -Path C:\Scripts -Recurse | Format-Table Path, Issue, SignatureStatus, Action -Wrap
请把 C:\Scripts 换成您存放脚本的实际文件夹。扫描结果会给出可能的编码问题、当前签名状态和建议操作，其中几个关键词的含义是：
- CodePageTextReadAsUtf8：特定语言的文本（比如 Shift-JIS）可能被当成 UTF-8 读取；
- Utf8WithoutBom：系统代码页和无 BOM 的 UTF-8 文本可能不匹配；
- MalformedUtf8：被当作 UTF-8 的文件里有无效的 UTF-8 数据。
如果扫描结果是 None，就别因为状态显示 NotSigned 去硬修编码，应该去排查证书、签名等其他可能。
第三步：转换为带 BOM 的 UTF-8
想要一劳永逸，微软建议把受影响的脚本转成有效的、带字节顺序标记（BOM）的 UTF-8，检查内容后重新签名：
.\Repair-SignedPowerShellUtf8.ps1 -Mode ConvertToUtf8Bom -Path C:\Scripts\Deploy.ps1请把路径换成受影响脚本的位置。工具会另存一份以 .utf8bom.ps1 结尾的副本，不会覆盖原文件，转换后的副本里旧签名会被清除。如果脚本原本使用特定的源编码，需要指定代码页。比如 Shift-JIS 的代码页是 932：
.\Repair-SignedPowerShellUtf8.ps1 -Mode ConvertToUtf8Bom -Path C:\Scripts\Deploy.ps1 -SourceCodePage 932转换后，请打开新文件仔细核对命令、特殊字符和注释，确认没有变样再继续。
第四步：重新签名并验证
假设您已批准使用的证书保存在 $cert 变量里，运行：
Set-AuthenticodeSignature -FilePath C:\Scripts\Deploy.utf8bom.ps1 -Certificate $cert再检查签名：
Get-AuthenticodeSignature -FilePath C:\Scripts\Deploy.utf8bom.ps1 | Format-List Status, StatusMessage确认状态为有效（Valid）后，再放到其他设备上运行之前，请先测试一遍。
来不及重新签名：临时修复模式
如果暂时没法重新签名，工具还提供一种临时修复模式，针对某些特定的编码问题：
.\Repair-SignedPowerShellUtf8.ps1 -Mode Repair -Path C:\Scripts\Deploy.ps1它会生成一份单独的副本，并尽量保留原有的签名。不过只适用于部分编码情形，不保证每次成功。只有 SignatureStatus 显示 Valid 时才能部署，并且部署前一定要自己检查、测试。
小结
这次 PowerShell 签名验证的变化，是有意为之的安全加固，不是普通的功能故障：Windows 现在会拒绝被改动过或畸形的 UTF-8 数据。遇到问题的朋友，先扫描、认清是哪种编码毛病，再按微软建议转成带 BOM 的 UTF-8 并重新签名，这是最稳的长期办法。更多官方资料可参考 微软 PowerShell 文档。
常见问题（FAQ）
脚本显示 NotSigned，就一定是编码问题吗？
不一定。文件被改动或证书不可信也会这样，所以要先用 Scan 模式确认。
修复工具会覆盖我的原文件吗？
不会。它会另存带 .utf8bom.ps1 后缀的副本，原文件保持不变。
转换后为什么签名没了？
内容编码变了，旧签名就失效了，所以会被清除。核对内容无误后需要重新签名。
可以直接关掉执行策略绕过吗？
不建议。请遵守所在组织的执行策略和应用控制，别为了省事关闭安全防护。
Shift-JIS 脚本怎么转换？
转换时加上 -SourceCodePage 932 参数，指明源编码的代码页即可。