WezTerm 终端乱码时如何排查 LANG 与 locale 环境变量【免费下载链接】weztermA GPU-accelerated cross-platform terminal emulator and multiplexer written by wez and implemented in Rust项目地址: https://gitcode.com/GitHub_Trending/we/wezterm当 WezTerm 终端里出现乱码——比如一个字符被拆成好几个乱码字符显示——官方 FAQdocs/faq.md给出的首要怀疑对象是LANG与 locale 环境变量。原理是终端传输的是字节流本身并不知道文本的编码unix 模型下由你通过 locale 环境变量告诉应用程序用什么 locale 去解释这条字节流而这些变量在默认环境下经常未设置或设成了无效值。WezTerm 始终只输出UTF-8编码的文本所以你的LANG和 locale 相关环境必须与之匹配。本文按先判断、再检查、后修正的顺序给出 FAQ 中描述的排查路径。先判断乱码是否由 locale 引起FAQ 给出了几种现象的区分方法修错方向会浪费不少时间一个字符的位置出现多个乱码字符大概率是 locale 环境变量有问题按本文继续排查。该有字符的位置显示为 unicode 替换字符、问号甚至空格这是字体回退font fallback问题不是 locale 问题参见 docs/config/fonts.md 中的 Troubleshooting Fonts 一节。只有某个应用如 zsh REPL里贴入的 Emoji 显示异常同样内容从脚本输出却正常FAQ 指出这类部分 Emoji 渲染不正确可能只是表象相似根因可能在应用侧对 Emoji 规格支持不足可尝试升级该应用。检查当前 locale 环境在 WezTerm 里打开的 shell 中查看env的输出确认LANG和各个LC_XXX变量当前是什么值——这也是 FAQ 要求你在提交 issue 时附带提供的信息env输出和xxdhexdump。然后用下面命令列出系统上实际可用的 locale确认你想设置的值确实存在locale -a注意两点文档示例用en_US.UTF-8但你需要从locale -a的列表里选择一个真实的 unicode locale如果你在 macOS 上使用 WezTerm升级到20200620-160318-e00b076c或更新的版本后WezTerm 会在启动时根据当时的 locale 设置自动为环境设置合理的LANG这一步在 macOS 上通常已经由 WezTerm 代劳。设置正确的 LANG 与 LC 变量确认当前值无效或缺失后为环境设置一个 unicode locale。FAQ 给出的示例en_US.UTF-8仅为文档示例值请按locale -a中实际存在的 unicode locale 替换export LANGen_US.UTF-8 # You dont strictly need this collation, but most technical people # probably want C collation for sane results export LC_COLLATEC如果你的环境里还有其他LC_XXX变量按 FAQ 的要求要么把它们从环境中移除要么把它们调整成使用 UTF-8 locale 的值——任何残留的非 UTF-8LC_XXX都会让环境回到不支持 UTF-8的状态。要让设置跨会话生效需要把export写入你的 shell rc 文件FAQ 在 zsh 一节同样建议把相关配置放进.zshrc。如果你通过 ssh 或 mux 连接协议登录远程主机FAQ 强调这套 locale 设置必须同时在你本地和远端系统上生效只改本地是不够的。使用 tmux 时的额外步骤如果你在 tmux 里看到 unicode 字符全部变成下划线FAQ 明确说明这是LANG/locale 问题的典型表现tmux 在认为环境不支持 UTF-8 时会用下划线替代 unicode 字形。修改环境后还有一个容易漏掉的点必须杀掉 tmux server 并重启它新环境才会生效。此外FAQ 建议先把输入/输出异常放在脱离 tmux 的环境里排查因为 tmux 自己还引入一层对LANG、TERM和 locale 敏感的输入/输出处理先排除其他变量。可选分支zsh 下粘贴或输入 unicode 仍有问题FAQ 指出 zsh 的行编辑器默认不支持组合字符序列combining character sequences。在确认LANG和 locale 已按上文配置正确之后在 zsh 中启用组合字符支持setopt COMBINING_CHARS把这行写进.zshrc使其始终生效。仍未解决时的下一步如果该有字符的位置显示的是替换字符、问号或空格说明问题在字体回退而非 locale在.wezterm.lua中用wezterm.font_with_fallback显式加入包含所需字形的字体并参考 docs/config/fonts.md 的 Troubleshooting Fonts 一节。如果确认是输入字节流本身的问题FAQ 建议用xxd观察按键实际产生的字节运行xxd按下出问题的键回车再按CTRL-D即可看到字节序列的十六进制转储。若以上排查后仍认为 WezTerm 发送的输入不正确向项目提交 issue 时需要附上xxd的 hexdump 和env的输出以便复现你的环境。【免费下载链接】weztermA GPU-accelerated cross-platform terminal emulator and multiplexer written by wez and implemented in Rust项目地址: https://gitcode.com/GitHub_Trending/we/wezterm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WezTerm 终端乱码时如何排查 LANG 与 locale 环境变量？
WezTerm 终端乱码时如何排查 LANG 与 locale 环境变量【免费下载链接】weztermA GPU-accelerated cross-platform terminal emulator and multiplexer written by wez and implemented in Rust项目地址: https://gitcode.com/GitHub_Trending/we/wezterm当 WezTerm 终端里出现乱码——比如一个字符被拆成好几个乱码字符显示——官方 FAQdocs/faq.md给出的首要怀疑对象是LANG与 locale 环境变量。原理是终端传输的是字节流本身并不知道文本的编码unix 模型下由你通过 locale 环境变量告诉应用程序用什么 locale 去解释这条字节流而这些变量在默认环境下经常未设置或设成了无效值。WezTerm 始终只输出UTF-8编码的文本所以你的LANG和 locale 相关环境必须与之匹配。本文按先判断、再检查、后修正的顺序给出 FAQ 中描述的排查路径。先判断乱码是否由 locale 引起FAQ 给出了几种现象的区分方法修错方向会浪费不少时间一个字符的位置出现多个乱码字符大概率是 locale 环境变量有问题按本文继续排查。该有字符的位置显示为 unicode 替换字符、问号甚至空格这是字体回退font fallback问题不是 locale 问题参见 docs/config/fonts.md 中的 Troubleshooting Fonts 一节。只有某个应用如 zsh REPL里贴入的 Emoji 显示异常同样内容从脚本输出却正常FAQ 指出这类部分 Emoji 渲染不正确可能只是表象相似根因可能在应用侧对 Emoji 规格支持不足可尝试升级该应用。检查当前 locale 环境在 WezTerm 里打开的 shell 中查看env的输出确认LANG和各个LC_XXX变量当前是什么值——这也是 FAQ 要求你在提交 issue 时附带提供的信息env输出和xxdhexdump。然后用下面命令列出系统上实际可用的 locale确认你想设置的值确实存在locale -a注意两点文档示例用en_US.UTF-8但你需要从locale -a的列表里选择一个真实的 unicode locale如果你在 macOS 上使用 WezTerm升级到20200620-160318-e00b076c或更新的版本后WezTerm 会在启动时根据当时的 locale 设置自动为环境设置合理的LANG这一步在 macOS 上通常已经由 WezTerm 代劳。设置正确的 LANG 与 LC 变量确认当前值无效或缺失后为环境设置一个 unicode locale。FAQ 给出的示例en_US.UTF-8仅为文档示例值请按locale -a中实际存在的 unicode locale 替换export LANGen_US.UTF-8 # You dont strictly need this collation, but most technical people # probably want C collation for sane results export LC_COLLATEC如果你的环境里还有其他LC_XXX变量按 FAQ 的要求要么把它们从环境中移除要么把它们调整成使用 UTF-8 locale 的值——任何残留的非 UTF-8LC_XXX都会让环境回到不支持 UTF-8的状态。要让设置跨会话生效需要把export写入你的 shell rc 文件FAQ 在 zsh 一节同样建议把相关配置放进.zshrc。如果你通过 ssh 或 mux 连接协议登录远程主机FAQ 强调这套 locale 设置必须同时在你本地和远端系统上生效只改本地是不够的。使用 tmux 时的额外步骤如果你在 tmux 里看到 unicode 字符全部变成下划线FAQ 明确说明这是LANG/locale 问题的典型表现tmux 在认为环境不支持 UTF-8 时会用下划线替代 unicode 字形。修改环境后还有一个容易漏掉的点必须杀掉 tmux server 并重启它新环境才会生效。此外FAQ 建议先把输入/输出异常放在脱离 tmux 的环境里排查因为 tmux 自己还引入一层对LANG、TERM和 locale 敏感的输入/输出处理先排除其他变量。可选分支zsh 下粘贴或输入 unicode 仍有问题FAQ 指出 zsh 的行编辑器默认不支持组合字符序列combining character sequences。在确认LANG和 locale 已按上文配置正确之后在 zsh 中启用组合字符支持setopt COMBINING_CHARS把这行写进.zshrc使其始终生效。仍未解决时的下一步如果该有字符的位置显示的是替换字符、问号或空格说明问题在字体回退而非 locale在.wezterm.lua中用wezterm.font_with_fallback显式加入包含所需字形的字体并参考 docs/config/fonts.md 的 Troubleshooting Fonts 一节。如果确认是输入字节流本身的问题FAQ 建议用xxd观察按键实际产生的字节运行xxd按下出问题的键回车再按CTRL-D即可看到字节序列的十六进制转储。若以上排查后仍认为 WezTerm 发送的输入不正确向项目提交 issue 时需要附上xxd的 hexdump 和env的输出以便复现你的环境。【免费下载链接】weztermA GPU-accelerated cross-platform terminal emulator and multiplexer written by wez and implemented in Rust项目地址: https://gitcode.com/GitHub_Trending/we/wezterm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考