LINUX.ORG.RU

не работает setfont -v cyr-sun16 -m cp1251_to_uni

 , ,


0

1

У меня Slackware, системная кодировка по умолчанию ISO-8859-1 (append=" vt.default_utf8=0" в lilo.conf).

В целом систему я специально не русифицировал, поэтому если файл на русском, то

$ cat in.txt

выдает кракозябры. Но, я помню, что когда разбирался с проблемой русификации, то понял схему, как выводить на консоль файлы, созданные в винде (то есть в кодировке cp1251). Идея очень простая - берется юникод шрифт cyr-sun16 и загружается таблица преобразования из юникода в cp1251. Раньше как я понимаю это делалось с помощью трюков с mapscrn, а теперь setfont может загружать таблицу преобразования сам. В сухом остатке: после вызова

$ setfont -v cyr-sun16 -m cp1251_to_uni

Loading symbolic screen map from file /usr/share/kbd/consoletrans/cp1251_to_uni.trans

Loading 256-char 8x16 font from /usr/share/kbd/consolefonts/cyr-sun16.psfu.gz

Loading Unicode mapping table...

можно было спокойно набрать в консоли

$ cat in.txt

и получить текст в кириллице. теперь вместо этого вылезают просто квадратики.

я в бешенстве. точно помню, что раньше работало. это ведь голый линукс, без иксов. какого хрена сломалось? может есть идеи?


Сперва ответ на незаданный вопрос, к ситуации, когда шрифт консоли соответствует кодировке:

$ cat in.txt | iconv -f cp1251

Другой вариант — использовать luit.

Про заданный вопрос отпишусь позднее, извините.

bormant ★★★★★
()

Slackware 14.1, консоль без фреймбуфера.

# export LANG=ru_RU.ISO-8859-5
# setfont cyr-sun16 -m cp1251_to_uni
# cat utf8.txt | iconv -f utf8 -t cp1251
Привет!

# export LANG=ru_RU.ISO-8859-1
# setfont cyr-sun16 -m cp1251_to_uni
# cat utf8.txt | iconv -f utf8 -t cp1251
Привет!

У меня ошибка ваша не воспроизводится. Могобыть файлик ваш все-таки не в cp1251, проверите?

bormant ★★★★★
()
# echo -e "\xcf\xf0\xe8\xe2\xe5\xf2\x21"
Привет!

Это в cp1251, соответственно, картинка при setfont cyr-sun16 -m cp1251_to_uni. А у вас оно что выводит?

bormant ★★★★★
()
Ответ на: комментарий от bormant

спасибо за помощь, рад, что я не глючу и этот рецепт раньше работал, раз у вас тоже работает.

файл точно в cp1251, я проверил. запустил последовательность ваших команд - вывело 5 белых квадратиков на черном фоне и восклицательный знак.

я подозреваю, что у меня по какой-то причине не работает конвертационная часть, -m cp1251_to_uni, так как когда я вызываю просто

$ setfont -v cyr-sun16

файлы в utf-8 выводятся правильно, а файлы в cp1251 - белыми квадратиками. а когда вызываю

$ setfont -v cyr-sun16 -m cp1251_to_uni

ничего не меняется, все по старому - utf правильно, а cp1251 опять белыми квадратиками, как и ваша команда с echo.

похоже это какой-то внутренний глюк моей системы. может быть после того, как я один раз, в качестве эксперимента, перевел систему на utf-8 (поставив append=" vt.default_utf8=1" в lilo.conf), она теперь не может полноценно вернуться к обычной кодировке ISO, хоть я уже и вернул старые настройки и 1000 раз перезагрузился? либо за 2 года накопилось глюков и надо переустановить систему...

nemec
() автор топика
Ответ на: комментарий от nemec

файлы в utf-8 выводятся правильно

а вот это явное свидетельство того, что консоль юникодная, в utf-8.

На всякий случай вопрос, выполнять от рута
# lilo
после изменений в /etc/lilo.conf не забываете?

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 1)

Варианты с однобайтовыми локалями:

