Лингвофорум

Итак, все знают, что мне ся не нравит Уникод. Я хочу свою кодировку.

Итак, я потихоньку буду пилить свою кодировку. Мои требования:

• Unencumbered with compatibility. Совместимость с уникодом не нужна, с ASCII — не знаю.
  
• Для вывода не нужна дополнительная база данных (кроме шрифта); все свойства символа можно узнать их его позиции.
  
• Слишком редкие буквы не нужны; никаких египетских иероглифов — для них есть Manuel de Codage.
  
• Двухбайтовая кодировка. Воистину двухбайтовая, а не как Уникод.
  
• Precombined буквы не нужны; комбайнов — побольше.
  
• Иероглифы — по максимуму комбайны.
  

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

Мне хочется, чтобы комбайны записывались в обратном порядке: á — не как <латинская строчная буква а><комбинируемый акут сверху>, а как <комбинируемый акут сверху><латинская строчная буква а>. Хотя не уверен.

---

Начать я решил с иероглифов. Очевидно, что подавляющее большинство иероглифов можно разбить на составные части. Так, «問» можно закодировать символами <комбинируемые традиционные ворота сверху><рот>.

Для этого я взял список разбиений иероглифов (http://lingvowiki.info/w/%D0%94%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BE_%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D1%85_%D0%B8%D0%B5%D1%80%D0%BE%D0%B3%D0%BB%D0%B8%D1%84%D0%BE%D0%B2_%D0%93%D1%8D%D0%B2%D0%B8%D0%BD%D0%B0_%D0%93%D1%80%D1%83%D0%B2%D0%B5%D1%80%D0%B0), составленный Гэвином Грувером, и отобрал самые частые сочетания. Их можно увидеть в файле res-hanzis.txt. Прошлый файл, который у Юуургена в блоге, не совсем верен: там были баги в скрипте. Есть также файл res-entries.txt, в нём данные по всем элементам, в том числе кускам иероглифов без самостоятельного уникодного кода.

Формат файла такой:
2498       a:f:氵
2024       a:f:口
1989       a:f:木
1917       a:f:扌
1838       d:f:艹
Так, первая строка значит: есть 2498 иероглифов, которые разбиваются по типу a (по горизонтали) с 氵 в качестве первого (f — первый, l — последний) компонента. То есть введение одного только символа <комбинирующаяся трёхточечная вода слева> может сократить количество требуемых кодовых мест на 2497! (Хотя дальше выгода будет меньшей. Например, если ввести <комбинируемую 去 справа>, то в иероглифе 法 всё равно будет использоваться обычная 去.)

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

Цитата: Вывод скрипта
Limit is 3: 9348 codepoints: 2138 hanzi, 7210 combining characters.
Limit is 4: 7992 codepoints: 2565 hanzi, 5427 combining characters.
Limit is 5: 7358 codepoints: 2945 hanzi, 4413 combining characters.
Limit is 6: 7077 codepoints: 3347 hanzi, 3730 combining characters.
Limit is 7: 6944 codepoints: 3711 hanzi, 3233 combining characters.
Limit is 8: 6948 codepoints: 4077 hanzi, 2871 combining characters.
Limit is 9: 7019 codepoints: 4457 hanzi, 2562 combining characters.
Limit is 10: 7076 codepoints: 4758 hanzi, 2318 combining characters.
Limit is 11: 7182 codepoints: 5069 hanzi, 2113 combining characters.
Limit is 12: 7367 codepoints: 5420 hanzi, 1947 combining characters.
Limit is 13: 7492 codepoints: 5690 hanzi, 1802 combining characters.
Limit is 14: 7618 codepoints: 5927 hanzi, 1691 combining characters.
Limit is 15: 7869 codepoints: 6291 hanzi, 1578 combining characters.
Limit is 16: 8125 codepoints: 6653 hanzi, 1472 combining characters.
Limit is 17: 8328 codepoints: 6944 hanzi, 1384 combining characters.

Таким образом, оптимальным представляется брать N в 7—8 символов. Числа настолько радуют, что закрадывается сомнение, не ошибся ли я где.  ;D Кроме того, у Грувера иногда декомпозиции слишком «суровые», мы не будем следовать им всем. Но, думаю, в любом случае, больше, чем 20000 кодовых мест иероглифы с таким подходом явно не займут.

---

Дискас.

Цитата: fujhi от июля 17, 2012, 12:00

• Двухбайтовая кодировка. Воистину двухбайтовая, а не как Уникод.
  

То есть таки несовместимая с ASCII?

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

Цитата: fujhi от июля 17, 2012, 12:00
все свойства символа можно узнать их его позиции.

Что имеется в виду?

Цитата: Hellerick от июля 17, 2012, 12:31
То есть таки несовместимая с ASCII?

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

Планируется использовать для себя, конечно же. Я не оставляю надежды сделать свою операционную систему (хочу что-нибудь типа colorForth'а)...

Под совместимостью с ASCII понимается то, что первые 127 букв будут такие же. Хотя я не уверен, что мне такое чудо нужно́.

Цитата: Hellerick от июля 17, 2012, 12:31
чем это лучше Юникода?

Легче обрабатывать (никаких суррогатных пар), легче написать рендерер. Дополнительная плюшка: можно придумывать свои иероглифы.

Цитата: Тайльнемер от июля 17, 2012, 12:31

Цитата: fujhi от июля 17, 2012, 12:00
все свойства символа можно узнать их его позиции.

Что имеется в виду?

Что-то вроде такого:
(* Псевдокод *)
FUNCTION isLower(c: CHAR): BOOLEAN;
VAR
  code: Word;
BEGIN
  code := Ord(c);
  isLower := Odd(code) AND (code >= #80) AND (code <= #2000);
END;

FUNCTION isDiacritic(c: CHAR): BOOLEAN;
BEGIN
  isDiacritic := Ord(c) >= #8000;
END;

Цитата: fujhi от июля 17, 2012, 12:48
Под совместимостью с ASCII понимается то, что первые 127 букв будут такие же. Хотя я не уверен, что мне такое чудо нужно́.

Это усложняет реализацию toLower и toUpper: я хотел, чтобы маленькие буквы шли прямо после больших. Возможно, сделаю «совместимую ASCII-латиницу», которая выводится красным цветом в текстах и всегда моноширинна (для идентификаторов в компиляторе, etc) и «настоящую латиницу», выводимую чёрным цветом (для собственно текстов). Хотя Оккам негодуэ... Не знаю.

Что если придумывать не кодировку, а «язык мультискриптой разметки», позволяющий записать любой текст в plain ASCII файле?

Цитата: Hellerick от июля 17, 2012, 13:14
Что если придумывать не кодировку, а «язык мультискриптой разметки», позволяющий записать любой текст в plain ASCII файле?

Придумывайте, я Вам не мешаю. :donno: Но на практике реализовывать этот мультскриптовый ввод очень муторно, все задолбаются. Я честно пробовал (когда редактор ЛингвоКода писал) и задолбался.

А я хочу что-то простое. Проще, чем уникод, но функциональнее, чем ASCII.

Русская "А" и латинская "A" - один и тот же символ?

Цитата: Alone Coder от июля 17, 2012, 15:13
Русская "А" и латинская "A" - один и тот же символ?

Не знаю. Пока что не решил. А как Вы думаете: как лучше?

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

Я думаю, лучше не изобретать велосипеды. Даже на Спектруме пользуются стандартными кодировками.

Цитата: Alone Coder от июля 17, 2012, 15:33
Я думаю, лучше не изобретать велосипеды. Даже на Спектруме пользуются стандартными кодировками.

Это какими? Как выглядит стандартная спектрумовская кириллическая кодировка?

(На своем Спектруме я пользовался смесью из кириллицы и латиницы)

CP866.

Цитата: Alone Coder от июля 17, 2012, 15:38
CP-866.

А разве использование старших кодов под команды встроенного Бейсика не мешает?

Нет. Это личное дело Бейсика, к текстовым редакторам не имеет отношения.

Цитата: Alone Coder от июля 17, 2012, 15:33
Я думаю, лучше не изобретать велосипеды.

Кому от этого лучше? Я не изобретал бы, если бы мне нравились существующие.

Из существующих кодировок мне нравится разве что CangJie, но а) доступны только старые версии, новых в открытом доступе нет, б) она всё равно слишком сложна из-за того, что это одновременно кодировка и метод ввода [фрикобред про «китайские гены» (https://zh.wikipedia.org/zh-hant/%E6%BC%A2%E5%AD%97%E5%9F%BA%E5%9B%A0) опустим], в) непонятно, как туда вписать кириллицу (кодировать её как zea = а, zeb = б, zec = в, что ли?).

Вариант Хеллерика же — делать надстройку над существующими кодировками — слишком неудобен. Получается двухуровневое кодирование, усложняется работа с встроенными символами... И вообще, нехорошо это — сущности плодить.

Цитата: Alone Coder от июля 17, 2012, 15:33
Даже на Спектруме пользуются стандартными кодировками.

Если равняться, то лучше на colorForth. Там вообще своя кодировка, со встроенным сжатием по Хаффману с учётом частотности букв в английском. Но там только латиница, мне же хочется некоторой многоязычности и простора.

Цитата: fujhi от июля 17, 2012, 15:56
Вариант Хеллерика же — делать надстройку над существующими кодировками — слишком неудобен.

Это мой вариант? :what:

Впрочем, повторюсь, я не понимаю, чего вы добиваетесь.

Цитата: Hellerick от июля 17, 2012, 16:10

Цитата: fujhi от июля 17, 2012, 15:56
Вариант Хеллерика же — делать надстройку над существующими кодировками — слишком неудобен.

Это мой вариант? :what:

Ну-у-у... Предложенный Вами. Вы же предлагаете создавать надстройку над ASCII.

Цитата: Hellerick от июля 17, 2012, 16:10
Впрочем, повторюсь, я не понимаю, чего вы добиваетесь.

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

Уникод не удовлетворяет первому требованию, Windows-1251 — второму [KOI-8 не удовлетворяет обоим ;D].

Цитата: fujhi от июля 17, 2012, 15:56Я не изобретал бы, если бы мне нравились существующие.

Цитата: Большое количество новых распространенных операционок свидетельствует о том, что народ существующими недоволен. (http://lingvoforum.net/index.php/topic,28846.msg673401.html#msg673401)

;D

Цитата: fujhi от июля 17, 2012, 16:14

Цитата: Hellerick от июля 17, 2012, 16:10

Цитата: fujhi от июля 17, 2012, 15:56
Вариант Хеллерика же — делать надстройку над существующими кодировками — слишком неудобен.

Это мой вариант? :what:

Ну-у-у... Предложенный Вами. Вы же предлагаете создавать надстройку над ASCII.

ASCII — это не «кодировки», это — «The Кодировка».

А чем вас не устраивает принцип расширяемости до бесконечности, заложенный в той же UTF-8?

Цитата: Bhudh от июля 17, 2012, 16:29

Цитата: Большое количество новых распространенных операционок свидетельствует о том, что народ существующими недоволен. (http://lingvoforum.net/index.php/topic,28846.msg673401.html#msg673401)

;D

tl;dr

Да и следует отличать «народ» от «я». Я ничего для народа делать не собираюсь. Я руководствуюсь исключительно своим вкусом.

Цитата: fujhi от июля 17, 2012, 16:46tl;dr

Γτητδτλβ...

Цитата: Hellerick от июля 17, 2012, 16:44
ASCII — это не «кодировки», это — «The Кодировка».

Одно второму не мешает. ;D

Цитата: Hellerick от июля 17, 2012, 16:44
А чем вас не устраивает принцип насширяемости до бесконечности, заложенный в той же UTF-8?

Сложностью реализации, кларо же. Это расширяемость à la C++: добавлять кучу новых вещей, частично перекрывающих уже существующие. Я хочу расширяемость à la Scheme: мало кирпичиков, из которых можно сложить всё то же и даже больше.

Цитата: Bhudh от июля 17, 2012, 16:48
Γτητδτλβ...

Гтитдтлб? ЧЗБ?

Еджвк? ЧЗБ?

我唔明白。

Цитата: fujhi от июля 17, 2012, 16:46tl;dr

→

еджвк

Γτητδτλβ... → Переведи...

Цитата: fujhi от июля 17, 2012, 12:00
То есть введение одного только символа <комбинирующаяся трёхточечная вода слева> может сократить количество требуемых кодовых мест на 2497! (Хотя дальше выгода будет меньшей. Например, если ввести <комбинируемую 去 справа>, то в иероглифе 法 всё равно будет использоваться обычная 去.)
Выбрать, что будет выносится в комбинирующуюся диакритику, предлагаю статистически — если элемент используется в какой-то роли в N или более иероглифах, то ему выделяется соответствующий код.

Я ничего не понимаю в китайском :( поэтому мне сложно понять, что имеется в виду.
Правильно ли я понимаю, что вы предлагаете для каждого простого иероглифа (типа 口) ввести помимо основного код-пойнта ещё несколько дополнительных код-пойнтов, содержащих тот же иероглиф в роли диакритики того или иного типа?
Если так, то не проще ли выделить несколько код-пойнтов, обозначающих только тип диакритики, или тип разложения иероглифа на части, и представлять иероглиф в виде этого маркера типа и составных частей?
___________________

Кстати, как бы вы разложили хангыль?

Цитата: Тайльнемер от июля 18, 2012, 10:40
Правильно ли я понимаю, что вы предлагаете для каждого простого иероглифа (типа 口) ввести помимо основного код-пойнта ещё несколько дополнительных код-пойнтов, содержащих тот же иероглиф в роли диакритики того или иного типа?
Если так, то не проще ли выделить несколько код-пойнтов, обозначающих только тип диакритики, или тип разложения иероглифа на части, и представлять иероглиф в виде этого маркера типа и составных частей?

Не думаю, что проще. С моим подходом задача «прочитать одну букву» делается достаточно просто — «прочитать всю диакритику [т.е. символы с кодом больше определённого числа] аж до не-диакритика» (или, если делать диакритику после символа, как в уникоде, то «прочитать один не-диакритик и всю диакритику вплоть до следующего не-диакритика»; но тогда нужен lookahead).

Если делать «комбинации», то «взять символ; если это комбинатор, рекурсивно вызвать себя же дважды; [потом прочитать всю диакритику — впрочем, диакритику тоже можно рассматривать как комбинации тогда]» (ведь подкомпоненты тоже могут быть комбинациями) — это гораздо сложнее.

Кроме того, я не думаю, что в китайском так уж нужны совершенно рандомные комбинации. Самыми частыми являются сочетания любого иероглифа (от него берётся чтение) с небольшим количеством семантических компонент. Т.е. в большинстве сочетаний фонетики бывают очень разными, а семантические компоненты — всегда одни и те же (言， 木， 口, 金), при чём у них фиксированное положение.

Кроме того, среди семантических компонентов много таких, которые не являются самостоятельными иероглифами (疒, 辶). А ещё больше таких, которые теоретически являются полноценными иероглифами, но настолько сильно видоиземнёнными, что кодировать их одинаково не представляется желательным (水 = 氵, 手 = 扌, 艸 = 艹, 人 = 亻, 火 = ⺮, 心 = 忄).

Цитата: Тайльнемер от июля 18, 2012, 10:40
Кстати, как бы вы разложили хангыль?

Не знаю. Я ни в зуб ногой в корейском. :(

А как по-Вашему лучше?

http://hanzijs.com/character/艸
:???

Цитата: Bhudh от июля 18, 2012, 12:29
http://hanzijs.com/character/艸
:???

Что не так?

Поццему не на 2? :donno:

Цитата: Bhudh от июля 18, 2012, 12:33
Поццему не на 2? :donno:

На совести Грувера. Впрочем, иероглиф редкий и никому не нужный.

Цитата: Bhudh от июля 18, 2012, 12:33
Поццему не на 2? :donno:

На два чего?
Этот «трезубец» разве является отдельной графемой?

Цитата: Hellerick от июля 18, 2012, 12:38

Цитата: Bhudh от июля 18, 2012, 12:33
Поццему не на 2? :donno:

На два чего?
Этот «трезубец» разве является отдельной графемой?

屮
Гм, ялвяется...

Что делать с парами прописная-строчная буква? Всегда и всюду следовать порядку AaBbCc и т.д.?

Цитата: Hellerick от июля 18, 2012, 12:43
Что делать с парами прописная-строчная буква? Всегда и всюду следовать порядку AaBbCc и т.д.?

Не знаю. Я думал так, хотя не знаю.

С одной стороны, заманчиво кодировать их отдельно: <прописная буква><С>. Так легче работать с текстом (замена «слон» на «верблюд» автоматически заменит «Слон» на «Верблюд»). Но тогда all-caps выглядит тупо, и непонятно, что делать с комбинациями типа <прописаная буква><9>.

---

Кстати, можно числа вообще хранить как числа. Т.е. <десятичное число><...>. (Понятно, что 0 так лучше не кодировать. Хотя...).

Так автоматически получаем:

• natural sort без забот,
  
• расширяемость для римских/индийских цифр,
  

Но получаем такие проблемы:

• если число >#x7fff (не выходить же в область диакритики...),
  
• как записать 0? (не нулевым кодом же...) Прибавлять ко всем числам какое-то начальное значение?
  

В colorForth'е ввели понятие «слова». У каждого слова есть тип (с прописной буквы, все прописные, цифра)... Но это как-то по-инопланетянски. По сути, при таком подходе понятие «plain text»'а тогда вообще пропадает: есть только текст как массив слов.