кодировка linux в консоли
Как сменить locale в Debian или пишем кириллицей в консоли linux
Я знаю что кириллица в логах Linux – это самый страшный грех для айтишника, но иногда это просто необходимость. Одна из таких необходимостей возникает при создании централизованного хранения log-файлов различных операционных систем. Microsoft всегда в своих log`ах применяет кириллицу и поэтому если мы хотим получать log-файлы и от Win-серверов, то стоит смириться, что в log`ах будет кирилица.
Для того, чтобы эти логи нормально отображались нам и нужно явно указать locale в Debian, Ubuntu или какой Linux-дистрибутив Вы используете.
Чтобы добавить кириллицу, чтобы Linux сервер нормально отображал русские буквы, нужно объяснить ему, что необходимо работать в той же кодировке, что и Windows.
Для того, чтобы управлять локалью в Linux, необходим пакет locales, который должен быть у Вас установлен. В большинстве случаев пакет locales уже будет у Вас установлен, поэтому для проформы просто проверяем этот факт.
Посмотреть установленную locale linux можно командой:
Для ручного указания кодировке в Linux Mint, Debian или ubuntu нужно отредактировать конфигурационный файл /etc/locale.gen :
Команду sudo не нужна, если Вы зашли как суперпользователь. Это относится к Linux Mint и Ubuntu, так как Debian ничего не знает о команде sudo.
Стоит обратить внимание, что первые 2 символа (в нашем примере это ru) говорят нам о языке локализации (кириллица).
После этого переопределяем настройки locales командой:
Команда locale-gen позволяет запустить скрипт /etc/locale.gen и перечитывает все кодировки для консоли.
Чтобы увидеть кириллицу в консоли Linux, остается только перелогиниться.
Комментарии
Попробую применить ваши методы, не знаю, что из этого выйдет, но просмотрим.
Как я боролся с кодировками в консоли
В очередной раз запустив в Windows свой скрипт-информер для СамИздат-а и увидев в консоли «загадочные символы» я сказал себе: «Да уже сделай, наконец, себе нормальный кросс-платформенный логгинг!»
Об этом, и о том, как раскрасить вывод лога наподобие Django-вского в Win32 я попробую рассказать под хабра-катом (Всё ниженаписанное применимо к Python 2.x ветке)
Задача первая. Корректный вывод текста в консоль
Симптомы
До тех пор, пока мы не вносим каких-либо «поправок» в проинициализировавшуюся систему ввода-вывода и используем только оператор print с unicode строками, всё идёт более-менее нормально вне зависимости от ОС.
«Чудеса» начинаются дальше — если мы поменяли какие-либо кодировки (см. чуть дальше) или воспользовались модулем logging для вывода на экран. Вроде бы настроив ожидаемое поведение в Linux, в Windows получаешь «мусор» в utf-8. Начинаешь править под Win — вылезает 1251 в консоли…
Теоретический экскурс
Ищем решение
Очевидно, чтобы избавиться от всех этих проблем, надо как-то привести их к единообразию.
И вот тут начинается самое интересное:
Кроме того, как замечательно видно из примера, если в linux у нас везде utf-8, то в Windows — две разных кодировки — так называемая ANSI, она же cp1251, используемая для графической части и OEM, она же cp866, для вывода текста в консоли. OEM кодировка пришла к нам со времён DOS-а и, теоретически, может быть также перенастроена специальными командами, но на практике никто этого давно не делает.
До недавнего времени я пользовался распространённым способом исправить эту неприятность:
… и собрать всё вместе:
Задача вторая. Раскрашиваем вывод
Попробовав несколько из них, я, в итоге, воспользовался простейшим наследником StreamHandler, приведённом в одном из комментов на Stack Overflow и пока вполне доволен:
Однако, в Windows всё это работать, разумеется, отказалось. И если раньше можно было «включить» поддержку ansi-кодов в консоли добавлением «магического» ansi.dll из проекта symfony куда-то в недра системных папок винды, то, начиная (кажется) с Windows 7 данная возможность окончательно «выпилена» из системы. Да и заставлять юзера копировать какую-то dll в системную папку тоже как-то «не кошерно».
Снова обращаемся к гуглу и, снова, получаем несколько вариантов решения. Все варианты так или иначе сводятся к подмене вывода ANSI escape-последовательностей вызовом WinAPI для управления атрибутами консоли.
Побродив некоторое время по ссылкам, набрёл на проект colorama. Он как-то понравился мне больше остального. К плюсам именно этого проекта ст́оит отнести, что подменяется весь консольный вывод — можно выводить раскрашенный текст простым print u»\x1b[31;40mЧто-то красное на чёрном\x1b[0m» если вдруг захочется поизвращаться.
Сразу замечу, что текущая версия 0.1.18 содержит досадный баг, ломающий вывод unicode строк. Но простейшее решение я привёл там же при создании issue.
Собственно осталось объединить оба пожелания и начать пользоваться вместо традиционных «костылей»:
Дальше в своём проекте, в запускаемом файле пользуемся:
На этом всё. Из потенциальных доработок осталось проверить работоспособность под win64 python и, возможно, добаботать ColoredHandler чтобы проверял себя на isatty, как в более сложных примерах на том же StackOverflow.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Настройка языка и региональных стандартов в Ubuntu Server/Debian
В наших материалах тема региональных настроек Linux-систем ранее почти не поднималась. Подразумевалось, что система устанавливается читателями самостоятельно и все эти вопросы уже решены на стадии установки. Но бывают ситуации, когда нужно работать с уже готовой системой, например, VPS у зарубежного провайдера или в облачных системах типа Amazon или Azure. В этом случае появляется необходимость настроить систему для использования родного языка и привычных региональных настроек.
Это, в первую очередь, поддержка символов национального алфавита, кодовых страниц и раскладок клавиатуры, форматов чисел, а также настроек даты и времени. Если данные настройки не выполнить или выполнить неправильно, то имена файлов и содержимое документов с использованием символов отличных от стандартного латинского алфавита могут быть искажены или испорчены. Также масса проблем может возникнуть в дальнейшем, например, при переходе на локализованную систему, когда имена уже существующих файлов или ссылок на них могут оказаться неверными или вовсе недействительными.
Ниже на рисунке прекрасный пример того, что бывает, если на нелокализованный сервер скриптом были залиты файлы с именами, содержащими национальные символы, в данном случае кириллицу.
При этом сам скрипт, в данном случае CMS, функционирует нормально и при скачивании с сайта файлы имеют нормальные имена на кириллице, но с ними практически невозможно работать на сервере, так как непонятно, что это за файлы (вместо имен кубики), и нет возможности скачать их на Windows-систему. Переименовать файлы также нет возможности, так как сразу получим массу битых ссылок по всему сайту.
Поэтому, самым правильным решением будет сразу же настроить сервер на работу с нужной локализацией и снять целый пласт потенциальных проблем, тем более, что сделать это несложно.
Debian
Для правильного отображения символов национальных алфавитов в определенной кодировке в Linux-системах предназначены локали (locales), узнать какие локали уже установлены в системе можно командой:
Обычно установлена и используется английская локаль en_US.utf8, однако, если вы, например, приобрели VPS в Германии, может присутствовать только национальная локаль, в этом случае, кроме русской, также рекомендуется установить английскую локаль.
Для генерации и настройки локалей используйте команду:
Откроется псевдографическая утилита, которая предложит выбрать используемые локали, добавляем ru_RU.utf8
Затем укажите используемую по умолчанию локаль, тем самым установив язык системы:
Большинство «инструкций» в интернете на этом заканчиваются, но установить локаль недостаточно, нужно еще настроить консоль, т.е. ту среду ввода-вывода с которой вы взаимодействуете. Иначе вы увидите примерно такую картину:
Для настройки консоли запустите следующую утилиту:
Прежде всего зададим кодировку консоли, в современном Linux это UTF-8.
Затем используемые наборы символов, нам нужен комбинированный набор Latin; Slavic Cyrillic; Greek.
И используемый шрифт, здесь посоветовать что-то однозначно нельзя и следует исходить из личных предпочтений, в любом случае выбор можно всегда изменить, запустив утилиту повторно.
Ниже, чтобы облегчить вам выбор, представлены образцы шрифтов:
Остальные настройки, вроде размера шрифта и т.п. не представляют сложности и могут быть оставлены по умолчанию или выставлены в соответствии с собственными предпочтениями. Теперь можно выйти из системы и войти повторно или перезагрузить ее. После этого основным языком системы будет русский и символы кириллицы будут отображаться корректно.
Следующим шагом следует настроить клавиатуру:
Выбираем тип клавиатуры, по умолчанию это 105-клавишная международная, менять эту настройку без особой необходимости не следует.
Так как система изначально была установлена с локалью en_US, то нам предлагаются американские раскладки, выбираем Другая.
Затем выбираем сочетание клавиш для переключения раскладок и отвечаем еще на ряд вопросов, отвечать на который можете по своему усмотрению. Советуем не спешить, там есть интересные возможности, например, клавиша временного переключения между раскладками:
И устанавливаем текущий часовой пояс, после чего система автоматически переведет часы.
Ubuntu Server
В Ubuntu Server команда dpkg-reconfigure locales не имеет псевдографического интерфейса и при запуске настраивает уже сгенерированные локали. Поэтому придется нужные настройки выполнить вручную, прежде всего сгенерируем русскую локаль (здесь и далее обращаем внимание на регистр команд):
Затем зададим локаль по умолчанию:
После чего выполним их настройку:
Следующим шагом будет настройка консоли:
Здесь все настройки аналогичны Debian, выбираем кодировку, набор символов и настраиваем шрифты.
Теперь можно выйти и повторно войти в систему (или перезагрузиться), чтобы продолжить дальнейшую настройку на русском языке. Для полноценной локализации потребуется настроить клавиатуру:
Мы не будем подробно останавливаться на настройках, так как работа этой утилиты подробно описана выше, в разделе о Debian.
Временные зоны также настраиваются аналогично командой:
Как видим, локализация системы не представляет абсолютно никакой сложности и выполняется в считанные минуты, позволяя снять целый ряд потенциальных проблем, решить которые впоследствии будет гораздо труднее.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Ubuntu. Русификация консоли в 2016 году
Для меня было некоторым откровением узнать, что в 2016 году, в одном из крупных дистрибутивов GNU/Linux существуют проблемы с локализацией. А точнее, с локализацией текстовой консоли. Кто пользуется текстовой консолью в 2016 году? Не надо забывать, что есть множество дистрибутивов, базирующихся на Ubuntu и не все из них используют графическое окружение. Назову два примера: Ubuntu Server и Clonezilla.
Выглядит проблема так:
И присутствует в текущем релизе Ubuntu 15.10 и в бета-версии Ubuntu 16.04. Тем, кому интересно узнать причины проблемы и как можно её решить — прошу под хабракат.
Лирическое вступление
Всё началось с Clonezilla. Это такой Linux Live CD/USB с программой Clonezilla для копирования дисков. Делаю, я, значит, себе загрузочную флешку с различными утилитами и, по-возможности, включаю русификацию, там где это возможно, так как хочу поделиться флешкой с коллегами, а они не все хорошо владеют английским. Только-что закончил настраивать GParted Live. Думаю, что всё должно быть похоже — оба дистрибутива поддерживают live-config. Задаю параметры для русификации — добавляю к параметрам ядра следующие значения:
locales=ru_RU.UTF-8
keyboard-layouts=us,ru
keyboard-options=grp:ctrl_shift_toggle,lctrl_shift_toggle
Первый параметр задаёт язык, на котором система будет с нами общаться и кодировку. Второй параметр задаёт раскладки клавиатур, которые мы будем использовать. И третий задаёт способ переключения раскладок клавишами CTRL+SHIFT. На самом деле, язык и раскладку можно выбрать после запуска Clonezilla, но нельзя выбрать две раскладки и способ переключения — будет только русская или только английская клавиатура. Эти параметры корректно отработали в GParted Live и я ожидаю такого же поведения от Clonezilla. Но… после загрузки вместо русских символов отображаются чёрные квадратики:
Вспоминаю, что Clonezilla предлагает две ветки дистрибутива: стабильная базируется на Debian и альтернативная на Ubuntu. Альтернативная содержит несвободное ПО, такое как прошивка (firmware) некоторого оборудования (например, WiFi-карт), поэтому, я скачал её — для большей универсальности.
Ради хохмы качаю стабильную версию, основанную на Debian, запускаю с русской локалью — всё отображается корректно.
Подозрения падают на родительский дистрибутив — Ubuntu 15.10. Как раз у меня такой, думаю я и переключаюсь на текстовую консоль (Ctrl+Alt+F1) и запускаю `date`:
На-ка, говорит Убунта.
Поворот не туда
Здравый смысл подсказывает — бери стабильную Clonezilla и работай дальше. Но. Впереди выходные, Dota 2 меня «отпустила», а память подсказывает что проблемы с локализацией текстовой консоли в Ubuntu существуют давно, решаются с переменным успехом и хочется всё-таки разобраться.
Гуглим проблему и обнаруживаем, что с подобным сталкиваются начиная с Ubuntu 11.10. Есть несколько решений разной степени полезности, самое популярное — включить опцию FRAMEBUFFER=y для initramfs и пересобрать initrd командой update-initramfs. Со словами «только бы не думать, и наша возьмет!» добавляю строку FRAMEBUFFER=y в конец файла initramfs.conf, обновляю образ initrd и перезагружаюсь:
После перезагрузки изменений нет, всё те-же квадратики вместо кириллицы. На форумах многие так же жалуются на то, что этот способ им не помог.
Начнём сначала
Откатил все изменения назад, пораскинул мозгами. За настройку консоли в Ubuntu отвечает пакет console-setup, который хранит настройки в /etc/default/console-setup и применяет их через команду setupcon. Настройки можно изменить просто отредактировав файл или через dpkg-reconfigure console-setup. Проверяем настройки консоли:
cat /etc/default/console-setup
ACTIVE_CONSOLES=»/dev/tty1″
CHARMAP=»UTF-8″
CODESET=»guess»
FONTFACE=»Fixed»
FONTSIZE=»8×16″
В текстовой консоли даём команду setupcon. Даже на глаз видно, что шрифт изменился и теперь консоль отображает кириллицу:
Значит, в системе есть всё для отображения кириллицы, но при загрузке эти настройки не применяются. Посмотрим, что находится внутри пакета console-setup:
Помимо уже упомянутых двух файлов (console-setup и setupcon) интерес представляет файл console-font.conf, устанавливаемый в /etc/init/. Этот файл представляет из себя скрипт systemd, системы начальной загрузки linux, заменившей system v init. Посмотрим на содержимое:
Судя по заголовку и описанию это похоже на то, что надо — установка шрифта консоли при загрузке системы. Задача по установке шрифта перекладывается на скрипт /lib/udev/console-setup-tty. Приведу самые интересные части этого скрипта:
Я пока пропустил все функции, которые определены внутри скрипта, чтобы обратить внимание на самое важное. Первый комментарий говорит, что скрипт основан на setupcon, но урезан, чтобы соответствовать правилу udev. Допустим. Ниже идёт включение файла настроек (. /etc/default/console-setup). Дальше идёт проверка первого параметра, переданного скрипту, как раз с таким параметром (fbcon) скрипт вызывается из /etc/init/сonsole-font.conf. Для каждой активной консоли (указаны в /etc/default/console-setup) делается проверка на возможность записи в неё и, для каждой консоли вызывается функция setup_font. При этом, автор скрипта пишет, что к моменту вызова скрипта консоли должны быть созданы, а если нет, то тест на запись в консоль не сработает и эта консоль останется не настроенной. А пользователь сам может вызвать setupcon потом. Возьмём это на заметку и рассмотрим функцию setup_font из файла /lib/udev/console-setup-tty:
После перезагрузки шрифт будет установлен, но при смене шрифта через dpkg-reconfigure console-setup нам придётся опять вносить исправления вручную.
Продолжаем разговор
Вспоминаем про скрипт setupcon, который был упомянут в комментариях и на котором базируется /lib/udev/console-setup-tty. Смотрим, что у него внутри:
(a — первая цифра, b — вторая), то бОльшая цифра переставляется вперёд:
Например, было ’10×20′ — стало ’20×10′, а ’22×11′ меняться не будет. Посмотрим, как называются шрифты, доступные в системе:
то скрипт отработает правильно.
Тёплые потроха
Продолжаем потрошить скрипты. Ищем, откуда (из какого пакета) растут ноги у /lib/udev/console-setup-tty:
Скачиваем и распаковываем пакет keyboard-configuration:
Смотрим, в каких скриптах используется файл настроек /etc/default/console-setup:
Из них интерес представляют только:
отличаюся только одной строкой:
OPTION=FRAMEBUFFER
Знакомая опция, подумал я… Три интересующих нас скрипта расположены в папке initramfs-tools. Пакет initramfs-tools отвечает за сборку образа initrd, который загружается в память при загрузке ядра и используется им в тот момент, пока не доступна основная файловая система. В initrd обычно содержатся модули ядра, необходимые для его работы на нашем оборудовании и для подключения файловых систем, а так же, скрипты инициализации и их конфигурационные файлы. Собирается образ скриптом update-initramfs, который, в итоге, вызывает скрипт mkinitramfs. Как всегда, посмотрим что внутри у mkinitramfs:
Здесь всё выглядит довольно сложно, я попробую показать с примерами. Этот блок проходит по всем файлам в /usr/share/initramfs-tools/scripts/ и подпапках, и ищет внутри них строку, содержащую ‘OPTION=’. Например, в файле /usr/share/initramfs-tools/scripts/init-top/console_setup есть строка
Этими скриптами запускается и настраивается фреймбуфер (framebuffer) — грубо говоря, текстовая консоль переводится в графический режим. После этого появляется возможность отрисовывать в ней изображения и нестандартные шрифты. Вот как раз console_setup и устанавливает шрифт для консоли. Вероятно, из-за того, что пользователь может выбрать нестандартный шрифт, этот скрипт привязан к запуску фреймбуфера и без установленого параметра ‘FRAMEBUFFER=y’ не добавляется в initrd.
Таким образом, при активации фреймбуфера, так же будет происходить настройка консоли с установкой шрифта, но на более раннем этапе.
Но вернёмся к нашим скриптам из keyboard-configuration
Скрипт …/init-top/console_setup копируется в образ initrd при установленном параметре ‘FRAMEBUFFER=y’.
Скрипт …/panic/console_setup копируется в initrd всегда, т. к. не содержит заданную переменную ‘OPTION’. Скрипты из каталога panic вызываются функцией panic из скрипта init (который включает функции из файла /usr/share/initramfs-tools/scripts/functions). Сама же функция panic вызывается в случае, когда скрипт инициализации init не может продолжить выполнение (не найдена корневая файловая система и т.п.). Значит, скрипт…/panic/console_setup предназначен для настройки консоли в режиме panic, чтобы вывести сообщения в родной для пользователя кодировке.
Скрипт …/hooks/console_setup вызывается из скрипта mkinitramfs, при создании образа initrd:
Этот скрипт занимается тем, что копирует файлы, необходимые для настройки консоли (файл шрифта, таблицу перекодировки шрифта (acm) и файл раскладки клавиатуры (keymap)) в initrd. Соответственно, даже если мы исправим init-top/console_setup, но забудем внести изменения в hooks/console_setup, настройка консоли на этом этапе не произойдёт из-за отсутствия необходимых файлов.
Вносим исправления
Теперь, зная каким образом происходит настройка консоли и где допущены ошибки, можно внести правки в код. Качаем исходный код пакета keyboard-configuration, так же, скачаем все зависимости для пересборки пакета:
Но вместо keyboard-configuration у нас скачался пакет console-setup, из которого, как оказалось собирается несколько deb-файлов, в том числе console-setup и keyboard-configuration. Заходим в корень исходников, и смотрим в каких файлах используется переменная FONT:
После их изучения, понятно что нам интересны только
в каждый из файлов, после подключения конфигурационного файла и проверок, например:
Так же нужно добавить проверку на сжатый файлы:
После внесения правок можем пересобрать пакет — заходим в корень исходников и выполняем:
Всё, теперь при загрузке ОС будет корректно настраиваться текстовая консоль.
Скачать патч и исправленный пакет можно на странице с багрепортом на ланчпаде. Там же можно увеличить приоритет ошибки, зарегистрировавшись и нажав «This bug affects me».
Обновлено 20.04.2016:
Сегодня, 20.04.2016, за один день до релиза, исправление вошло сначала в proposed, а затем, и в release ветку Ubuntu Xenial.
Для этого пришлось приложить некоторые усилия. В частности — создать на launchpad’е ветку пакета console-setup, внести в неё исправления и предложить (propose) эту ветку для слияния с релизной. Так же, я посмотрел кто последний загружал пакет console-setup и отправил ему просьбу рассмотреть ошибку и исправления. Через 2 недели исправленный пакет был рассмотрен, одобрен и принят в релиз. Спасибо тебе, Mathieu Trudel-Lapierre!