UTF-8语言环境可移植性（和ssh）

我花了很多时间ssh在各种机器上，它们都是不同的（有些是嵌入式的，有些是运行Linux的，有些是运行BSD的，等等）。但是，在我自己的本地计算机上，我使用OS X，它当然具有基于BSD的用户区。这些机器上的我的语言环境设置为en_GB.UTF-8，这是可用的选项之一：

% echo `sw_vers`
ProductName: Mac OS X ProductVersion: 10.8.2 BuildVersion: 12C60
% locale -a | grep -i 'en_gb.utf'
en_GB.UTF-8

我使用的一些功能更强大的Linux系统似乎具有等效的选项，但是我注意到在Linux上，名称略有不同：

% lsb_release -d
Description: Debian GNU/Linux 6.0.3 (squeeze)
% locale -a | grep -i 'en_gb.utf' 
en_GB.utf8

这让我感到奇怪：当我ssh从Mac进入Linux机器时，它LC_*使用后缀'UTF-8' 转发了我所有的变量，那台Linux机器是否还明白要求什么？还是只是回到其他语言环境？

编辑：这是我所指的示例：

% ssh -v odin
...
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_ALL = en_GB.UTF-8
debug1: Sending env LC_COLLATE = en_GB.UTF-8
debug1: Sending env LC_CTYPE = en_GB.UTF-8
debug1: Sending env LC_MESSAGES = en_GB.UTF-8
debug1: Sending env LC_MONETARY = en_GB.UTF-8
debug1: Sending env LC_NUMERIC = en_GB.UTF-8
debug1: Sending env LC_TIME = en_GB.UTF-8
debug1: Sending env LANG = en_GB.UTF-8
odin:~ % locale | tail -1  # locale is set to .UTF-8 without error...
LC_ALL=en_GB.UTF-8
odin:~ % locale -a | grep 'en_GB.UTF-8'  # ... even though .UTF-8 isn't an option
odin:~ %

在这两种情况下，其行为背后的机制是什么，它是否依赖于任何特定的设置（例如，我是否会在基于BusyBox的系统上看到与基于GNU的系统相同的行为）？

— 坚
source

那里的解释：superuser.com/questions/999133/…（来自grawity的答案）。因此，从BSD到Linux，都没有问题。从Linux（如果它定义utf8而不是UTF-8）到BSD，可能存在问题。

— AB

Answers:

这是一个有趣的问题，但我认为其中可能存在关于如何设置变量的误解。当启动安全外壳会话（ssh remotehost）时，另一端发生的事情是使用单独的环境实例化新外壳。这是服务器启动一个新外壳的一种奇特的说法。该新Shell可能配置或未配置与原始本地Shell相同的语言环境。

例如

geee：〜
$ echo`locale | grep LANG` ::`date`
LANG = zh_CN.UTF-8 :: 2012年12月3日星期一12:30

$ ssh flode
弗洛德：〜
$ echo`locale | grep LANG` ::`date`
LANG = nb_NO.UTF-8语言= nb_NO.UTF-8 :: ma。03. des。2012年06:59:33 +0100

为了证明这一点，我通过在〜/ .bash_profile文件中添加以下行，在挪威语的远程shell上设置了语言环境：

export     LANG=nb_NO.UTF-8
export LANGUAGE=nb_NO.UTF-8
export   LC_ALL=nb_NO.UTF-8

同样，您必须在远程Shell上设置环境才能执行此操作。当然，其他外壳程序会读取不同的启动文件，例如Z外壳程序的〜/ .zprofile。

我怀疑的误解在于，本地变量（设置）根本无法转发。远程外壳具有自己的设置。为了列出远程主机上的可用语言，无论是简约的BusyBox外壳还是成熟的GNU OS，请locale在-a开关中使用命令（如问题中所述）。任何打印行都可以用作该环境的语言环境设置。

对于第一个问题，任何Shell都以其开头的默认语言环境通常在/ etc / profile之类的中央位置进行配置。大多数登录Shell在启动时都会读取此文件。

— ЯрославРахматуллин
source

语言环境的东西肯定是转发的。/etc/ssh_config每一台机器，我曾经看着定义上LANG，并LC_*默认发送给所有主机，并ssh -v揭示了几条线象debug1: Sending env LC_ALL = en_GB.UTF-8。当然，如果另一端的shell配置文件随后覆盖了那，那是另一回事-但是在我的某些机器上不是这种情况

— kine 2012年

PS：我已经用可能是我所指的更好的插图更新了我的原始帖子

— kine 2012年

诚然，我从未见过。您所指的机器，Debian？也许这将解释ssh env转发机制。我仍然认为语言环境名称必须完全匹配，因为语言环境不够聪明，无法弄清楚。字符串不同的原因是因为基于BSD和GNU / Linux的计算机的C库不同。他们彼此不认识。但是也许我太怀疑了，语言环境程序可以自动调整它。

— ЯрославРахматуллин

那是我很好奇的部分- ssh转发的东西是偶然的，这只是为什么我的语言环境被设置成这样的背景。我只是不知道如何确定另一端的外壳实际上在做什么–我通常不会在尝试设置语言环境时遇到错误（尽管我有时在嵌入式设备上也是如此），并且Unicode文本输入/显示似乎工作正常（？），但系统上显然不存在我使用的语言环境。我连接的大多数Linux设备都是基于Debian或Ubuntu的，而其他Linux设备则是基于uClibc / BusyBox的（网络设备，＆c。）。

— kine 2012年

对于以下命令，UTF-8支持的名称在不同系统上是否也略有不同？

LC_ALL='' locale charmap  # UTF-8 (on Mac OS X 10.6.8)

如果遇到奇怪的语言环境相关的问题，它可以帮助告诉SSH客户端不发送那些LC_*被注释掉的变量SendEnv LANG LC_*中/etc/ssh_config（参见，例如，固定的Mac OS X Lion中的SSH UTF-8的问题和OS X Lion中的终端：可以不要在远程计算机上写åäö）。

另一个解决方法是：

# from: http://mod16.org/hurfdurf/?p=189
tjac wrote:
Actually the real problem that's causing this is that Mac OS 10.7 sets totally 
non-standard locale values, at least when you tweak some of the formats in
SysPrefs/Language&Text as I did.

If you type "locale" on your Mac terminal you should see pretty much the same as on 
other Unices (e.g. lots of en_US.UTF-8s if you prefer US English), but you don't. 
If these garbled settings get transferred to other Unix hosts by the SendEnv option 
they naturally do not know what's going on.

So if you want to fix it cleanly to allow for sshing to all kinds of remote hosts,
including those with older character sets, put the following lines in your 
~/.bash_profile on your Mac client machine.

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Monday, September 12, 2011 at 22:54 #

— 卡莉
source