Я тебе больше скажу:
"Юникод имеет несколько форм представления: UTF-8, UTF-16 (UTF-16BE, UTF-16LE) и UTF-32 (UTF-32BE, UTF-32LE). Была разработана также форма представления UTF-7 для передачи по семибитным каналам, но из-за несовместимости с ASCII она не получила распространения и не включена в стандарт".
Кроме того, меня например, сильно бесит его "вес". Это же нихрена не экономия!!! Еще поражают фразы типа: "С академической целью добавлены многие исторические письменности, в том числе: древнегреческая, египетские иероглифы, клинопись, письменность майя, этрусский алфавит. В Юникоде представлен широкий набор математических и музыкальных символов, а также пиктограмм."
Да на кой хрен там пиктограммы? Зачем мне клинопись или этрусский алфавит?

Отвечая на твой "PS" "Не бред ли пытаться их все охватить совокупным алфавитом !?"
Бред. Полный. Нет, полнейший!!!

--
Steel

Ты бы это, посмотрел на то, какие существуют способы представления нескольких алфавитов, отличные от Unicode. Сходу могу назвать два - COMPOUND_TEXT формат в X selection и переключение charset-ов в формате RTF. Спецификации обоих доступны. Прочитай и ужаснись.

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

Юникод со всеми его многочисленынми способами представления таки проще.

А если учесть существование на Земле письменностей количество знаков в которых принципиально в 8 бит не укладывается, и то что этими письменностями пользуются без малого два миллиарда человек...

(Reply to this) (Thread)

с ртфом я работал. это чудовище. не вижу смысла не сделать лучше.

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

нет не захотелось.
искать я могу И ДОЛЖЕН независимо от кодировки. (если же я ищу с учётом морфологии слов то я при поиске ПОЛЮБОМУ указываю в каком языке я ищу)
проверка орфографии прекрасно пойдёт по размеченному тексту (орфография это внутриязыковая херня)

АГА ! сортировать ! сортировать мультиязыковые строки ! офигенная идея !
то есть ты предлагаешь ввести бинарное отношение _больше_ на символах РАЗНЫХ алфавитов! латинская "A" больше кирилической "А" а она в свою очередь больше китайского иероглифа "хун" И каков прости физический смысл такой сортировки ? Насколько он более важен чем порядок байт приписанных буквам в произвольной кодировке ?

> "А если учесть существование на Земле письменностей количество знаков в которых принципиально в 8 бит не укладывается, и то что этими письменностями пользуются без малого два миллиарда человек..."

...то надо было воспользоваться такой УНИКАЛЬНОЙ ВОЗМОЖНОСТЬЮ изолировать их нахрен от технического прогресса.
и вообще
Какого хрена мы должны отказываться от КОМПАКТНОСТИ которую нам даёт алфавит, ради недоумков, которые до алфавита не додумались !
Эдак можно много от чего отказаться - вот православная церковь тоже любит традиции, может спросим у неё чего бы нам переделать ?

(Reply to this) (Parent) (Thread)

с ртфом я работал. это чудовище. не вижу смысла не сделать лучше.

Ну так ведь никто не сделал. Я тоже работал и с rtf-ом, и с postscript-ом и с COMPOUND_TEXT в X-selection. И даже на японскую кодировку shift-jis смотрел. А еще я KOI-7 помню.

Решения на базе переключателей кодовых страниц всегда кривее и более громоздки, чем решения на базе расширения пространства кодов.


АГА ! сортировать ! сортировать мультиязыковые строки ! офигенная идея !
то есть ты предлагаешь ввести бинарное отношение _больше_ на символах РАЗНЫХ алфавитов! латинская "A" больше кирилической "А" а она в свою очередь больше китайского иероглифа "хун" И каков прости физический смысл такой сортировки ? Насколько он более важен чем порядок байт приписанных буквам в произвольной кодировке ?


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


.то надо было воспользоваться такой УНИКАЛЬНОЙ ВОЗМОЖНОСТЬЮ изолировать их нахрен от технического прогресса.


