От здесь-строки (<<<
) синтаксис, который Вы использовали, я предполагаю, что Ваша оболочка bash
, таким образом, можно также использовать строку с оставленными из обратной косой черты символами ($''
):
sftp -o PasswordAuthentication=no user@host <<< $'lcd /home\n cd /myhome\n get file'
Портативная альтернатива является здесь-документом:
sftp -o PasswordAuthentication=no user@host <<END
lcd /home
cd /myhome
get file
END
Если я понимаю Ваш вопрос затем, я верю elinks
поддерживает эту функцию. Используя UTF-8-demo.txt, из которого @michas, обеспеченный в его ответе, вот является снимком экрана elinks
просматривание той страницы.
Вызов elinks
как так:
$ elinks http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
Вот снимок экрана терминального выполнения elinks
:
Как альтернатива elinks
можно также использовать w3m
.
Можно вызвать w3m
как так:
$ w3m http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
Вот снимок экрана терминального выполнения w3m
:
Lynx также поддерживает эту возможность. Можно вызвать его как так:
Рысь $ http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt
Вот снимок экрана терминального выполнения lynx
:
Все на терминальном основанные браузеры, о которых я знаю, работают просто великолепно в рендеринге этих символов. Моя локаль установлена следующим образом:
$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=
Который вероятен проблема.
Для ручного тестирования возможностей терминала, можно использовать файл как UTF-8-demo.txt.
Действительно ли Ваш терминал в состоянии отобразить Ваши поля?
Если это может, Ваш браузер знает, что Ваш терминал может сделать так?
Иначе браузер будет выбирать безопасный вариант и эмулировать поля с помощью символов ASCII.
Из чего вывод locale
и echo $TERM
? - По всей вероятности Ваш браузер оценит тех для определения возможностей терминала.
locale
и $TERM
быть? Как Вы говорите браузеру, что терминал может отобразить UTF8?
– terdon♦
24.11.2013, 04:51
После получения некоторых подсказок здесь, кажется, что ответ - то, что рысь, elinks, и w3m, вся работа, если определение местоположение настроено правильно.
locale
показанный, что все было установлено на "POSIX".
export LC_ALL="en_US.UTF-8"
решенный проблема. Добавленный это к ~/.bashrc так, чтобы изменение сохранилось.
Спасибо люди!
LC_CTYPE
, Вы не должны смешивать с LC_ALL
. Вы не должны вставлять это .bashrc
, это испортит при использовании non-UTF-8 терминала. Обычно LC_CTYPE
установлен автоматически, общая причина его, которой не работа состоит в том, что некоторый пользовательский сценарий вслепую переопределяет его. При использовании PuTTY удостоверьтесь, что он настраивается, чтобы использовать UTF-8 и объявить это правильно.
– Gilles 'SO- stop being evil'
24.11.2013, 23:02
это - проблема набора символов. Если Ваш терминал находится в utf8 режиме, и рысь знает это, это просто работает. проверенный 30 секунд назад.
Данные ответы близки: настройки локали являются основой для каждой из программ (lynx, w3m, elinks), чтобы решить, как рендерить вещи.
Однако есть несколько моментов, вызывающих разногласия:
Поведение lynx зависит также от настройки locale_charset, например, в файле lynx.cfg
:
Описание
LOCALE_CHARSET
переопределяет CHARACTER_SET, если true, используя текущую локаль для поиска соответствующего MIME-имени и использования его в качестве кодовой таблицы.Он также изменяет значение по умолчанию для ASSUMED_CHARSET; он не отменяет эту настройку.
Обратите внимание, что хотя сам
nl_langinfo(CODESET)
стандартизован, возвращаемые значения и их связь со значением локали не стандартизованы. GNU libiconv, как правило, выдает полезные значения, но другие реализации не гарантируют этого.Значение по умолчанию
LOCALE_CHARSET
:FALSE
Упаковщики настраивают этот параметр; исходные тексты более консервативны в отношении настроек по умолчанию.
Отображение приведенных примеров с помощью lynx и w3m очень похоже. С другой стороны, если прокрутить файл вниз с помощью elinks, сразу же становится очевидной проблема с сочетанием символов, используемых в примере с тайским языком. Похоже, что elinks не справляется с этой проблемой:
Сравните с w3m:
и с lynx (используя ncursesw, конечно):
Это все текущие исполняемые файлы из Debian/testing.
Короче говоря, хотя разные браузеры могут отображать символы Юникода, как и просили, их возможности (и настраиваемость) отличаются.