Переносимость локали UTF-8 (и ssh)


8

Я провожу много времени 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захожу на Linux-машину с моего Mac, и она пересылает все мои 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 (если он определяет utf8 вместо UTF-8) до BSD, может быть проблема.
AB

Ответы:


0

Это интересный вопрос, но я думаю, что там может быть неправильное представление о том, как устанавливаются переменные. Когда инициируется сеанс безопасной оболочки ( ssh remotehost), на другом конце происходит создание новой оболочки с отдельной средой. Это причудливый способ сказать, что сервер запускает новую оболочку. Эта новая оболочка может быть настроена с тем же языковым стандартом, что и исходная локальная оболочка.

Например

Geee: ~
$ echo `locale | grep LANG` ::` date`
LANG = en_US.UTF-8 :: Понедельник, 3 декабря 07:04:00 CET 2012

$ ssh flode
flode: ~
$ echo `locale | grep LANG` ::` date`
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

Точно так же вам придется настроить окружение на удаленной оболочке, чтобы сделать то же самое. Конечно, другие оболочки читают различные файлы запуска, такие как ~ / .zprofile для оболочки Z.

Я подозревал, что заблуждение заключается в том, что локальные переменные (настройки) никоим образом не пересылаются. Удаленная оболочка имеет свои настройки. Чтобы вывести список доступных языков на удаленном хосте, будь то минималистичная оболочка BusyBox или полноценная ОС GNU, используйте localeкоманду с -aпереключателем (как отмечено в вопросе). Любая из напечатанных строк может использоваться в качестве настройки локали для этой среды.

Что касается первого вопроса, локаль по умолчанию, с которой начинается любая оболочка, обычно настраивается в центральном месте, например / etc / profile. Большинство логинов читают этот файл при запуске.


2
Локальные вещи определенно передаются. /etc/ssh_configна каждой машине, на которую я когда-либо смотрел, определяет это LANGи LC_*отправляется на все хосты по умолчанию, и ssh -vпоказывает несколько строк вроде debug1: Sending env LC_ALL = en_GB.UTF-8. Конечно, если профиль оболочки на другом конце впоследствии переопределяет это, это другое дело - но на некоторых моих машинах это не так
kine

PS: я обновил свой оригинальный пост, возможно, с лучшей иллюстрацией того, на что я ссылаюсь
kine

По общему признанию я никогда не видел это. Машины, на которые вы ссылаетесь, Debian? Возможно, это объяснит механизм пересылки по ssh. Я все еще думаю, что названия локалей должны точно совпадать, потому что локаль не должна быть достаточно умной, чтобы понять это. Причина, по которой строки отличаются, заключается в том, что библиотека C отличается для машин на базе BSD и GNU / Linux. Они не знают друг о друге. Но, возможно, я слишком скептически отношусь, и в программе локали есть способ настроить это автоматически.
Ярослав Рахматуллин

Это та часть, в которой мне было любопытно - sshпереадресация носит случайный характер, это просто контекст того, почему мой язык настроен таким, какой он есть. Я просто не знаю, как определить, что на самом деле делает оболочка на другом конце - я обычно не получаю ошибок при попытке установить языковой стандарт (хотя иногда это происходит на встроенных устройствах), и ввод / вывод текста в Unicode выглядит как работать нормально (?), но используемая локаль явно отсутствует в системе. Большинство устройств Linux, к которым я подключаюсь, основаны на Debian или Ubuntu, в то время как другие основаны на uClibc / BusyBox (сетевые устройства и т. Д.).
кин

0

Различается ли имя поддержки 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 Проблемы и Terminal в 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 #
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.