/etc/lilo.conf
append = " vt.default_utf8=0"

/etc/profile.d/lang.sh	/etc/rc.d/rc.font
LANG=en_US.ISO8859-1	setfont -v cyr-sun16 -m 8859-1_to_uni
LANG=en_US.cp437	setfont -v cyr-sun16 -m cp437_to_uni

LANG=ru_RU.ISO8859-5	setfont -v cyr-sun16 -m 8859-5_to_uni
LANG=ru_RU.koi8-r	setfont -v cyr-sun16 -m koi8-r_to_uni
LANG=ru_RU.cp1251	setfont -v cyr-sun16 -m cp1251_to_uni
LANG=ru_RU.cp866	setfont -v cyr-sun16 -m cp866_to_uni

# lilo

Обращаю внимание, в iso-8859-1 русских символов нет, вызов locale будет материться на ru_RU.ISO8859-1.

Должны быть установлены пакеты glibc, glibc-i18n, kbd.

ps. Посмотрите, не вписаны куда-либо вызовы unicode_start и(или) unicode_stop.
Посмотреть на юникодность текущей консоли, если правильно путаю, можно по

# stty -a | grep iutf8
" iutf8 " — юникодная, " -iutf8 " — однобайтовая.

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 5)

Еще можно для определения юникодности глянуть на

# less /usr/share/kbd/consoletrans/utflist
полистать до CYRILLIC ... или даже раньше, если в колонке символов видны двухсимвольные последовательности — однобайтовая, если односимвольные — юникодная.

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 1)
Ответ на: комментарий от bormant

пролистал /usr/share/kbd/consoletrans/utflist

0401   <D0><81>   CYRILLIC CAPITAL LETTER IO
0402   <D0><82>   CYRILLIC CAPITAL LETTER DJE (Serbocroatian)
0403   <D0><83>   CYRILLIC CAPITAL LETTER GJE (Macedonian)
$ stty -a | grep iutf8
-iuclc -ixany -imaxbel -iutf8

то есть получается, что вроде однобайтовая.

после изменений lilo.conf вызвать lilo не забываю.

не очень понял комментарий о том, что в iso-8859-1 русских символов нет. как я понимаю теорию работы команды setfont cyr-sun16 -m cp1251_to_uni, ей вроде без разницы, какая установлена локаль. она просто получает на вход от echo или cat коды символов (которые будут в диапазоне > 127), с помощью таблицы /usr/share/kbd/consoletrans/cp1251_to_uni.trans преобразует эти коды в коды utf8 и выводит их на печать с помощью шрифта cyr-sun16.

насчет glibc вы меня озадачили. как я понимаю, проверка осуществляется с помощью команды

$/sbin/ldconfig | grep glibc
так? при таком вызове ничего не находится. если я вызываю
$/sbin/ldconfig | grep libc
то находится огромное количество строк типа такого
        libADM_smjs.so (libc6,x86-64) => /usr/lib64/libADM_smjs.so
        libADM_render_qt4.so (libc6,x86-64) => /usr/lib64/libADM_render_qt4.so
        libADM_render_gtk.so (libc6,x86-64) => /usr/lib64/libADM_render_gtk.so
        libADM_render_cli.so (libc6,x86-64) => /usr/lib64/libADM_render_cli.so
        libADM_coreUI.so (libc6,x86-64) => /usr/lib64/libADM_coreUI.so
как я понял из гугла, libc6 - это аналог glibc. так?

что меня заинтересовало, это результат вызова

