Win10 Terminal中Telnet远程Linux与原生WSL2运行iftop显示差异的原因及解决方法咨询

嘿，这个终端显示乱码的问题我之前也踩过坑，咱们来好好聊聊背后的原因和可行的解决办法：

(1) 差异产生的核心原因 #

这两种场景的终端通信机制完全不一样，导致了显示效果的区别：

• WSL2本地运行场景：Win10 Terminal直接和WSL的shell通过**PTY（伪终端）**交互，Win10 Terminal本身是现代终端模拟器，支持UTF-8编码、VT系列终端控制码以及盒状绘图字符。而且WSL会自动识别终端类型，把TERM环境变量设置成适配的值（比如xterm-256color或windows-ansi），iftop拿到这个正确的终端类型后，会输出对应终端能正确解析的界面字符，自然显示正常。
• Telnet远程连接场景：Windows自带的telnet.exe是个非常老旧的客户端，它不支持现代终端的核心特性：
  • 不会正确传递终端类型信息给远程Linux，哪怕你手动设置TERM=xterm，telnet客户端本身也没法处理iftop输出的盒状绘图字符（这类字符属于Unicode或VT100扩展字符集）；
  • 对ANSI终端控制码的解析有缺陷，iftop依赖这些控制码来刷新屏幕、绘制动态界面，telnet.exe无法正确解析，最终导致显示乱码。

(2) 解决Telnet远程显示乱码的方法 #

这里给你几个实用的方案，按推荐程度排序：

• 替换为SSH连接（最推荐）：放弃老旧的telnet，直接在Win10 Terminal里用WSL的ssh命令连接远程Ubuntu：ssh 10.22.4.47。SSH是现代远程连接协议，能完美传递终端类型、UTF-8编码和控制码，iftop的显示效果会和WSL本地运行完全一致。
• 更换Telnet客户端：如果一定要用telnet，可以安装支持现代终端特性的客户端，比如Git Bash自带的telnet、PuTTY等，这些工具能正确处理iftop的输出字符和控制码。
• 调整远程端终端参数（应急方案）：如果只能用Windows自带的telnet.exe，可以在远程Ubuntu上用更基础的终端类型启动iftop：TERM=vt100 sudo iftop。vt100是更老旧但兼容性更强的终端类型，虽然会丢失部分颜色和排版细节，但至少不会乱码。
• 配置Win10 Terminal的Telnet Profile：在Win10 Terminal中创建自定义Telnet配置文件，设置编码为UTF-8，并在启动命令中指定环境变量：cmd.exe /c "set TERM=xterm-256color && telnet 10.22.4.47"。不过这个方法对自带telnet的改善有限，仅作为备选。

补充说明 #

[Figure 1] 准备连接或启动Linux环境
[Figure 2] 准备执行sudo iftop
[Figure 3] Telnet连接与WSL本地运行的iftop显示对比，Telnet端出现乱码

备注：内容来源于stack exchange，提问作者Jimm Chen