На главную -> MyLDP -> Электронные книги по ОС Linux

---

Beyond Linux From Scratch. Version 2011-12-30
Назад	2. Важная информация	Вперед

---

Вопросы, связанные с локалями

На этой странице приведена информация о проблемах, связанных с локалями. Ниже будет приведен общий обзор ситуаций, которые могут возникнуть, когда вы конфигурируете систему, использующую различные локали. Многие (но не все) существующие проблемы, связанные с локалями, могут быть расклассифицированы и помещены одну из групп, перечисленных ниже. Степень серьезности проблемы определяется в соответствие со следующими критериями:

Если известно, что для конкретного пакета есть вариант решения проблемы, он будет указан на домашней странице пакета. Самую последнюю информацию, касающуюся вопросов, связанных с локалями, смотрите в Замечаниях для пользователя на BLFS Wiki.

Необходимая кодировка является недопустимой в программе

Серьезность: Критическая

В некоторых программах требуется, чтобы пользователь указал кодировку символов для их входных или выходных данных, причем присутствует только ограниченный выбор кодировок. Это параметр -X в пакетах a2ps-4.14 и Enscript-1.6.4, параметр -input-charset в непропатченном пакете Cdrtools-2.01 и наборы символов, предлагаемые для отображения меню в пакете Links-2.4. Если требуется кодировка, не указанная в списке, программы обычно становятся совершенно непригодными для использования. Для неинтерактивных программ проблему можно обойти, если преобразовать документ в поддерживаемый входной набор символов перед отправкой его в программу.

Проблему такого рода можно решить либо с помощью патча, применяемого к исходной программе, который добавляет требуемую поддержку для отсутствующей кодировки (как это было сделано в этой книге для пакета Cdrtools-2.01), либо с помощью поиска другой программы, которая заменит исходную.

Внутри самой программы определяется, в какой кодировке должны быть внешние документы

Серьезность: Высокая для нетекстовых документов и низкая для текстовых документов

В некоторых программах, например, Nano-2.1.10> или JOE-3.7, предполагается, что в документах всегда используется кодировка, задаваемая текущей локалью. Хотя это предположение может быть справедливо для документов, созданных пользователем внутри системы, это может оказаться неверным для внешних документов. Когда это предположение оказывается неверным, символы, не являющиеся символами ASCII, будут отображаться неправильно и документ не удастся прочитать.

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

Для нетекстовых документов такое преобразование сделать невозможно. Чаще всего такая ситуация возможна с документами, в которых де-факто используются стандарты операционной системы Microsoft Windows. Примером такой проблемы являются теги ID3v1 в файлах MP3 (более подробную информацию смотрите на странице BLFS Wiki ID3v1Coding). Для этих случаев, единственным решением является поиск другой программы, в которой такая проблема отсутствует (например, такой, в которой вы можете указать нужную кодировку документа).

Среди пакетов BLFS, эта проблема имеется в пакетах Nano-2.1.10 и JOE-3.7 и во всех медиаплейерах, за исключением Audacious-3.1.

Еще одна проблема из этой категории заключается в том, что некто не может прочитать документы, которые вы ему послали, поскольку его операционная система по другому настроена для обработки кодировок символов. Часто это может быть связано с тем, что с другой стороны используется система Microsoft Windows, в которой для конкретной страны используется только одна кодировка символов. Например, из-за этого возникают проблемы с документами TeX в кодировке UTF-8, созданными в Linux. В Windows большинство приложений будет считать, что эти документы были созданы в 8-битной кодировке Windows, используемой по умолчанию. Более подробную информацию смотрите на странице Wiki teTeX.

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

Программа использует или создает имена файлов в неправильной кодировке

Серьезность: Критическая

Стандарт POSIX обязывает, чтобы в качестве кодировки имен файлов использовалась кодировка, определяемая настройкой текущей локали, указываемой в LC_CTYPE. Эта информация хорошо скрыта и определяет поведение программ Tar и Cpio. Некоторые программы по умолчанию используют эту информацию неправильно (или просто не могут получить эту информацию). В результате они создают имена файлов, которые затем не удается правильно отображать командой ls, либо они отказываются принимать имена файлов, которые команда ls показывает правильно. Для библиотеки GLib-2.30.1 проблему можно исправить с помощью задания в переменной среды окружения G_FILENAME_ENCODING специального значения "@locale". Программы, пользующиеся библиотекой Glib2 и не учитывающие значение этой переменной, работают неправильно

Эта проблема есть в пакетах Zip-3.0 и UnZip-6.0, поскольку в них жестко задана используемая кодировка имен файлов. В пакете UnZip есть жестко закодированная таблица преобразования кодировок CP850 (DOS) и ISO-8859-1 (UNIX); таблица используется при раскрытии архивов, созданных под DOS или Microsoft Windows. Но такое решение хорошо работает в случае, когда используется настройка US, и не работает в случае использования локали UTF-8. В разархивированных файлах символы, не являющиеся символами ASCII, будут искажены.

