Почему кодировка включена в локаль?

Насколько я понимаю, POSIX говорит, что определение локали должно включать в себя тип кодировки символов, такой как UTF-8. Локаль обычно реализуется как переменные среды оболочки.

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

  • ssh и кодировка символов
  • cp: не может статировать ошибку - когда имя файла имеет азиатские символы
  • ssh и кодировка символов
  • cp: не может статировать ошибку - когда имя файла имеет азиатские символы
  • One Solution collect form web for “Почему кодировка включена в локаль?”

    Некоторые языки, например, китайцы, могут быть написаны несколькими наборами символов, и оба они верны. У них есть более новый, упрощенный набор символов, а также более сложный, традиционный. Или монгольский или сербский могут быть написаны как с кириллицей, так и с латинским шрифтом.

    Кроме того, акцентированные символы, такие как ä, ö и подобные, на многих языках, имеют разные коды в разных кодировках, хотя они одинаковы на экране. Таким образом, написать ä в файл означает, что вы пишете в этот файл другую последовательность байтов, если он закодирован utf8, как если бы он был закодирован по другому стандарту (в моем примере его имя – iso8859-1).

    Кроме того, существуют кодировки, которые могут поддерживать один или несколько языков. Например, iso8859-1 поддерживает большинство западноевропейских языков, iso8859-2 поддерживает центральные и восточные европейские, пока они не написаны латинским шрифтом. Ascii поддерживает только английский язык, но utf8 поддерживает почти все языки мира.

    Таким образом, между языками и возможными кодировками существует соотношение «многие-ко-многим»: языки могут кодироваться несколькими кодировками, а большинство кодировок может использоваться для нескольких языков.

    Существует также отношение «многие ко многим» для совместимости с кодировкой: например, iso8859-2 совместимо с ascii, но ebcdic – нет.

    Между совместимостью кодирования существует также много-много взаимосвязей. Например, ebcdic может быть преобразован в ascii, но iso8859-2 не может.

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

    Хотя это было бы возможно, и, на мой взгляд, лучший способ, если бы он обрабатывался другой переменной окружения. Таким образом, для кодировки в качестве языка будет другая переменная среды, и она не будет расширением языковой строки. Причина этого в основном историческая, по причинам совместимости.

    Но, по крайней мере, в glibc существует поддержка также для разных переменных среды. Вот как выглядит «локаль» на одном из моих английских linux:

    $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= 

    Как вы можете видеть, существуют различные переменные среды LANG и LANGUAGE. К сожалению, это в основном для некоторой стандартной совместимости, и система не выглядит действительно последовательной.

    Расширение:

    Об истории: в древние времена почти все системы находились на американском английском языке с кодировкой ASCII или EBCDIC. Поддержка Multilang или multiencoding была неслыханной, и, если они были разработаны, они использовали специальные решения (например, перезаписывая растровые изображения набора символов в прошивке системы). Кроме того, я разработал в то время латинскую поддержку символов для c64 примерно в 1988 году (я сделал только некоторые символы latin2, доступные, но не кодовая страница – в то время я даже не знал, что такое кодовые страницы)). Страницы кодов были для них более поздним изобретением, первоначально для стандартизации аналогичных расширений для ascii. В мире мэйнфреймов использовались ebcdic, которые по своей сути несовместимы с ascii, аналогичный коммутатор произошел также (ebcdic был первоначально разработан, чтобы сделать перфокарты легко читаемыми людьми, цели ascii – легкая обработка данных).

    Все эти кодировки использовали 1 символ для 1 байта. В Linux поддержка нескольких языков началась в эпоху libc4 (в начале девяностых). Unicode еще не существует, это был новый и не реализованный стандарт, и все программное обеспечение было разработано с 1 символом char = 1 байт. Чтобы сделать utf жизнеспособным, все они должны быть значительно изменены, что стало источником серьезных проблем следующего десятилетия.

    Все языковые расширения использовали верхнюю половину байта (ascii указывает только 7 бит, поэтому место для ä, ö или для сценария кириллицы / грека находилось между 128-255). Таким образом, они были несовместимы также с каждым другом. Таким образом, в то время отношение между языками и кодовыми страницами было больше похоже на взаимно однозначное, как на нынешнее много-ко-многим.

    Таким образом, поддержка языка четко указала и кодовую страницу. Таким образом, не было никакой поддержки для разных кодовых страниц, даже кодовая страница, поскольку терминология не была очень принята. Вы можете себе представить, сколько проблем было вызвано в то время, когда win95 переключился с ibm850 на win31 на cp1251, в то время как большинство инструментов даже не знали, что существуют кодовые страницы.

    В Linuxes просто язык был определен двумя символами в переменной среды LANG и не более. Языковая диалектная поддержка (например, «pt_BR» для португальского португальца, а не просто «pt») уже была независимым расширением для этого.

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

    Linux и Unix - лучшая ОС в мире.