$ locate glibc
/var/log/removed_scripts/glibc-solibs-2.13-x86_64-4-upgraded-2013-09-07,04:29:13
/var/log/removed_scripts/glibc-zoneinfo-2.13-noarch-4-upgraded-2013-09-07,04:33:19
/var/log/removed_scripts/glibc-2.13-x86_64-4-upgraded-2013-09-07,04:32:25
/var/log/removed_packages/glibc-profile-2.13-x86_64-4-upgraded-2013-09-07,04:33:09
/var/log/removed_packages/glibc-solibs-2.13-x86_64-4-upgraded-2013-09-07,04:29:13
/var/log/removed_packages/glibc-i18n-2.13-x86_64-4-upgraded-2013-09-07,04:32:53
/var/log/removed_packages/glibc-zoneinfo-2.13-noarch-4-upgraded-2013-09-07,04:33:19
/var/log/removed_packages/glibc-2.13-x86_64-4-upgraded-2013-09-07,04:32:25
/var/log/packages/glibc-i18n-2.13-x86_64-6_slack13.37
/var/log/packages/glibc-zoneinfo-2013b-noarch-1_slack13.37
/var/log/packages/glibc-solibs-2.13-x86_64-6_slack13.37
/var/log/packages/glibc-profile-2.13-x86_64-6_slack13.37
/var/log/packages/glibc-2.13-x86_64-6_slack13.37
...
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/plugin/include/config/glibc-stdint.h
/usr/lib64/glib-2.0/include/glibconfig.h
/usr/lib64/glib/include/glibconfig.h

видимо 2013-09-07 я запустил какой-то upgrade, который обновил пакет glibc-i18n. может быть такое, что апгрейд обновил часть пакетов до новой версии libc6, а другую часть пакетов нет и в результате перестала работать конвертация символов?

поиск kbd даёт

$ /sbin/ldconfig -p | grep kbd 
        libxfce4kbd-private.so.5 (libc6,x86-64) => /usr/lib64/libxfce4kbd-private.so.5
        libxfce4kbd-private.so (libc6,x86-64) => /usr/lib64/libxfce4kbd-private.so

то есть (как я понимаю) kbd установлен.

вроде ответил на все ваши вопросы?

п.с. огромное спасибо, что нянчитесь со мной)

nemec
() автор топика
Ответ на: комментарий от nemec

Поиск установленных пакетов в слаке:
ls -1 /var/log/packages/ | egrep ШАБЛОН

ashot ★★★★
()
Ответ на: комментарий от nemec

Наличие установленных пакетов в Slackware проверяют по наличию соответствующего файла в /var/log/packages (или /var/adm/packages, /var/adm — уже давно симлинк на /var/log):

$ ls /var/adm/packages/{kbd,glibc}-*
/var/adm/packages/glibc-2.17-x86_64-10_slack14.1
/var/adm/packages/glibc-i18n-2.17-x86_64-10_slack14.1
/var/adm/packages/glibc-solibs-2.17-x86_64-10_slack14.1
/var/adm/packages/glibc-zoneinfo-2014j-noarch-1
/var/adm/packages/kbd-1.15.3-x86_64-2

Ок, судя по выводу stty -a и отображению utflist консоль в однобайтовом режиме.

Теперь пару слов про setfont. Загружаемые шрифты для текстовых режимов консоли обычно содержат 256 глифов (растровых изображений символов), могут содержать до 512 глифов, в этом случае для выбор первого или второго 256-элементного набора осуществляется битом яркости. В текстовых режимах глифы загружались в знакогенератор видеокарты.

Шрифт может содержать таблицу соответствия глифов символам (юникодным codepoint-ам), например, для символов дефиса, минуса, en-dash, em-dash назначить единый глиф «дефис» и т.п., с целью увеличения количества охваченных шрифтом символов.

Шрифт может содержать глифы в разных последовательностях. Например, шрифтs Cyr_a8x* содержат глифы согласно cp866 (она же альтернативная кириллическая кодировка). Её особенность, если помните, в том, что символы псевдографики расположены в ней в позициях 0xB0-0xDF, для которых видеодаптер аппаратно дублирует 8-ю вертикальную линию (если не отключить), таким образом, при знакоместе 9 точек шириной и символах в 8 точек шириной по-прежнему можно отображать непрерывные горизонтальные линии.

Когда использовалась кодировка символов локали, отличная от кодировки символов видеоадаптера, отдельно загружалась таблица преобразования, раньше при помощи mapscrn, теперь это умеет делать setfont с ключом -m. Для локали ru_RU.koi8-r шрифты Cyr_a8x* нужно грузить с указанием преобразования koi2alt:

