PowerShell中用gh api获取UTF-8 BOM文件出现损坏字符，如何解决？

问题背景 #

在Windows 11的PowerShell Core 7.2.6执行以下命令获取XML文件时：

gh api -H "Accept: application/vnd.github.raw+text" repos/zippy1981/CodeFirstBetter/contents/Zippysoft.CodeFirst.AD.Importer/Zippysoft_CodeFirst_AD_Importer.csproj | Out-File Zippysoft_CodeFirst_AD_Importer.csproj

得到的文件存在4个疑似损坏的BOM字符，导致dotnet无法解析；添加-Encoding utf8BOM参数后，会额外增加真实BOM，问题仍未解决。

解决方案 #

方法1：使用原生重定向绕开PowerShell管道编码处理 #

直接用CMD风格的重定向符>写入文件，PowerShell Core会直接保留gh api返回的原始字节，避免编码转换带来的问题：

gh api -H "Accept: application/vnd.github.raw+text" repos/zippy1981/CodeFirstBetter/contents/Zippysoft.CodeFirst.AD.Importer/Zippysoft_CodeFirst_AD_Importer.csproj > Zippysoft_CodeFirst_AD_Importer.csproj

方法2：通过字节流模式写入文件 #

如果需要使用管道，用Set-Content的-AsByteStream参数直接处理原始字节，跳过PowerShell的字符串编码步骤：

gh api -H "Accept: application/vnd.github.raw+text" repos/zippy1981/CodeFirstBetter/contents/Zippysoft.CodeFirst.AD.Importer/Zippysoft_CodeFirst_AD_Importer.csproj | Set-Content Zippysoft_CodeFirst_AD_Importer.csproj -AsByteStream

方法3：修复已生成的损坏文件 #

如果已经得到了带损坏字符的文件，可以直接截取掉开头的4个字符，再重新写入：

$content = Get-Content Zippysoft_CodeFirst_AD_Importer.csproj -Raw
$content.Substring(4) | Set-Content Zippysoft_CodeFirst_AD_Importer.csproj -Encoding utf8NoBOM

原命令失效原因 #

Out-File会将管道中的内容先转换为PowerShell字符串，再按指定编码写入文件。gh api返回的损坏字节经过字符串解析后变成了可见的异常字符，即使指定utf8BOM编码，也会在保留这些损坏字符的基础上额外添加BOM，导致文件无法被dotnet正常解析。

内容的提问来源于stack exchange，提问作者Justin Dearing