中文乱码的根本原因：编码链路上的断裂

很多人一遇到乱码就去改设置，改完发现还是不对，反复折腾。要真正做到SecureCRT中文乱码解决，得先理解乱码是怎么产生的。

SecureCRT相关配图

整个中文显示链路有三个环节：服务器端生成中文字符（由locale决定编码）→ SSH通道传输字节流 → SecureCRT终端解码并渲染到屏幕。任何一个环节的编码不一致，都会导致乱码。最常见的情况是：服务器用UTF-8输出，但SecureCRT的Session配置还停留在默认的ISO-8859-1，终端拿Latin字符集去解码中文字节，自然显示成乱码或问号。

另一个容易忽略的因素是字体。即使编码完全匹配，如果所选字体不包含中文字形（比如纯英文等宽字体Consolas），中文字符也会显示为方框或空白。所以排查乱码，要同时检查编码和字体两条线。

SecureCRT端的编码与字体配置

这是解决问题最直接的一步，操作路径如下（基于SecureCRT 9.x版本，8.x版本菜单位置相同）：

SecureCRT相关配图

第一步，修改Session编码。打开SecureCRT，在菜单栏选择 Options → Session Options → Terminal → Appearance 旁边的 Emulation 标签页，找不到的话直接进 Terminal 分类。关键设置在 Session Options → Terminal → Appearance 下方的 Character encoding（字符编码）下拉框，将其从默认值改为 UTF-8。如果你的服务器使用GBK编码，则选择 GBK/GB2312。

第二步，设置支持中文的字体。在同一个 Appearance 页面，点击字体设置按钮，推荐选择"新宋体""Microsoft YaHei Mono"或"Courier New"（Courier New在Windows中文环境下也能回退显示中文）。字号建议设为12pt或14pt，避免中文字符因过小而模糊。

第三步，点击OK保存，断开当前Session重新连接，观察中文是否正常显示。

如果你希望所有新建Session都默认使用UTF-8，可以通过 Options → Global Options → Default Session → Edit Default Settings，在同样的位置修改编码，这样后续新建的连接都会继承这个配置。

服务器端locale校验与修复

SecureCRT端改好了还是乱码？那问题大概率出在服务器端。SSH登录后执行以下命令检查：

SecureCRT相关配图

```bash locale ```

重点看 LANG 和 LC_ALL 两个变量。如果输出是 POSIX、C 或者空值，说明服务器没有配置中文locale，终端再怎么设置UTF-8也没用，因为服务器压根没在用UTF-8输出。

修复方法（以CentOS 7 / RHEL 7为例）：

```bash # 查看系统是否已安装中文locale locale -a | grep zh_CN

# 如果没有，安装中文语言包 sudo yum install glibc-common -y sudo localedef -i zh_CN -f UTF-8 zh_CN.UTF-8

# 设置系统默认locale echo 'LANG="zh_CN.UTF-8"' | sudo tee /etc/locale.conf

# 当前会话立即生效 export LANG=zh_CN.UTF-8 export LC_ALL=zh_CN.UTF-8 ```

Ubuntu/Debian系统则使用：

```bash sudo apt-get install locales sudo locale-gen zh_CN.UTF-8 sudo update-locale LANG=zh_CN.UTF-8 ```

修改后重新登录Session，再次执行 `locale` 确认 LANG 已变为 zh_CN.UTF-8。

两个实战故障场景的排查

场景一：cat查看文件正常，vim打开全是乱码。这说明cat是直接输出字节流、由SecureCRT解码，而vim有自己的内部编码判断。打开vim后执行 `:set fileencoding` 查看vim识别到的文件编码，如果显示latin1，说明vim猜错了。在 ~/.vimrc 中添加以下配置强制优先使用UTF-8解码：

```vim set encoding=utf-8 set fileencodings=utf-8,gbk,gb2312,latin1 ```

保存后重新用vim打开文件，中文应恢复正常。

场景二：SecureCRT连接跳板机后再SSH到目标机器，目标机器中文乱码，但直连目标机器正常。这是因为跳板机的locale环境变量通过SSH传递到了目标机器，覆盖了目标机器自身的设置。检查跳板机的 /etc/ssh/ssh_config 中是否有 `SendEnv LANG LC_*` 配置，同时检查目标机器的 /etc/ssh/sshd_config 中是否有 `AcceptEnv LANG LC_*`。如果跳板机locale是POSIX，它会把这个"错误"的值传过去。解决办法：要么统一跳板机的locale为UTF-8，要么在目标机器的 ~/.bashrc 中强制指定 `export LANG=zh_CN.UTF-8`，不依赖SSH传递的环境变量。

总结

SecureCRT中文乱码解决的核心思路就一句话：保证"服务器输出编码 = SecureCRT解码设置 = 字体支持中文"三者一致。优先检查Session的Character encoding是否为UTF-8，再用 `locale` 命令确认服务器端编码，最后排查字体和特殊场景（vim配置、跳板机传递等）。按这个顺序走一遍，绝大多数乱码问题都能定位。

如果你还没有安装SecureCRT，或者正在使用的版本较旧（低于8.x），建议前往官方下载页面获取最新版本，新版本在Unicode支持和终端渲染上都有明显改进，能从根源上减少编码兼容性问题。

相关阅读：SecureCRT中文乱码解决使用技巧，SecureCRT和Putty区别：从功能到体验