setfont -v Cyr_a8x16 -m koi2alt
Если теперь вы выводите что-либо на терминал, например, строку в koi8r «Привет», выводимые коды символов преобразуются ИЗ koi8-r В cp866 и в видеопамять пишутся коды символов в cp866. То есть, echo "Привет" вместо
f0 d2 c9 d7 c5 d4
в видеопамять запишет (не считая атрибутов)
8f e0 a8 a2 a5

Если в кодировке назначения нет символа, пишется символ заполнитель (знак вопроса, квадратик или что там назначено при загрузке шрифта).

Насколько понимаю, фреймбуферные варианты в части перекодирования вывода «на железо» копируют поведение текстовых режимов, кроме знакоместа, которое в этом случае по горизонтали 8 точек на символ вместо 9 (именно это учитывают консольные шрифты Terminus для фреймбуфера с суффиксом «v», а раньше «f»).

Теперь проверочный вариант:

# (grep '^\s*#\|^\s*$' /etc/lilo.conf /etc/rc.d/rc.font /etc/profile.d/lang.sh | grep 'append\|vga\|setfont\|LANG')
/etc/lilo.conf:append = " vt.default_utf8=0"
/etc/lilo.conf:vga = normal
/etc/rc.d/rc.font:setfont -v cyr-sun16 -m 8859-1_to_uni
/etc/profile.d/lang.sh:export LANG=en_US.ISO8859-1

# showconsolefont
# setfont cyr-sun16 -m cp1251_to_uni
# showconsolefont  # обращаю внимание, позиции символов не изменялись!
# cat cp1251.txt
Привет!
# echo -e "\xcf\xf0\xe8\xe2\xe5\xf2\x21"
Привет!

bormant ★★★★★
()
Ответ на: комментарий от nemec

В продолжение прошлого примера:

# setfont Cyr_a8x16 -m cp1251_to_uni
# showconsolefont  # позиции символов изменились, соответствуют cp866, но
# echo -e "\xcf\xf0\xe8\xe2\xe5\xf2\x21"
Привет!

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 1)
20 июля 2015 г.
Ответ на: комментарий от bormant

похожая проблема

у меня tinycore и почти такая же проблема, когда пишу в терминале возникают вопросики, но после отправки они преобразуются в русские буквы, из доп проблем, если писать текст, то между буквами ещё и пробелы появляются попробовал сделать setfont и так и эдак, но пока безуспешно, у меня груб и кажется не 2, попробовал туда vt.default, ничего не изменилось

oeai
()

а всё потому, что нужно было использовать православный koi8

anonymous
()
Ответ на: похожая проблема от oeai

после отправки они преобразуются в русские буквы

Значит клавиатура работает как надо

между буквами пробелы появляются

Клавиатура в UTF8 отдает по паре байт на символ, а консоль в однобайтном режиме отображает каждый байт как символ

Было б неплохо узнать версию ядра — в современных консоль изначально в UTF8, и дистрибутива.

в терминале

Вы точно про консоль/текстовый vt, а не про графический терминал, вроде rxvt? Обсуждаемое к графическим терминалам отношения не имеет.

bormant ★★★★★
()
Ответ на: комментарий от bormant

tinycore 6.3

ядро 3.16.6, вроде как сам дистр именно эту версию plusCore позиционирует с поддержкой прочих языков. консоль не графическая. пробовал setfont по всякому и скачивал другие шрифты - не показывает в промте буквы. Поправлюсь для ясности, что после enter они высвечиваются по русски, соответственнои файлы utf8 отображаются.

oeai
()
Ответ на: комментарий от bormant

вероятные решения

Как я понимаю вариантов не так уж и много

1. Перекомпилить stty чтобы было iutf8 2. Найти однобайтовую раскладку 3. Поставить luit 4. Найти какую-то трансляцию типа -iutf8_to_iutf8?

Альтернативно - сменить дистр на типа Пупса (PuppyRus) или Magos

oeai
()
Ответ на: tinycore 6.3 от oeai