Ох, насмешил! Изолировать нафиг от технического прогресса страны где сосредоточено практически все мировое производство чипов, значительная доля производства автомобилей и т.д.
Ты подумай внимательно - эти два миллиарда - это Китай, Япония, Тайвань и обе Кореи. Что от нашего технического прогресса останется, если их изолировать?

(Reply to this) (Parent) (Thread)

> Решения на базе переключателей кодовых страниц всегда кривее и более громоздки, чем решения на базе расширения пространства кодов.

черезчур общее высказывание чтобы я в него поверил.
Да ещё не забывайте что Юникод у вас не один - от переключения кодовых страниц вы никуда не ушли.

> позволит собрать все русские слова в одну кучку, все европейские в другую, все китейакие третью.

это явная натяжка.
с таким же успехом можно сравнивать Джоули с Метрами и ведь сравнение будет давать результат.

> Ты подумай внимательно - эти два миллиарда - это Китай, Япония, Тайвань и обе Кореи.

ТОЛЬКО КИТАЙ и Тайвань, но тайвань весь свободно пишет по английски.
У обеих Корей и у Японии есть нормальные алфавиты (у японцев есть ещё два иероглифических сэта, но это для гурманов, а корейцы забыли про иероглифы более 500 лет назад)

(Reply to this) (Parent)

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

- имен файлов
- комментариев в JPEG и прочих графических форматах
- тэгов в MP3 и прочих audio-форматов
- субтитров в в видео
- форматов, изначально заточенных ни разу не под текст на естественном языке (например, комментариев в тексте программ и даже идентификаторов в оных)

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

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

С очевидностью, любой способ языковой разметки эту задачу решает намного хуже, чем универсальный набор символов (Universal Character Set, UCS). Опять же, представим себе что в тексте на английском языке встретилось название французского населенного пункта, с использованием каких-нибудь диакритических знаков. На каком языке написано это слово? А на каком языке написано словосочетание et cetera?

В общем, если мы захотим добиться решения задачи универсального представления многоязычных текстов путем маркирования языка, на котором текст написан, нам придется вносить еще больше изменений во все существующие программы, начиная с утилиты /bin/ls, чем в случае использования unicode. В случае unicode нам /bin/ls менять не придется. Достаточно поменять в стандартной библиотеке функцию strcoll (что и было проделано лет восемь назад).

Переход на unicode прозрачен для большинства мелких инструментов. Маркированное представление многоязычных текстов - нет.

(Reply to this) (Thread)

Ув. Витус.
Скажите, зачем мне, простому пользователю, хотеть иметь все сразу? Особенно, если мне надо только 2 вида кодировки. Latin-1 и Koi8-r ? Зачем мне представлять себе, что я, возможно, когда-нить захочу написать на суахили?
Кроме того, скажите, символы скольких языков (примерно) не могут быть записаны в 1 байт? и зачем, мне терять примерно в 2,7-3,2 больше трафика, чем если бы я исплользовал 8-битную кодировку? Еще раз повторяю. На древне-шумерском я пишу _очень_ редко.

Также интересна хотя бы примерная цифра тех, кто использует одновременно более 2-х языков в текстах. И, прикидка отношения (те, кто так делает/те кто так не делает).

Помимо все вышеперечисленного еще интересно, так на каком же из Юникодов надо писать? UTF-16 или UTF-8 ?

Также очень сильно интересует, что, в случае, если бы я согласился использовать Юни, то я бы, скорее всего, был бы очень даже 2-мя руками за механизм "подгрузки", т.е. я устанавливаю ТОЛЬКО то, что мне надо, а при необходимости, и после моего разрешения, система лезет и качает то, что использованно в этом документе.

--
Steel

(Reply to this) (Parent)

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

Обычно приходят РОВНО ДВА: нормальный и национальный

> Причем, это касается не только текстов документов в word-процессоре, а всего где могут понадобится осмысленные слова
>
> - имен файлов
> - комментариев в JPEG и прочих графических форматах
> - тэгов в MP3 и прочих audio-форматов
> - субтитров в в видео
> - форматов, изначально заточенных ни разу не под текст на естественном языке (например, комментариев в тексте программ и даже идентификаторов в оных)
>
> При этом ему категорически не хочется указывать явным образом, на каком языке он в данный момент пришет.

