Китайского не знаю. Интересуюсь кодированием текста в компьютере.
Есть такое подозрение, что 16 бит на один символ (типа UCS-2) - вполне достаточно для кодирования всех современных языков. При этом кодировки c переменным числом бит на символ, доходящим до 32 (типа UTF-8, UTF-16), представляются излишними. Применительно к китайскому языку это выглядит так:
При наборе иероглифа на компьютере китайцы всё равно используют обычную клавиатуру и набирают последовательность ключей. Эту последовательность ключей и нужно записывать в компьютере при кодировании текста. Иероглифы же получаются объединением последовательных ключей абсолютно по тем же принципам,
как буквы объединяются в лигатуры: При графическом отображении текста несколько подряд идущих ключей нужно изобразить одним знаком. Соответственно, попытка считать иероглиф отдельным символом - ненужное усложнение.
Согласны ли в целом с такой точкой зрения уважаемые китаеведы? Или тут что-то принципиально неверно?
2018.05.02 И виноград  Есть такое подозрение, что 16 бит на один символ (типа UCS-2) - вполне достаточно для кодирования всех современных языков.
16 бит на символ - совершенно недостаточно для кодирования современных языков. Хотя бы потому, что общее количество различных живых языков составляет несколько тысяч, плюс есть огромное число вымерших, на которых тоже, вообще-то, есть тексты, которые надо иметь в оцифрованном виде. Долгое время были даже сомнения, что на все символы всех языков хватит 4-х байт, поэтому первые версии кодировки UTF были вообще 6-байтовыми.
2018.05.02И виноград При этом кодировки c переменным числом бит на символ, доходящим до 32 (типа UTF-8, UTF-16), представляются излишними.
Иметь постоянную длину символа (например, ровно 2 байта) - неудобно. Некоторые символы используются часто (например, латинские), некоторые редко, и поэтому удобно иметь кодировку переменной длины. Именно так устроена UTF8, которая в качестве базовой части берет латинские символы и кодирует их одним байтом, а русские символы и иероглифы кодируются большим числом байт.
2018.05.02И виноград При наборе иероглифа на компьютере китайцы всё равно используют обычную клавиатуру и набирают последовательность ключей. Эту последовательность ключей и нужно записывать в компьютере при кодировании текста.
1) Мы пишем то, что говорим, и китайцы - не исключение. Как правило, удобнее набирать иероглиф не по ключам, а по его звучанию, то есть пиньинем. Каждый набранный слог естественно превращается в иероглиф.
2) Набирать по чертам - значит еще и помнить весь порядок написания иероглифа, а не просто его звучание, что гораздо сложнее. Даже сами китайцы далеко не для всех иероглифов, значение и звучание которых они помнят, способны по памяти воспроизвести порядок черт.
2018.05.02И виноград Иероглифы же получаются объединением последовательных ключей абсолютно по тем же принципам, как буквы объединяются в лигатуры: При графическом отображении текста несколько подряд идущих ключей нужно изобразить одним знаком.
Знание ключей и их порядка - это еще не знание иероглифа, потому что есть еще вариации написания конкретного ключа и местоположение ключа в составе иероглифа. Кроме этого, некоторые иероглифы можно разложить на ключи разными способами. И вообще, хранение символа через последовательность ключей крайне избыточно, потому что, во-первых, в иероглифе могут быть десятки ключей, и, во-вторых, огромное количество комбинаций ключей никогда не встретится в составе одного иероглифа.
Спасибо. Это всё очень интересно. И в значительной мере ведёт к тому, что мне нужно свои мысли переформулировать.
С учётом внесённых поправок, мне пока представляется такая картина.
Конкретно китайцы что-то набирают на обычной клавиатуре. Пускай пиньинь.
Всё равно комбинаций кнопок, набираемых последовательно или одновременным комбинированием, совсем не много: несколько десятков.
Вот их-то и представляется целесообразным сохранять в качестве компьютерной записи текста.
Проблема же отображения сохранённого текста путём формирования иероглифов - это другая проблема,
которую нужно решать по тем же принципам, как формируются лигатуры в европейских языках.
То есть составить "словарь" лигатур, и каждой лигатуре сопоставить свой алгоритм начертания (кодирование векторной графики).
Хотелось бы понять, почему китайцы так не делают? Или делают?
Что касается общих вопросов относительно всех имеющихся языков вообще, тут Вы меня не переубедили.
Попытка раз и навсегда составить набор символов когда-либо использовавшихся человечеством (и символов, которые будут использоваться)
представляется химерой и утопией (лично мне, но, видимо, не Консорциуму Юникода).
Когда-то 7-битная кодировка ASCII расширялась до различных 8-битных кодовых страниц типа CP866 или CP1251 (для кириллицы).
Представляется актуальным сохранить примерно такой же механизм расширений.
В качестве "базового ядра" взять уже не латиницу, а все символы живых языков (что-то типа UCS-2).
Живых языков, имеющих свою письменность, вроде бы не так уж и много. Вроде пишут, что порядка сотни.
Значит, кодирующих символов скорее всего меньше 10 тысяч. То есть 16 бит вполне достаточно, и даже на расширения хватит.
Иметь представление символов в виде комбинаций фиксированного числа бит (16-ти) - очень удобно:
в последовательности любой символ легко отыскивается по номеру, легко программируются стандарные операции со строками.
Если памяти жалко - архиваторы в помощь. Сожмут всяко лучше, чем UTF-8.
(Кодировку типа UTF-8 следует рассматривать как один из множества алгоритмов сжатия.)
Касательно того, что "огромное количество комбинаций ключей никогда не встретится в составе одного иероглифа".
Это к чему? Огромное количество комбинаций русских букв никогда не встретятся в составе одного русского слова. И чего?
В общем, хочется понять, насколько тяжело китайский язык может быть вписан в прокрустово ложе описанной схемы.
Никто не утверждает, что это совсем просто и безболезненно. Но ведь и организация набора китайского языка на стандартной клавиатуре - задача не из простых.
Однако приходится её как-то решать.
В том, что вы описали выше, я вижу только одну цель - устранить избыточность хранения иероглифов в текущем виде. Вам кажется, что хранение последовательности черт, или хранение набора нажатых клавиш на клавиатуре будет оптимальнее, чем хранение иероглифов принятым в настоящее время образом.
Представьте, вы вводите иероглиф.
Для этого вам, к примеру, пришлось ввести пиньинь (допустим, это три нажатия, каждое кодируем 5 битами) и выбрать далее из списка омонимов конкретный иероглиф с этим пиньинем (допустим, вы выбрали 1 иероглиф из 50 предложенных омонимов, то есть это 6 бит). В итоге информационная емкость получается 3x5 бит + 6 бит = 21 бит. Это уже будет избыточно по сравнению с 16-битной кодировкой.
Допустим, вы изловчились, и стали кодировать умнее - к примеру, вместо подряд нажатых кнопок стали сразу кодировать используемый слог (которых около 400, то есть это 9 бит) + устранение омонимии (опять же 4-5 бит). Все равно у вас получится около 16 бит на символ. Но это будет только один язык - китайский, а у нас их еще куча, и если вы будете обозначать использованный язык каким-то битовым префиксом в составе символа, например 8-битным для 100 языков, то опять же будет почти 3 байта на символ.
Да, можно оптимизировать это все и дальше, но тогда у вас получится уже не алгоритм кодирования, а алгоритм сжатия, и в этом случае, даже если вы и сэкономите объем памяти, вы сильно потеряете на времени кодирования - декодирования.
Еще учтите вот что: архитектура 32-битных процессоров заточена под выравненные данные. То есть, данные должны быть 4 байтными, расположение в памяти должно быть по адресу, кратному четырем, и тд. Работа со структурами, имеющими некратный размер байт, оказывается медленнее. В частности, из-за этого многие базы данных - типа того же Oracle - даже самые мелкие типы (1 байт, 1 бит) данных предпочитают хранить в контейнерах большего объема, кратного 4-м.
Вывод: текущие кодировки (UTF8, Unicode) мне кажутся близкими к оптимальным.
P.S.: есть еще вот такой факт: если вы возьмете большой (несколько мегабайт) текст на русском языке в CP1251, и его перевод на китайский в UTF8, то размеры файлов в байтах, как ни странно, получаются почти одинаковыми. Да, отдельный китайский иероглиф занимает больше байт, но самих иероглифов меньше, чем букв в русском тексте, и эти два фактора друг друга гасят. Отсюда следует, что избыточность хранения "смысла текста" на китайском языке в UTF8 соответствует такой же избыточности ее хранения на русском, то есть минимальна. Вы же не будете утверждать, что и русские буквы хранятся неоптимально?
Спасибо за разъяснения. Я чувствую, что у меня уже есть некоторое понимание принципов кодирования китайских текстов. 
Складывается ощущение, что некий условный "общий знаменатель" между тем, что говорю я, и тем, что говорите Вы - это кодировка UTF-16. То есть вроде как китайцам нет особого смысла полностью сохранять при кодировании текста способ клавиатурного ввода. А если при кодировании китайский иероглиф считать разновидностью "лигатуры", то суррогатная пара в качестве такой "лигатуры" ничем не хуже, чем закодированный способ клавиатурного ввода (а на самом деле, видимо, лучше - ввиду большей экономности).
Но тут возникает другой вопрос.
Когда я смотрю на кодировку кириллицы в UTF-8, у меня возникает стойкое ощущение,
что в этом случае уже русские буквы оказываются двухбайтовыми "лигатурами". Причём операции, которые кажутся для русского языка "элементарными" (с точки зрения не-программиста), оказываются вовсе не такими уж простыми для
программиста (скажем, преобразование регистра). Всё это кажется некоторым издевательством над русским языком и некоторой противоестественностью. В кодировке UTF-16 этого нет. И для русского восприятия в этом плане вроде как UTF-16 лучше, чем UTF-8.
Но если кодировку UTF-16 подсунуть китайцам и объяснить им, что некоторые иероглифы - это такие "лигатуры" в виде суррогатных пар, у них тоже будет ровно такое же ощущение "издевательства" над языком? У них столь же естественно желание легко выделять начало "лигатуры"-иероглифа? И нет ли такого, что основные общеупотребительные иероглифы в UTF-16 укладываются в 2 байта, а 4-байтными оказываются только весьма редкие?
Я даже глянул, как кодируются в Юникоде некоторые популярные китайские иероглифы. Некоторые в UTF-16 требуют два байта, а в UTF-8 - три. То есть вроде как и китайцы должны любить UTF-16 больше, чем UTF-8?
Эти вопросы имеют ещё вот какой подтекст. Некоторые люди считают, что UTF-8 лучше, чем UTF-16, и что Майкрософт (в отличие от линуксоидов) сделал ошибку, когда основной кодировкой для системных вызовов Windows принял UTF-16, а не UTF-8 (как у линуксов). Но вот пока что я склоняюсь больше к правоте Майкрософта. И вроде как это решение должно нравиться больше не только русским, но и китайцам.
Какова конечная цель? Призываете к смене стандарта?
Для многих случаев UTF-16 лучше и используют именно её, тем более если это критично (или что-то ещё более эффективное). Местный пример - текст базы Лингво.
Основная фича UTF-8, сделавшая её стандартом - обратная совместимость. Исторические причины + для подавляющего числа случаев обработка текста не узкое горлышко и кодировки легко друг в друга конвертируются. То самое "достаточно хорошо".
Ещё очень свеж в памяти переход на неё со старых неюникод кодировок в вебе (utf8 всего несколько лет назад стал абсолютным стандартном, когда вопросы "какую кодировку использовать" перестали появляться), это ли не громадный прогресс? Даже если есть что-то лучше, переход на новое сути не изменит, только внутренности. Проблема кодировок для пользователей можно считать решённой. Слава Юникоду!
Несомненно только, что кодировки это бездна.
2018.05.03И виноград Я даже глянул, как кодируются в Юникоде некоторые популярные китайские иероглифы. Некоторые в UTF-16 требуют два байта, а в UTF-8 - три. То есть вроде как и китайцы должны любить UTF-16 больше, чем UTF-8?
Ещё куча китайских сайтов сидят на своих старых кодировках. Они гораздо медленней переходят, видимо из-за всех этих китайских стен.
Сейчас глянул, все основные уже перешли, но пару лет назад кое что парсил с небольших сайтов, обплювался весь (там какие-то дикие сложности с конвертацией странных иероглифов, за пределом моего понимания, весь скрипт ложили)
Любви тут нет, о кодировках мало кто знает. А кто знает что и зачем и так использует их так, как считает нужным, где это важно.
Т.е. имеет смысл говорить только о смене стандарта в вебе или где ещё текст массово используется. И становится понятно, что выгода невелика.
2018.05.02И виноград При наборе иероглифа на компьютере китайцы всё равно используют обычную клавиатуру и набирают последовательность ключей. Эту последовательность ключей и нужно записывать в компьютере при кодировании текста. Иероглифы же получаются объединением последовательных ключей абсолютно по тем же принципам,
как буквы объединяются в лигатуры: При графическом отображении текста несколько подряд идущих ключей нужно изобразить одним знаком.
То, что вы описали выше, возможно (возможно!) справедливо для корейских иероглифов, но не для китайских.
Цитата:С учётом внесённых поправок, мне пока представляется такая картина.
Конкретно китайцы что-то набирают на обычной клавиатуре. Пускай пиньинь.
Всё равно комбинаций кнопок, набираемых последовательно или одновременным комбинированием, совсем не много: несколько десятков.
Вот их-то и представляется целесообразным сохранять в качестве компьютерной записи текста.
Проблема же отображения сохранённого текста путём формирования иероглифов - это другая проблема,
которую нужно решать по тем же принципам, как формируются лигатуры в европейских языках.
То есть составить "словарь" лигатур, и каждой лигатуре сопоставить свой алгоритм начертания (кодирование векторной графики).
Хотелось бы понять, почему китайцы так не делают? Или делают?
Работу китайского IME будет правильнее сравнить с автокоррекцией на клавиатуре смартфона. Вы набрали только одну букву, а она уже предлагает целые слова. При этом, в зависимости от предыдущего выбора, она самообучается, и каждый раз порядок предлагаемых слов будет разным.
И это правильно. Системы набора должны быть в первую очередь оптимизированы по скорости набора. И к кодировке не должны иметь прямого отношения.
2018.05.03 бкрс Какова конечная цель? Призываете к смене стандарта?
Вопрос вначале возник в основном в связи с проблемой обучения начинающих российских программистов. Хочется, чтобы всё было просто и логично, с точки зрения человека, который не знает других языков, кроме русского и английского. И чтобы программы, написанные таким человеком, оказывались интернационализированными автоматически.
И вроде бы кажется, что с большинством языков так и выходит, если использовать простую двухбайтовую кодировку (типа UCS-2 = UTF-16 без суррогатных пар).
Большая нужность кодирования символов типа кучки дерьма (U+1F4A9) не кажется очевидной.
Что нарушает эту простую и стройную картину? Действительно ли нужны расширения двухбайтовой схемы для кодирования китайского языка? И если они действительно нужны, то нужно ли российскому программисту знать о существовании суррогатных пар? Нужен ли вообще этот термин "суррогатная пара"? Или же терминологию можно построить таким образом, чтобы российский программист мог бы ничего такого не знать, и при этом писать всю жизнь отличные интернационализированные программы, пригодные и для китайцев?
Если совсем огрублять, будет ли самосогласованной и всеобъемлющей такая точка зрения, что кодировка UTF-16 является исключительно 2-байтовой, но некоторые пары символов графически принято изображать лигатурами (в том числе китайскими иероглифами)?
2018.05.03И виноград Вопрос вначале возник в основном в связи с проблемой обучения начинающих российских программистов.
К программированию тема кодировок почти никакого отношения не имеет. Программистов, скорее, надо начинать учить со штудирования Кнута (чтобы мозги на место встали), Кайта (чтобы знать, как работает хорошая база данных), ассемблера (чтобы знать как оно "на самом деле") и численных методов. Потом уже этот математический и низкоуровневый базис дополнять изучением компилируемого языка (типа си/дельфи) и скриптового (типа perl/php/python). А все вопросы кодировок это 0.001% от задач программиста и почти никакого отношения к реальной работе не имеют.
В программировании сейчас настолько много разных технологий и движков, что если программист будет тратить сначала день на изучение кодировок, потом день на освоение регулярных выражений, потом неделю на ANSI SQL, то он и за пять лет не освоит необходимый минимум.
|
