Debian 12与macOS的UTF-8文件名兼容性问题排查咨询
首先得给你吃个定心丸：你的文件系统里的文件名本身是没问题的——毕竟SMB挂载、Web服务都能正确识别，本地创建的带重音字符的文件夹也正常，问题根源出在不同终端环境下的编码解析和渲染差异上，咱们一步步拆解：
一、问题原因拆解
物理控制台乱码：字体/字符集渲染限制
Debian的纯文本控制台（tty）和GUI终端不一样，它默认的字体可能只支持有限的UTF-8字符集，甚至部分老字体只覆盖ASCII范围。虽然你系统的locale设置是en_US.UTF-8，但控制台没法渲染那些重音字符，就会显示成奇怪的符号。这是纯文本控制台的常见局限，和文件本身的编码无关。SSH连接的转义字符：locale传递冲突
macOS Terminal默认会把本地的LC_CTYPE=UTF-8传递给Debian服务器，但Debian的LC_ALL是空的，这就导致终端在解析文件名时，出现了“本地locale”和“服务器locale”的冲突，所以才会显示一堆转义字符（比如$'\303\251'其实就是UTF-8中é的字节表示）。关掉“Set locale environment variables on startup”后，终端会直接用Debian自身的en_US.UTF-8来解析，自然就正常了。SMB/Web服务正常：绕开了终端渲染层
SMB协议本身就对UTF-8文件名做了标准化处理，Web服务则是直接读取文件系统的UTF-8元数据，然后在支持完整UTF-8的浏览器里展示，完全不涉及终端的渲染逻辑，所以不会有问题。
二、解决建议
针对物理控制台乱码
更换支持UTF-8的控制台字体：
先安装一款全UTF-8支持的控制台字体，比如fonts-unifont：sudo apt update && sudo apt install fonts-unifont然后运行配置工具：
sudo dpkg-reconfigure console-setup在弹出的界面里，选择“UTF-8”作为字符集，再挑选一款支持扩展字符的字体（比如Unifont），重启控制台后应该就能正常显示重音字符了。
检查控制台字符集配置：
打开/etc/default/console-setup，确认CHARMAP的值是UTF-8，如果是ISO-8859-1这类旧字符集，改成UTF-8后重启系统生效。
针对locale配置（避免SSH连接的编码冲突）
永久设置LC_ALL：
编辑Debian的~/.bashrc或者/etc/profile（全局生效），添加一行：export LC_ALL=en_US.UTF-8保存后执行
source ~/.bashrc（或重新登录），确保所有会话都继承这个设置，这样就算macOS传递过来locale，也会被Debian的LC_ALL覆盖，避免冲突。验证文件编码正确性：
用ls -b命令查看文件名的原始字节，比如élément应该显示为\xc3\xa9l\xc3\xa9ment，这说明文件名确实是标准UTF-8编码，进一步确认问题出在终端渲染而非文件本身。
三、潜在风险说明
只要文件系统的文件名是标准UTF-8编码，后续的服务（Web、SMB、程序读写）都不会有任何问题。物理控制台的显示问题只是视觉上的，如果你需要在物理控制台上操作这些文件，可以用通配符（比如ls *ment）或者通过inode号来访问（先用ls -i查看inode，再用find . -inum <inode号> -exec mv {} 新文件名 \;重命名）。
备注：内容来源于stack exchange，提问作者Cirrocumulus