Очень хорошо !
Возьмём например имена файлов (остальные пункты по аналогии будут работать).
Сегодня я даю файлам русские имена И НЕ УКАЗЫВАЮ НИГДЕ ЯВНО ЧТО ПИШУ НА РУССКОМ (это то что категорически хочет пользователь) никаких проблем не имею.
Если я перехожу на Юникод, то оказывается что я ЯВНО УКАЗЫВАЮ ЧТО АЛФАВИТ КИРИЛИЦА ПРИ КАЖДОЙ БУКВЕ

> чтобы можно было перетащить мышкой фрагмент текста из документа в комментарий к картинке и так далее.

В ТОПКУ !

> Опять же, представим себе что в тексте на английском языке встретилось название французского населенного пункта, с использованием каких-нибудь диакритических знаков. На каком языке написано это слово? А на каком языке написано словосочетание et cetera?

А вот тут вы смешиваете два понятия алфавита и языка (впрочем это делают создатели юникода)

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

А на каком языке - это вопрос отдельный, который кстати юникодом не решается.
Я могу написать слово et cetera на UTF-8 (что я сейчас и сделал) Скажите мне на каком языке я его написал.


> Переход на unicode прозрачен для большинства мелких инструментов.

это не так
все они сталкиваются с кучей проблем.

(Reply to this) (Parent) (Thread)

Возьмём например имена файлов (остальные пункты по аналогии будут работать).
Сегодня я даю файлам русские имена И НЕ УКАЗЫВАЮ НИГДЕ ЯВНО ЧТО ПИШУ НА РУССКОМ (это то что категорически хочет пользователь) никаких проблем не имею.

Дорогой мой - имена файлов уж десять лет как в юникоде. И офисные документы - тоже. Ну - девять, здесь не с 95, а с 97. Так что по аналогии - не получится.

(Reply to this) (Parent) (Thread)

Хорошо, меня проигнорировали, но это ладно. "второй пост был не мой".

Так что же мне мешает использовать "аналог" DTD ? с указанием места, откуда можно закачать нужный мне пакет шрифтов?

--
Steel

(Reply to this) (Parent) (Thread)

да глупости вы говорите, DTD и вообще вся эта грёбаная технология уместно пребывает в общем потоке бардака - не стоит на неё равняться.

Просто у господ изобретателей новых "всеохватных" кодировок плоховато было с декомпозицией - пытаются решать проблемы не своего уровня реализации

(Reply to this) (Parent)

а вот насчёт того что
ШРИФТ ДОЛЖЕН БЫТЬ ОТДЕЛЁН ОТ КОДИРОВКИ это я как раз хотел написать.
Шрифт отображает алфавит на его начертание
А кодировка отображает коды буков на алфавит
Вот именно так.
Поэтому не может быть в принципе никаких "коёвых" шрифтов "юникодных" шрифтов итп.
Тут мы имеем классический пиздец в основе здания.

(Reply to this) (Parent)

Вы меня пугаете ! Я конечно до такой степени не разбирался, я - юзер.
Но я же всё и всегда компилирую --without-multibyte --without-nls
расскажите подробнее, что за беда с именами файлов.

(Reply to this) (Parent)

Ходил в ЖЖ по ссылкам от юзера к юзеру и попал к Вам... Прокомментриую моменты как их вижу, надеюсь Вы не против? И извините что всё в одну кучу.

Во-первых Unicode один. Это его форматов представления (UTF) несколько. Но это не так и важно, это чисто вопросы терминологии.

Unicode выигрывает по сравнению со смесью кучи кодировок только одним. Он проще построен и создает единую модель для любых алфавитов. При смеси разных кодировок надо постоянно искать где переключается кодировка и поиск с середины файла затруднен - надо "отматывать" назад до ближайшего "переключателя". При тексте в Unicode - максимум - надо только найти начало ближайшего символа.