после enter они высвечиваются по русски, соответственно и файлы utf8 отображаются.

А вот это уже больше похоже на собранный без поддержки UTF8 readline, кашу в .inputrc или что-то в таком роде.

Надо смотреть на дистрибутив, но такая возможность ранее августа у меня вряд ли случится. Возможно кто-то еще сможет посоветовать что-либо полезное.

bormant ★★★★★
()
Ответ на: комментарий от bormant

поковыряю мб тоже

readline .inputrc попробую поискать, что можно там изменить, спасибо =)

oeai
()
Ответ на: комментарий от bormant

en_US.UTF-8 locale

сгенерил сабж помимо ru_RU.UTF-8 и сразу появились буквы в mcedit + nano, в промте и vi по-прежнему вопросы, но это уже решает часть проблемы.

oeai
()
Ответ на: комментарий от bormant

busybox, kernel

в конфигах bb не было поставлено поддержки utf-8, либо сам пересоберу, либо апдейта подожду мб сделают, в ядро тоже вставил поддержку utf-8, скоро буду тестить, но в целом мой случай решён.

oeai
()
Ответ на: busybox, kernel от oeai

Вот и отлично.

С другой стороны, может ну его, utf8 на тех системах, на которые ориентирован Tiny?

Ведь от юникодности консоли, по большому счёту, зависят только имена на родных линуксу ФС, всё остальное, в том числе поддерживаемые иксами кодировки, зависимости от кодировки консоли не имеют вовсе.

bormant ★★★★★
()
Ответ на: комментарий от bormant

kernel mc emacs\uemacs\nano

у меня один старый ноут, но он вообще-то работает, мне из него нужна писчая машинка, сейчас он серьёзно не понимает флэшку на 8гиг и выкидывает кренделя при загрузке, поэтому я пытаюсь облегчить даже инитрд до минимума. а на остальных системах utf-8 и без него просто текста не видать.

oeai
()
Ответ на: kernel mc emacs\uemacs\nano от oeai

на остальных системах utf-8 и без него просто текста не видать

$ iconv -f utf8 text.txt > text_.txt
$ $EDITOR text_.txt
$ iconv -f koi8-r -t utf8 text_.txt > text.txt

либо воспользоваться редактором, умеющим перекодировку самостоятельно, коих вполне достаточно.

bormant ★★★★★
()
Ответ на: kernel mc emacs\uemacs\nano от oeai

старый ноут

можно озвучить характеристики?

На старый ноут можно поставить что-то постарше, будет комфортно не только в консольке, но и с иксами. На P-III 800 MHz со 128 Mb оперативки Slackware-12.2 с KDE-3 можно было вполне приемлемо себя чувствовать, а с XFCE и подавно, не говоря уже про легкие WM.

облегчить даже инитрд до минимума

С kernel-generic-smp в initrd обычно не требуется ничего кроме драйвера коневой ФС и его зависимостей (например, для ext4 это ext4.ko, jbd2.ko, mbcache.ko). Обычно — это из-за, возможно, необходимого дополнительно драйвера контроллера, если его нет в ядре.

bormant ★★★★★
()
Последнее исправление: bormant (всего исправлений: 2)
Ответ на: комментарий от bormant

p2-366 64mb

не стал заморачиваться с ядром, добил туда поддержку нтфс, обрезал емакс до минимума (после загрузки 56МБ RAM), теперь можно писать файлы на любой машине. Ноут флэшку определял через раз в этом его основная проблема, как только начинал читать с неё - подвисал, пришлось на сиди его перевести, а чтобы он с него грузился > загрузка с дискетки через plop. По сути он умеет работать на Xvesa, но там проблема с переключением языка, а на Xorg он начинает задумываться и сразу нужно 128+ памяти, у меня сейчас стоит 256 из другого п3-800, вот там у меня вообще дебиан etch наверное стоял или стоит и всё нормально. Просто задача - печатать текст, 800 камень греется, 366 - нет. https://yadi.sk/d/84GLM8-7iE7c4 - мало ли захочется поглядеть, тут исошник.

oeai
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.