UTF-8ロケールの移植性（およびssh）

私は多くの時間sshをさまざまなマシンに費やしていますが、それらはすべて異なります（一部は埋め込まれている、一部はLinuxを実行している、一部はBSDを実行している、など）。ただし、自分のローカルマシンではOS Xを使用しています。これには、もちろんBSDベースのユーザーランドがあります。これらのマシンの私のロケールは、利用可能なオプションの1つである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ベースのシステムと同じ動作が見られますか？）

興味深い質問ですが、変数の設定方法について誤解があると思います。セキュアシェルセッションが開始されると（ssh remotehost）、反対側で発生するのは、別の環境での新しいシェルのインスタンス化です。これは、サーバーが新しいシェルを起動するという言い方の空想です。その新しいシェルは、元のローカルシェルと同じロケールで構成されている場合とされていない場合があります。

例えば

geee：〜
$ echo `ロケール| grep LANG` ::`日付 `
LANG = en_US.UTF-8 :: Mon Dec 3 07:04:00 CET 2012

$ ssh flode
群れ：〜
$ echo `ロケール| grep LANG` ::`日付 `
LANG = nb_NO.UTF-8 LANGUAGE = nb_NO.UTF-8 :: ma。03.デス 06:59:33 +0100 2012

これを示すために、〜/ .bash_profileファイルに次の行を追加して、ノルウェー語のリモートシェルにロケールを設定します。

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

同様に、同じことを行うには、リモートシェルで環境を設定する必要があります。もちろん、他のシェルはZシェルの〜/ .zprofileなどの異なる起動ファイルを読み取ります。

私が疑った誤解は、ローカル変数（設定）は決して転送されないということです。リモートシェルには独自の設定があります。最小限のBusyBoxシェルでも本格的なGNU OSでも、リモートホストで使用可能な言語を一覧表示するにlocaleは、-aスイッチでコマンドを使用します（質問に記載されています）。印刷された行は、その環境のロケール設定として使用できます。

最初の質問と同様に、シェルが開始するデフォルトのロケールは通常、/ etc / profileなどの中央の場所で構成されます。ほとんどのログインシェルは、起動時にこのファイルを読み取ります。

次のコマンドについても、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のライオンのSSH UTF-8の問題の修正とすることができますOS Xライオンのターミナルをリモートマシンにåäöを記述しないでください）。

別の解決策はこれです：

# 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 #