Вот с разделением символов и языков в Unicode бардак. Прямо в сердце стандарта. Почему-то русская "П" и греческая "Π" там разные, хотя первая явно происходит от второй и выглядят они абсолютно одинаково. А иероглиф "草"[U+8349], который в китайском, корейском и японском языках пишется по-разному, хотя и происходит от одного символа, почему-то один. Причём унифицированы не все символы, а только некоторая часть - есть т.н. Z-variants. В общем, странностей хватает.

с таким же успехом можно сравнивать Джоули с Метрами и ведь сравнение будет давать результат.

А почему нет? Окажется джоуль в группе "единицы энергии", а метр в "единицы длины". То же, Unicode что-то имеет код больше или меньше и русский идет после греческого и до иврита это чистая условность. Как и то что "," идет до "{" и после "!".

У обеих Корей и у Японии есть нормальные алфавиты (у японцев есть ещё два иероглифических сэта, но это для гурманов, а корейцы забыли про иероглифы более 500 лет назад)

Если хотите сказать что теперь они могут обойтись и однобайтными кодировками то неправда Ваша.

У корейцев хангыль ни за что не впишется в 128 знаков. Или два байта на символ или суррогаты (или как там комбинационные символы называются), но и так и так - многобайтность не убрать. Да и, кстати, в именах у них до сих пор иероглифы.
У японцев есть фонетический алфавит, даже два (если не брать в счёт ещё один очень старый, который сейчас почти забыл), и они бы отлично вложились в 128 знаков upper ASCII, но из-за устройства языка без иероглифов у них никак не получится.
А азиаты пишут по-английски не так и свободно. Есть, конечно, хорошо говорящие на английском, но далеко не все. Мне как-то один корейский datasheet на микросхему попался - я бы, наверное, быстрее выучил корейский чем понял что же на "корейском английском" там было. У японцев дела так же (с учётом того что английский у них обязателен к изучению в школах). Может быть в Тайване с этим лучше, конечно.

Скажите, зачем мне, простому пользователю, хотеть иметь все сразу? Особенно, если мне надо только 2 вида кодировки. Latin-1 и Koi8-r? Зачем мне представлять себе, что я, возможно, когда-нить захочу написать на суахили?

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

Поэтому не может быть в принципе никаких "коёвых" шрифтов "юникодных" шрифтов итп.

Да, да и ещё раз да. Я с Вами абсолютно согласен.
Правда, Unicode, если не путаю, вообще ничего не говорит о реализации шрифтов. Практически всё что говорят же - "для символа U+nnnn должно быть изображение вот такого знака". А уж как система будет работать со шрифтами это дело системы. Явление "коёвых" и "юникодных" шрифтов же это только процесс перехода. Уже имевшиеся (неюникодные) шрифты же для Unicode не приспособлены, и устройство их не подходило для Unicode, а поддерживать надо.

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

(Reply to this) (Thread)

> Во-первых Unicode один. Это его форматов представления (UTF) несколько

хоть горшком назови, но их больше одного и они РАЗНЫЕ
таким образом нет единства и нет универсальности - эти два лозунга можно выкинуть.

> Он проще построен и создает единую модель для любых алфавитов.

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

Про нахождение начала символа это вы верно очень подметили !!!

> Окажется джоуль в группе "единицы энергии", а метр в "единицы длины".

это не является отношением линейного порядка, не надо притягивать за уши - автор аргумента про сортировки, не стал его отстаивать и правильно сделал.

> У корейцев хангыль ни за что не впишется в 128 знаков.

Это количество слогов не впишется но эти слоги составлены из БУКВ и букв там не больше 30 непомню.

> Но система делается не на конкретного, а на абстрактного пользователя, который может равновероятно захотеть говорить на любом языке.

Это неверная модель пользователя. Вы заточили систему исходя из ложного предположения о пользователе.



