UTF-8 로케일 이식성 및 ssh

나는 많은 시간 ssh을 다양한 기계에 썼다. 모든 기계는 다릅니다 (일부는 임베디드, 일부는 Linux, 일부는 BSD 등). 그러나 내 로컬 컴퓨터에서는 BSD를 기반으로 한 사용자 영역이있는 OS X를 사용합니다. 해당 컴퓨터의 내 로캘이 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

sshMac에서 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 기반 시스템에서와 동일한 동작을 볼 수 있습니까)?

— 키네
소스

거기에 대한 설명 : superuser.com/questions/999133/… (응답). 따라서 BSD에서 Linux로 문제가 없습니다. Linux (UTF-8 대신 utf8을 정의하는 경우)에서 BSD까지 문제가있을 수 있습니다.

— AB

답변:

흥미로운 질문이지만 변수 설정 방법에 대한 오해가있을 수 있습니다. 보안 셸 세션이 시작되면 ( ssh remotehost) 다른 쪽 끝에서 발생하는 상황은 별도의 환경에서 새 셸을 인스턴스화하는 것입니다. 서버가 새로운 쉘을 시작한다고 말하는 멋진 방법입니다. 새 셸은 원래 로컬 셸과 동일한 로캘로 구성되거나 구성되지 않을 수 있습니다.

예 :

geee : ~
$ echo`locale | grep LANG` ::`날짜`
LANG = ko_KR.UTF-8 :: 월요일 12 월 3 일 07:04:00 CET 2012

$ ssh flode
플로이드 : ~
$ echo`locale | 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과 같은 중앙 위치에 구성됩니다. 대부분의 로그인 쉘은 시작시이 파일을 읽습니다.

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

로케일은 확실히 전달됩니다. /etc/ssh_config내가 정의하는 검토 한 것으로 모든 컴퓨터에서 LANG와 LC_*기본적으로 모든 호스트로 전송하고, ssh -v같은 여러 줄을 보여준다 debug1: Sending env LC_ALL = en_GB.UTF-8. 물론, 다른 쪽 끝에있는 쉘 프로파일이 나중에 그것을 덮어 쓴다면, 그것은 또 다른 것입니다 – 그러나 내 컴퓨터의 일부에서는 그렇지 않습니다

— kine

추신 : 나는 내가 참조하고있는 더 나은 그림으로 원래 게시물을 업데이트했습니다

— kine

분명히 나는 이것을 본 적이 없다. 당신이 말하는 기계, 데비안? 아마도 이것은 ssh env-forwarding 메커니즘을 설명 할 것입니다. 나는 로케일이 이것을 알아낼만큼 똑똑하지 않기 때문에 로케일 이름이 정확하게 일치해야한다고 생각합니다. 문자열이 다른 이유는 C 라이브러리가 BSD 및 GNU / Linux 기반 시스템과 다르기 때문입니다. 그들은 서로에 대해 모른다. 그러나 아마도 너무 회의적이며 로케일 프로그램은 이것을 자동으로 조정하는 방법을 가지고 있습니다.

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

그것이 제가 궁금했던 부분입니다 – ssh전달하는 것은 우연입니다. 왜 내 로케일이 원래대로 설정되어 있는지에 대한 문맥 일뿐입니다. 나는 다른 쪽 끝의 쉘이 실제로 무엇을하고 있는지 결정하는 방법을 모른다 .- 일반적으로 로케일을 설정하려고 시도하는 동안 오류가 발생하지 않으며 (내장 임베디드 장치에서 수행하지만) 유니 코드 텍스트 입력 / 표시가 나타납니다. 정상적으로 작동합니까 (?), 사용중인 로케일이 분명히 시스템에 존재하지 않습니다. 내가 연결하는 대부분의 Linux 장치는 데비안 또는 우분투 기반이며 다른 장치는 uClibc / BusyBox 기반 (네트워크 어플라이언스 등)입니다.

— kine December

UTF-8 지원 이름은 다음 명령에서도 다른 시스템에서 약간 다른가요?

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

당신이 이상한 로케일 관련 문제가 발생하면, 그것은 그 보내지에 SSH 클라이언트에게 도움이 될 수 있습니다 LC_*주석에 의해 변수 SendEnv LANG LC_*에 /etc/ssh_config, 예를 들어, 참조 ( 맥 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 #

— 카를 리
소스