Какие-либо основанные на тексте веб-браузеры поддерживают unicode тянущие поле символы?

От здесь-строки (<<<) синтаксис, который Вы использовали, я предполагаю, что Ваша оболочка 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
3
24.11.2013, 02:21
5 ответов

elinks

Если я понимаю Ваш вопрос затем, я верю elinks поддерживает эту функцию. Используя UTF-8-demo.txt, из которого @michas, обеспеченный в его ответе, вот является снимком экрана elinks просматривание той страницы.

Пример

Вызов elinks как так:

$ elinks http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

Вот снимок экрана терминального выполнения elinks:

   ss of elinks

w3m

Как альтернатива elinks можно также использовать w3m.

Пример

Можно вызвать w3m как так:

$ w3m http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

Вот снимок экрана терминального выполнения w3m:

   ss of w3m

рысь

Lynx также поддерживает эту возможность. Можно вызвать его как так:

Рысь $ http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

Вот снимок экрана терминального выполнения lynx:

   ss of 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=

Который вероятен проблема.

Ссылки

2
27.01.2020, 21:16

Для ручного тестирования возможностей терминала, можно использовать файл как UTF-8-demo.txt.

Действительно ли Ваш терминал в состоянии отобразить Ваши поля?

Если это может, Ваш браузер знает, что Ваш терминал может сделать так?

Иначе браузер будет выбирать безопасный вариант и эмулировать поля с помощью символов ASCII.

Из чего вывод locale и echo $TERM? - По всей вероятности Ваш браузер оценит тех для определения возможностей терминала.

1
27.01.2020, 21:16
  • 1
    Охладите демонстрацию UTF, но как это на самом деле отвечает на вопрос? Что должно locale и $TERM быть? Как Вы говорите браузеру, что терминал может отобразить UTF8? –  terdon♦ 24.11.2013, 04:51
  • 2
    я пытался указать, что установка Вашей шпаклевки правильно является только половиной пути. Это файл UTF8 должен только удостовериться Ваш терминал, может отобразить символы UTF8 правильно. - Вторая часть говорит Вашему браузеру, что UTF-8 доступен, который, вероятно, определяется данными настройками. –  michas 24.11.2013, 07:16

После получения некоторых подсказок здесь, кажется, что ответ - то, что рысь, elinks, и w3m, вся работа, если определение местоположение настроено правильно.

locale

показанный, что все было установлено на "POSIX".

export LC_ALL="en_US.UTF-8"

решенный проблема. Добавленный это к ~/.bashrc так, чтобы изменение сохранилось.

Спасибо люди!

1
27.01.2020, 21:16
  • 1
    Также для кого-либо еще любят меня использующий ШПАКЛЕВКУ/И Т.Д. в Windows используйте шрифт DejaVu Sans Mono для лучших результатов. –  Cory J 24.11.2013, 06:51
  • 2
    Категория локали, которую необходимо установить, 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 секунд назад.

0
27.01.2020, 21:16

Данные ответы близки: настройки локали являются основой для каждой из программ (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 не справляется с этой проблемой:

enter image description here

Сравните с w3m:

enter image description here

и с lynx (используя ncursesw, конечно):

enter image description here

Это все текущие исполняемые файлы из Debian/testing.

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

1
27.01.2020, 21:16

Теги

Похожие вопросы