Есть у меня одно ИМХО:
более двух языков кроме как в текстовых произведениях нигде нахер не надо
поэтому затачивать на многоязыковость файловые системы итп - есть полнейший бред - уж кому кому а файловой системе в первую очередь не надо знать на каком языке я ей файлы именую.
Большинство современных проблем с кодировками (не только с юникодными) возникает от того что "слишком умные" подсистемы или программы пытаются неявно переконвертировать данные, делая какие-то свои предположения об их кодировке, в то время как пользователю хотелось бы просто БЕЗ ИЗМЕНЕНИЙ передать "три байта" ну например имя файлу из трёх байт дать и не подумайте что "хуй". А по сему ОЧЕНЬ МНОГО ПРОБЛЕМ СНЯЛОСЬ БЫ простым отрезанием рук тем кто любит провлять заботу о кодировках там где программе лучше было бы вообще о кодировке не знать.

(Reply to this) (Parent) (Thread)

таким образом нет единства и нет универсальности - эти два лозунга можно выкинуть.

Минимальная из проблем, на самом деле. Пусть приложение поддержит любой из форматов, а если что - даже сконвертировать на лету с вполне удовлетворительной скоростью это, думаю, не большая проблема.

IMHO же лучше всего UTF-8, т.к. она оставляет совместимость с ASCII (lower ASCII), нет нулевых байт, не несёт проблем с byte order и UTF-8 местами избавляет программиста от ложных убеждений, которые легко сделать с UTF-16, по ошибке расценив её как UCS-2. Но это моё мнение.

отдав на откуп носителям языка добавление и создание нац кодировок.

Я не вдавался в детали, но вроде бы так и есть - в Unicode Consortium и входят группы, в которых работают представители-носители языка.

это не является отношением линейного порядка, не надо притягивать за уши

Это вообще не отношение. Как нельзя сказать что "a" < "α" < "あ", так нельзя и сравнивать джоуль с метром. Но почему нельзя сказать "джоуль мы поставим в списке 5-м, а метр - 6-м" (где цифры - просто сложившиеся свободные места) я не понимаю. Поясните?

Это количество слогов не впишется но эти слоги составлены из БУКВ и букв там не больше 30 непомню.

Ok, ok, составные эти символы, но этого мало. Рассмотрю на простом примере слога хангыли "한" [Han]. Состоит из нескольких элементарных компонентов-"букв", т.н. "чамо". Если точнее, то из "ㅎ" [hieuh], "ㅏ" [a] и "ㄴ" [nieun]. Чамо действительно мало - 51 штука, в upper ASCII вписывается прекрасно. Но чтобы представить символ "한" все равно потребуется 3 байта. И разрезáть хангыль (слога) на куски корейцы, разумеется, ни за что не захотят - это во-первых нерационально, во-вторых - глупо - подстраивать язык под софт, когда должно быть наоборот - софт пишется для человека, а не человек для софта.

Это неверная модель пользователя. Вы заточили систему исходя из ложного предположения о пользователе.

А какое представление о пользователе правильно? То что пользователь всегда использует не более двух языков - национальный и английский?

И что я делаю неправильно, желая иметь и имея такой набор файлов:

• /home/drdaeman/university/ПиОС/Курсовики.tar.gz
• /usr/local/share/music/ムック/朽木の灯/01. 朽木の灯.mp3
• /usr/local/share/music/ムック/朽木の灯/15. 朽木の塔.mp3

При этом я, даже если бы мне этого хотелось, транслитерировать (написать "Kuchiki no Tou.mp3") японские названия не могу - они омонимичны.

О языке файловая система (ext3), разумеется, ничего не знает, она просто хранит набор байт, который ей сказали. В моём случае - строки в utf-8 (locale). Если надо будет что-то другое где-то - будет другая локаль, или укажу нужный iocharset в fstab, поимею свою долю гиморроя с перекодировкой того что было на диске, и всё.

А по сему ОЧЕНЬ МНОГО ПРОБЛЕМ СНЯЛОСЬ БЫ простым отрезанием рук тем кто любит провлять заботу о кодировках там где программе лучше было бы вообще о кодировке не знать.

Cогласен. Что программе дали то, если её не просили особо, она должна и использовать, все лишние выдумки разработчиков там где они не нужны - явное зло.

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

