Tmux 边框显示为 xq 而不是线条？
我无法让 tmux 显示边框线。它们是用 x 和 q 创建的。它是一个 debian squeeze 服务器，区域设置设置为 en_US UTF8。我还尝试
# instructs tmux to expect UTF-8 sequences
setw -g utf8 on
set -g status-utf8 on
向 .tmux.conf 添加行。似乎没什么作用。我不确定这是否是区域设置问题。在其他服务器上可以正确显示，但在 debian 上则不能。我感谢您提供的任何提示！谢谢...
I'm having trouble getting tmux to display lines for borders. They are being created with x and q. It's a debian squeeze server and the locale is set to en_US UTF8. I also tried adding
# instructs tmux to expect UTF-8 sequences
setw -g utf8 on
set -g status-utf8 on
lines to .tmux.conf. Nothing seems to work. I'm not sure if it's a locale issue or not. It displays correctly on other servers, but not the debian. I appreciate any tips you could offer! Thanks...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
当连接到 Debian Squeeze 机器上运行的 tmux 时，我在 PuTTY 和 Windows 8 上遇到了同样的问题。即使在 PuTTY 中将字符集设置为 UTF-8（在“窗口”>“翻译”>“远程字符集”下的设置中），我也没有得到正确的线条图。
将远程字符集设置为“使用字体编码”对我来说很有效。
I had the same problem with PuTTY and Windows 8 when connecting to tmux running on a Debian Squeeze machine. Even when setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) I didn't get the correct line drawing.
Setting the Remote character set to "Use font encoding" did the trick for me.
您的终端模拟器与 tmux 使用的 terminfo 数据库条目（启动/附加到时由 TERM 环境变量命名的数据库条目）之间存在一些不匹配。 tmux 服务器）。
根据 VT100 用户指南，表 3-9：特殊图形字符，当“特殊图形选择“set”，
x用于绘制“垂直条”，q用于绘制“水平线 - 扫描 5”。在 terminfo 下，VT100 特殊图形字符作为备用字符集功能的一部分提供；请参阅 terminfo(5) 手册页。
可能（在您的 Debian 服务器上）有效的 terminfo 数据库条目表明 ACS 可用，但您的终端仿真器实际上并未响应指定的控制序列。
tmux CHANGES 文件表示某些终端模拟器（例如 Putty）在 UTF-8 模式下不遵守 ACS 控制序列。因此，tmux 1.4 进行了一项更改，当附加客户端指定它可以处理 UTF-8 时（即附加时，
-u<给出了 /code> 或 LC_ALL、LC_CTYPE 或 LANG 中存在UTF-8；utf8窗口选项是关于 tmux 应该期望的它运行的程序，而不是它可以发送到连接的客户端的程序）。Debian“squeeze”仅包含tmux 1.3，所以你的tmux 可能没有“首选 UTF-8 线条绘制”功能（除非它来自 backports 源）。
如果您无法修复终端模拟器，也无法升级到至少 tmux 1.4，那么您也许可以使用 tmux 的
terminal-overrides选项来取消设置 ACS 相关功能，以便 tmux 将回退到 ASCII 线条绘制。在您的.tmux.conf中（在 Debian 系统上）：There is some mismatch between your terminal emulator and the terminfo database entry being used by tmux (the one named by the TERM environment variable when you start/attach to a tmux server).
Per the VT100 User Guide, Table 3-9: Special Graphics Characters, when the “special graphics set” is selected,
xis used to draw the “Vertical bar” andqis used to draw “Horizontal line - Scan 5”.Under terminfo, the VT100 special graphics characters are available as a part of the Alternate Character Set functionality; see the “Line Graphics” section of the terminfo(5) man page.
Probably (on your Debian server) the effective terminfo database entry indicates that ACS is available, but your terminal emulator is not actually responding to the specified control sequences.
The tmux CHANGES file indicates that some terminal emulators (e.g. Putty) do not respect the ACS control sequences when they are in UTF-8 mode. Thus, tmux 1.4 has a change that makes it always use UTF-8 characters instead of ACS sequences when the attaching client specifies that it can handle UTF-8 (i.e. when attaching,
-uwas given orUTF-8is present in LC_ALL, LC_CTYPE or LANG; theutf8window option is about what tmux should expect from the programs it runs, not what it can send to the attached client).Debian “squeeze” only includes tmux 1.3, so your tmux probably does not have the “prefer UTF-8 line drawing” feature (unless it pulls from a backports source).
If you can not fix your terminal emulator nor upgrade to at least tmux 1.4, then you might be able to use tmux’s
terminal-overridesoption to unset the ACS-related capabilities so that tmux will fall back to ASCII line drawing. In your.tmux.conf(on the Debian system):尝试将字符集设置为“UTF-8”并在“窗口”->“使用Unicode线条绘制代码点”下设置“UTF-8”。在腻子设置中进行翻译。
Try setting the character set to "UTF-8" and "Use Unicode line drawing code points" under Window -> Translation in your putty settings.
在 Linux 12.04 机器上启动 tmux 时，我遇到了与 Putty 相同的问题。即使在 PuTTY 中将字符集设置为 UTF-8（在“窗口”>“翻译”>“远程字符集”下的设置中）也没有解决问题。
使用 -u 选项启动 tmux 就成功了（
tmux -u）I had the same problem with Putty when launching tmux on Linux 12.04 machine. Even setting the charset to UTF-8 in PuTTY (in the settings under Window > Translation > Remote character set) didn't solve the problem.
Launching tmux with -u option did the trick (
tmux -u)如果您打开了 Putty 0.73 或更高版本的设置，请展开“窗口”类别，然后选择“翻译”。选中“即使在 UTF-8 模式下也启用 VT100 线条绘制”：
If you have Putty 0.73 or higher open settings, expand Window category, then select Translation. Check 'Enable VT100 line drawing even in UTF-8 mode':
我尝试了各种建议，包括：
以上不起作用。对话框显示 qqqq... 和 xxxx 以及各种角字符。
更改所有对话框调用以包含 --ascii-lines 是一个选项，但它会涉及大量脚本更改。
最好的建议是将远程字符集更改为使用字体编码。
PuTTY 更改设置 -->窗口-->翻译-->远程字符集 -->使用字体编码
将所有其他 PuTTY 设置保留为默认值。
I ran thru the gamut of suggestions including:
Above did not work. Dialog displays showed qqqq... and xxxx with various corner characters.
Changing all dialog calls to include --ascii-lines was an option but it would involve a lot of script changes.
Best recommendation was to change the Remote Character Set to Use font encoding.
PuTTY Change Settings --> Window --> Translation --> Remote Character Set --> Use font encoding
Left all other PuTTY settings default.
我将 Putty 中的终端设置更改为 Latin-1，这似乎解决了问题。
I changed the setting in Putty for terminal to Latin-1 and that seemed to fix the problem.
如果您使用 KiTTY，Windows 下会有一个复选框 ->翻译选项卡，称为“允许以 UTF 格式绘制 ACS 线”。需要检查：
If you are using KiTTY there is a check box under Windows -> Translation tab, that is called "Allow ACS line drawing in UTF". It needs to be checked:
对我来说，问题是当我设置这个 Arch Linux 机器时，我忘记创建一个
locale.conf文件。下面的行修复了问题，替换为您自己的语言。我不需要重新启动。For me the issue was I forgot to make a
locale.conffile when I setup this Arch Linux box. Below line fixed the issue, substitute your own language. A reboot was not required for me.在 windows/putty 下，您使用的字体必须具有要显示的字符
将翻译“UTF-8”和“使用 Unicode 线条绘制代码点”和字体设置为“courier-new”，大多数问题都会消失
under windows/ putty the font you use has to have the characters for it to display
set translation "UTF-8" and "Use Unicode line drawing code points" and font to "courier-new" and most of those problems go away
看来字体选择是一个令人困惑的因素，即：
替代
垂直快递新常态的替代
It seems the font choice is a confusing factor here, to wit:
substitution
substitution for vertical