Общее правило, позволяющее избежать проблем этого класса, состоит в отказе от установки неправильно работающих программ. Если это невозможно, то можно воспользоваться инструментальной программой convmv, работающей из командной строки, чтобы исправить имена файлов, созданные такими неправильно работающими программами, либо специально искажать имена файлов так, чтобы с ними могли работать такие программы.

В других случаях аналогичная проблема вызвана импортом имен файлов из системы, имеющей другую локаль, при помощи инструмента, не учитывающей значения локалей (например, пакет OpenSSH-5.6p1). Чтобы при передаче файлов в систему с другой локалью избежать искажения символов, не являющихся символами ASCII, можно воспользоваться одним из следующих способов:

Последние четыре способа работают, поскольку имена файлов будут автоматически преобразованы из локали отправителя в UNICODE и будут запомнены или отправлены в этом виде. Затем они будут прозрачно преобразованы из UNICODE в кодировку локали получателя.

Программа разрывает многобайтовые символы или неправильно подсчитывает количество символов

Серьезность: Высокая или критическая

Многие программы были написаны в то время, когда многобайтовые локали еще не были распространены. В таких программах предполагается, что для хранения одного символа может использоваться тип данных "char" языка C, который представляется одним байтом. Кроме того, в них предполагается, что любая последовательность символов является допустимой строкой, и что каждый символ занимает одну позицию в такой строке. Такие предположения абсолютно не соответствуют локалям UTF-8. Это проявляется в том, что программа преждевременно обрезает строки (т. е. использует 80 байтов вместо 80 символов). Терминальные программы неверно устанавливают курсор на экране, не реагируют на нажатие клавиши "Backspace", когда требуется стереть один символ, и оставляют повсюду нежелательные символы, когда происходит обновление экрана, что, как правило, обычно приводит к полному беспорядку на экране.

Как и со всеми другими случаями, связанными с внедрением новых концепций в старые проектные решения, исправление проблем такого рода с программистской точки зрения является трудоемкой задачей. В данном случае надо перепроектировать все структуры данных для того, чтобы учесть тот факт, что полный символ может занимать различное количество элементов типа "char" (или заменить его на wchar_t и выполнять конвертирование по мере необходимости). Кроме того, для каждого вызова функции "strlen" и других подобных функций нужно выяснить, определяют ли они количество байтов, количество символов, или ширину строк. Иногда быстрее с нуля написать программу с теми же самыми функциями.

Среди пакетов BLFS эта проблема встречается в пакете Xine User Interface-0.99.5 и во всех командных оболочках.

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

Серьезность: Низкая

Как было указано на странице LFS Man DB, в LFS ожидается, что страницы руководств кодируются в специальной кодировке (обычно 8-битовой), зависящей от конкретного языка. Тем не менее, в некоторых пакетах переведенные страницы руководств устанавливаются в кодировке UTF-8 (например, в пакете Shadow, с которым вы уже имели дело), или на языках, которых нет в таблице. Не все пакеты BLFS были проверены на соответствие с требованиями их включения в систему LFS (большинство было проверено, и для пакетов, о которых известно, что устанавливаемые страницы руководств не соответствуют требованиям, в книге приведены исправления). Если вы обнаружили, что страницы руководств, устанавливаемые в каком-нибудь из пакетов BLFS, имеют неправильную кодировку, пожалуйста, удалите их или преобразуйте в кодировку, которая вам нужна, и сообщите об этой ошибке разработчикам BLFS.

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

#!/bin/sh
# Begin checkman.sh
# Usage: find /usr/share/man -type f | xargs checkman.sh
for a in "$@"
do
    # echo "Checking $a..."
    # Pure-ASCII manual page (possibly except comments) is OK
    grep -v '.\\"' "$a" | iconv -f US-ASCII -t US-ASCII >/dev/null 2>&1 \
        && continue
    # Non-UTF-8 manual page is OK
    iconv -f UTF-8 -t UTF-8 "$a" >/dev/null 2>&1 || continue
    # If we got here, we found UTF-8 manual page, bad.
    echo "UTF-8 manual page: $a" >&2
done
# End checkman.sh

а затем выполните следующую команду (измените команду, приведенную ниже, если в переменной среды окружения PATH не указан путь к скрипту checkman.sh):

find /usr/share/man -type f | xargs checkman.sh

Обратите внимание, что если у вас есть страницы руководств, которые установлены не в каталоге /usr/share/man (например, в /usr/local/share/man), нужно изменить указанную выше команду так, чтобы в ней указать это другое место.

Перевод сделан с варианта оригинала, датированного 2011-11-09 17:37:35 +0000

---

Предыдущий раздел:	Оглавление	Следующий раздел:
Загрузочные скрипты BLFS		За пределами BLFS

---

---