(Reply to this) (Parent) (Thread)

> Пусть приложение поддержит любой из форматов, а если что - даже сконвертировать на лету с вполне удовлетворительной скоростью это, думаю, не большая проблема.

Это в точности повторяет нынешнюю ситуацию с множеством кодировок.

> Я не вдавался в детали, но вроде бы так и есть - в Unicode Consortium и входят группы, в которых работают представители-носители языка.

Нет, я не это имел ввиду. Как они организовали работу это не имеет значения, мне кажется что надо было сделать _механизм_ а конкретные таблицы кодировок не разрабатывать.

> Ok, ok, составные эти символы, но этого мало. Рассмотрю на простом примере слога хангыли "한" [Han]. Состоит из нескольких элементарных компонентов-"букв", т.н. "чамо".

Это всего лишь проблема ПОРЯДКА СЛЕДОВАНИЯ БУКВ НА ПЛОСКОСТИ ПРИ ПИСЬМЕ и эту проблему кодировка решить не может и не должна (хотя я уже предвижу, как через пару лет Юникодеры там наверху придумают приписывать буквам атрибуты "с какой стороны будет стоять следующая буква") если вы помните, в русском языке тоже далеко не с самого начала буквы стали писаться в строчки.

> глупо - подстраивать язык под софт, когда должно быть наоборот - софт пишется для человека, а не человек для софта.

Ну вы же прекрасно выучили два существенно разных графических набора знаков русского алфавита !!! Один из них заточен под рукопись другой под книгопечатание. Почему вы думаете что корейцам это не под силу ?

Глупо подстраивать язык под книгопечатание? давайте срочно отменим печатные буквы и отменим написание слов в строчку, будем писать как наши предки, тесня буквы подобно корейцам?

> О языке файловая система (ext3), разумеется, ничего не знает, она просто хранит набор байт,

Это прекрасно ! именно так и надо. и такой порядок не помешает мне именовать файлы в моей кодировке и затем интерпретировать эти имена так как мне это надо.

(Reply to this) (Parent) (Thread)

Это в точности повторяет нынешнюю ситуацию с множеством кодировок.

Повторяет, но не там где была проблема. Проблема стояла не в создании единой кодировки, а в вопросе размещения текстов на разных языках в одном документе. Я говорил в самом первом комментарии - Unicode это не формат представления как UTF-8 или UTF-16. Да и UTF-8 и UTF-16LE в одном файле никто даже при тяжёлом ранении головы смешивать не будет. А вот смесь CP1251 и Shift-JIS я в одном файле видел и выглядело далеко не лучшим образом.

Это всего лишь проблема ПОРЯДКА СЛЕДОВАНИЯ БУКВ НА ПЛОСКОСТИ ПРИ ПИСЬМЕ и эту проблему кодировка решить не может и не должна

Тем не менее, хоть не может, но решила. И компоновку хангыли из чамо в корейском и письмо справа-налево в иврите и ещё кучу всего.

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

Ну вы же прекрасно выучили два существенно разных графических набора знаков русского алфавита !!! Один из них заточен под рукопись другой под книгопечатание.

Вы смешиваете шрифты (начертание символов) и символы языка в одну кучу.

Для подстройки под книгопечатание адаптировалось начертание знаков. Но никто не делил для этого "й" на "и" и диакритический знак над ней.

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)

введение же юникода не избавляет от необходимости писать новый софт
Не совсем так.
Избавляет. Раньше написав версию софта для америки, вы потом заново ее переписывали для европы, россии, японии и т.п.
Потому как символы были в других местах кодовой таблицы, да и к тому-же не по одному байту на символ.
В конце концов программистов это достало. И чтобы не переделывать туже работу по многу раз и сделан юникод. Напиши один раз, и имей сразу поддержку всех языков. Рулез!
Да, много геморойнее, чем с однобайтовой кодировкой. Но раз для китайцев/японцев все равно приходится делать многобайтовую кодировку, то имеет смысл внести в нее и все остальные символы (их-то меньше), и писать софт сразу под нее. Вот и вышел юникод.