含Emoji文件名的文件在Git传输中乱码的原因与解决

Git 输出中出现反斜杠加数字或方框，往往不是文件在传输中损坏，而是路径转义或终端编码设置所致。在 Windows 环境下使用 Git 和 PowerShell 时，需先区分是 Git 的显示保护机制，还是终端无法渲染特定字符。只有确认工作区实际文件名已改变，才需要进行改名操作。

识别 Git 路径转义并调整配置

Git 默认启用 core.quotePath 配置，会在输出路径时对非 ASCII 字符进行转义，以防止特殊字符干扰命令行解析。这表现为文件名被双引号包裹，高位字节显示为八进制转义序列。

1. 对比开启与关闭转义的显示效果

在包含 Emoji 文件名（如 report_😀.txt）的仓库中，执行以下命令对比输出：

git -c core.quotePath=true ls-files
git -c core.quotePath=false ls-files

开启转义时，输出可能为 "report_\360\237\230\200.txt"；关闭后则直接显示 report_😀.txt。这种差异仅影响命令输出的可读性，不改变仓库中文件的实际存储名称。

左侧显示转义后的八进制序列，右侧直接显示Emoji文件名

2. 修改当前仓库配置

若希望默认直接显示原始字符，可在当前仓库执行：

git config --local core.quotePath false

该设置仅作用于当前仓库。需注意，即使关闭此选项，包含空格、双引号或控制字符的路径仍可能被转义或引用，因此不能将其视为完全关闭所有引用规则的手段。

排查终端编码与字体显示问题

若关闭路径转义后，Emoji 仍显示为方框或问号，需检查终端的输出编码及字体支持。字体缺失字形与字节解码错误是两类不同问题，单纯设置 UTF-8 无法补全缺失的字形。

1. 检查并设置 PowerShell 输出编码

在 Windows PowerShell 中，查看当前控制台输出编码：

[Console]::OutputEncoding.WebName

若需强制当前会话以 UTF-8 输出，可执行：

[Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false)

此设置仅影响当前会话的控制台显示，仍需终端模拟器（如 Windows Terminal）支持相应字体。不同版本的 PowerShell 对默认编码的处理存在差异，旧版控制台可能无法正确渲染所有 Emoji。

执行Console.OutputEncoding设置命令以确保终端正确输出UTF-8字符

2. 规范日志文件保存编码

当屏幕显示正常但保存为文本文件后出现乱码，通常是因为重定向输出时的编码不一致。Windows PowerShell 5.1 与 PowerShell 7 的默认行为不同。建议使用明确编码保存输出：

git -c core.quotePath=false ls-files | Out-File -Encoding utf8 paths.txt

使用支持 UTF-8 的编辑器打开生成的文件进行核对。注意 $OutputEncoding 主要影响管道传输给外部程序的文本编码，与 Out-File 保存文件的编码机制不同。

脚本处理与安全改名建议

在自动化脚本中，不应依赖人类可读的输出来解析文件名，因为引号和转义字符会导致解析错误。

1. 使用 NUL 分隔符读取路径

为确保脚本能准确获取包含特殊字符的文件名，应使用 -z 选项输出 NUL 字节分隔的数据：

git ls-files -z

调用方需按 NUL 字节分割记录，而非按行读取。这种方式避免了因文件名中包含换行符或特殊符号导致的解析偏差，是处理复杂文件名的标准做法。

使用-z参数输出NUL字节分隔的文件列表，适合脚本安全解析

2. 确认真实名称错误后的修复

若跨平台协作中确认文件名确实发生错误（如被替换为占位符），应先核对双方是否处于同一提交和分支。确认需改名后，使用 git mv 进行规范操作：

git mv -- "旧名称.txt" "report_😀.txt"

该命令会更新索引并标记为改名操作，随后需提交变更。避免直接通过文件系统重命名后强制添加，以免丢失 Git 的历史追踪信息。若目标环境不支持 Emoji，建议团队统一使用保守的 ASCII 命名规范。