Автор хотел бы обсудить некоторые недостатки текущей версии юникод и обсудить дальнейшие пути его совершенствования. Проблема на наш взгляд состоит в том, что unicode.org не систематизировала результаты своей работы (с чем она согласилась в процессе переписки unicode.org/cgi-bin/swish-uml-cgi.pl?query=Dmitry%20Turin&sort=sent), в результате чего не одна компьютерная индустрия понесла потери. Если просуммировать - масштабы будут очень велики.
Во всех программах - поисковых серверах, базах данных, CAD-системах, текстовых редакторах - необходимо искать слова и сравнивать варианты написания слова: все буквы строчные, первая буква прописная, все прописные буквы. Кроме того, пользователь иногда пишет в строке поиска с ошибками или озаглавливает искомый объект с ошибками - одна лишняя буква, одной буквы не хватает, одна буква изменена. Если в кодировке прописную букву обозначать строчной с дополнительным байтом впереди, то сравнение вариантов написания сводится к поиску с опечаткой, а значит один алгоритм можно уже не реализовывать. К тому же освободится половина мест в таблице кодировки, можно разместить больше символов (ISO уже застолбила стандарт 4-байтной кодировки под названием ISO 10646). Префиксным байтом можно маркировать имена собственные и аббревиатуры на языках без прописных букв, что в дальнейшем поможет поисковым серверам. На степени архивации текста нововведение никак не сказывается. В деталях оно выглядит следующим образом.
В тех случаях, когда встречается имя собственное или начало предложения,
поставить один префиксный байт перед словом
(будем условно изображать его как
),
чтобы указать, что следующая за ним буква прописная
(anna → Anna).
Назовем этот префиксный байт знаком "имя собственное"
.
Аналогично для аббревиатур,
достаточно одного префиксного байта
перед словом, чтобы указать,
что все буквы до следующего пробела прописные
(uno → UNO).
Назовем этот байт знаком "аббревиатура"
.
Пользователь по-прежнему ставит префиксы сам, нажимая клавиши "Shift" и "Caps Lock".
На взгляд автора международная организация поступила очень недальновидно, выбрав расточительное кодирование. И повторила распространенное заблуждение, отождествив обозначение букв (кодировку) и их графическое изображение (шрифт). Это совсем разные вещи.
Индексы прочно вошли в нашу жизнь: без них невозможно такое социальное явление, как наука - разумеется, без них немыслима такая всеохватывающая индустрия, как программирование. Поражает убогий, пещерный способ записи индексов в текстовых файлах - с помощью квадратных скобок. Он заставляет нас воссоздавать математические записи в своем воображении. Поднимая вопрос на принципиальную высоту, то же самое нужно сказать о пределах интегрирования и суммирования. Мы могли бы видеть индексы и пределы "на своих местах" в обыкновенных текстовых файлах, а не только в системах типа MathCAD, если бы у нас была разумная кодировка для них. Например, такая.
Пусть база - надпись, для которой индексы и пределы записываются,
индексы и пределы вместе назовем довесками,
и пусть управляющие символы
,
,
,
обозначают, что с них начинаются
нижний предел, верхний предел, нижний индекс, верхний индекс
.
Между базой, управляющими символами и довесками нет никаких пробелов,
и вместе они составляют одно слово.
У пределов бывают индексы, у индексов - субиндексы.
Будем использовать управляющие символы как вложенные открывающие скобки,
а не предварять довесок таким их количеством подряд,
на каком уровне вложенности довесок находится.
Однако чтобы вернуться на один уровень вложенности назад,
потребуется еще один управляющий символ "возврат"
.
Таким образом слово
Также убого выглядит невозмножность записать в текстовом файле общеупотребительные формулы с корнем, дробью, интегралами и фигурными скобками. А ведь все эти символы в таблице кодировки есть, но конформизм не позволяет проинтерпретировать их как управляющие. Неоднозначность только в том, какой символ - слэш или обратный слэш - использовать для обозначения дроби. Символ слэш оставим - вдруг кому-то захочется созерщать скрытую красоту выражений 1/2 или 3/4 - и обратимся вместо него к символу обратный слэш. Таким образом выражение (a+b+c)\(d+e) должно отображаться как , а выражение (a+b)(c+d) - как . Такие конструкции легко рисуют все математические программы, и виртуозно опознают, на какое из слагаемых пользователь передвинул курсор стрелками на клавиатуре или мышью. Еще проще поведение трех пар скобок и двух интегралов (простого и кругового ) - открывающие скобки и интегралы равны по высоте следующему за ними выражению, закрывающие скобки - предшествующему.
Существует два принципиально разных вида диакритических знаков.
Первые - будем называть их диакритическими некомпактами
-
входят в состав буквы и являются ее неотъемлемой частью,
примерами чего являются все буквы латинского, кириллического,
а также согласные арабского алфавитов.
Вторые - будем называть их диакритическими буквами
- обозначают отдельную букву,
примерами чего являются все гласные
индо-арийских, дравидийских, арабского, еврейского алфавитов.
В этих языках не горизонтальное и не вертикальное направление письма, а чередующееся
(следующая буква может быть как над или под предыдущей, так и после),
и только фильтр в голове не позволяет это увидеть.
Кодирование двух букв - обычной и диакритической - в любом случае потребует двух байт. Если кодировать обычные и диакритические буквы по-отдельности и отображать последние не в следующем знако-месте, а в предыдущем путем операции "or" с ним, то редактирование одной буквы слога не потребует замены кода другой буквы, т.е. не потребует замены кода всего слога целиком. Операция "or" выполняется с одним и тем же знакоместом для всех подряд идущих диакритических букв (см. примечание для индо-арийских алфавитов). Представляется, что международная организация unicode.org поступила нерачительно, даже не попытавшись свести многомерную задачу к одномерной.
В Индии существует множество родственных индо-арийских языков. У них очень разные алфавиты. Можно было бы обычные и диакритические буквы (или слога) разных языков, обозначающие один и тот же звук, кодировать одинаково, а для придания начертания, соответствующего тому или иному языку, добавлять перед текстом два байта - управляющий символ и номер языка. Тогда житель Индии, не знающий алфавита своего соседа, мог бы прочитать сообщение на своем алфавите (звучало бы оно наверное также, как для русского, читающего на беларусском или украинском), не перекодируя весь текст, а только изменив один байт - номер языка. Одного байта на идентификатор языка хватит - на планете используется только 67 алфавитов.
Аналогично, в Индии существует множество родственных дравидийских народов. И у них тоже сильно отличающиеся алфавиты. И их тексты также можно было бы перекодировать, изменяя только один байт. А чтобы не увеличивать количество идентификаторов языка, коды букв дравидийского алфавита могли бы продолжать коды букв индо-арийского. Для удобства запоминания идентификаторов, пусть они обозначают алфавиты по часовой стрелке в порядке следования по окружностям на географической карте: малаялам - каннара - телугу - тамильский, деванагари - гуджаратский - гурмукхи - ассамский - бенгальский - ория - сингальский.
Номер языка мог бы нести дополнительную функцию. Для индо-арийских, дравидийских и еврейского алфавитов - включать механизм отображения диакритических букв (см. под-заголовок в этой статье "Два вида диакритических знаков"). Для арабского - переводить курсор на новую строку, включать отображение букв справа налево (слова не нужно было бы выравнивать по правому краю в языке разметки текста или в проприетарным формате файла), выбор нужного варианта начертания буквы в зависимости от положения (вначале слова, в середине, в конце, в изолированном состоянии), а также специфическое не-европейское начертание цифр и трех знаков пунктуации (запятая, точка с запятой, вопросительный знак). Для корейского - включать алгоритм упаковки букв в иероглифы по часовой стрелке. Будем называть далее все печатные символы, приходящиеся на один и тот же идентификатор языка, страницей.
Две сотни символов той страницы, которая выбирается автоматически, если не указана в начале текста, желательно отдать под знаки, обслуживающие переписку наибольшего количества людей на земле. А не кодировать некоторые из таких языков (в т.ч. русский) двумя байтами, как в UTF-8. Экономия локальных накопителей информации и международного трафика очевидна. В одну страницу вполне влезают латинница, кириллица и греческий. Расположение этих букв и рассмотрим.
Латинницу ( 103 буквы которой можно также увидеть в Большой Советсткой Энциклопедии) и кириллицу ( 89 букв, также в БСЭ) внесем в кодировку целиком, а не многократно в виде их подмножеств. Также чтобы избежать дублирований постараемся выбросить из кириллицы символы, повторяющие символы латинницы, и разместить оставшиеся посреди латинницы, не нарушая порядок сортировки. Примем компромиссы. Первый, буквы 'c' и 'l' (а также вариант первой с диакретиком) расположены в латиннице в начале, а в кириллице в конце, выбрасывание их в одном слишком бы нарушило сортировку в другом, поэтому расположим буквы дважды. Второй, четверть букв 'a' (три штуки) можно расположить один раз, сохраняя сортировку только в одном из алфавитов - расположим один раз и сохраним в латинском, т.к. все три буквы с диакретиками: на нерусских языках публичные базы данных находятся в зачаточном состоянии, и к порядку букв в них еще никто не привык (а на случай, если бы такая привычка уже возникла, участки расположения всех букв 'a' в обоих алфавитах одинаковы, и использование латинского порядка только для трех из них не обнаружится при поиске слова на основе минимального количества перестановок букв). Итого 177 букв. Букву 'o' удалим из греческого, часть алфавита до нее (14 букв) разместим перед латинско-кириллическим, а часть (9 букв) - после. Начертание буквы "сигма" пусть зависит от настроек ОС, вместо того, чтобы присутствовать этой букве в двух местах алфавита - как уже было сказано, не надо путать кодировку и шрифт, кодировка должна быть одна для всех начертаний, обозначающих одну и ту же букву.
Математические символы и спец-символы расположим не на той же странице, где алфавит науки (греческий), а на отдельной странице, т.к. их количество будет все время увеличиваться, и неизвестно, какие же из них будут в разные моменты времени наиболее употребительными.
На каждой странице и в одних и тех же местах расположены цифры; знаки припинания; в т.ч. спецсимвол для обозначения ударений, отличный от диакретиков; знаки арифметических операций; скобки; управляющие символы, чтобы не переключать страницы только из-за этих символов при переписке на одном алфавите. Каждое из этих подмножеств не перемежается с другими, чтобы можно было определять принадлежность символа к подмножеству всего двумя операциями сравнения (для верхней и нижней границ). Исключения составляют, с одной стороны, знаки "имя собственное" и "аббревиатура", с другой - "перевернутые" восклицательный и вопросительный знаки. Первые существуют только на латинско-кириллико-греческой и армянской страницах; а перевернутые знаки, встречающиеся только в испанском и к тому же одновременно с нормальными, существуют только на латинско-кириллико-греческой странице.
И будем использовать два символа-переключателя страницы подряд для перехода на двухбайтную кодировку - для иероглифов и букв, перемежающихся с иероглифами, т.е. кроме хираганы и катаканы в двухбайтной кодировке закодированы еще раз корейский и латинница (смесь последней с иероглифами встречается во вьетнамском). Разумеется, в двухбайтной кодировке какой-то символ должен переключать назад в однобайтную.
Давайте посмотрим правде в глаза - текст не обходится без разметки. То там нужно жирностью выделить, то здесь нужно гипер-ссылку поставить. Однако ни один из многочисленных языков разметки или проприетарных форматов файлов невозможно скормить видео-карте непосредственно, что ложится лишней головной болью и ОС, и на ПО, и не везде можно эти языки и проприетарные форматы применить. Предлагаю для цвета, наклона, подчеркивания, размера шрифта и жирности как для действительно используемых ввести обозначение прямо в текстовом файле. Давайте перестанем сопротивляться и примем необходимое (а не "всё", как боятся некоторые самозабвенные критики). Пояснения требует разве что изменение размера шрифта посреди текста. Есть такое понятие - агрессивный пейзаж. Это - длинная повторяющаяся последовательность, например, одинаково окрашенные окна на однотонной стене (вы заметили, строители разукрашивают стены как матрешки?), или череда гипер-ссылок шрифтом одного размера. Да-да, именно поэтому вы периодически встречаете сайты, на которых куча ссылок дана шрифтами разного размера - чтобы глаз имел опорные знаки внутри этого участка текста.
Перед выделяемой фразой разместим управляющие символы "начало фракции"
и "середина фракции"
,
а после нее - символ "конец фракции"
.
Между первыми двумя управляющими символами находятся
байт-предсказатель
и (опционально) фракционная запись
.
В байте-предсказателе используются семь бит, первые три из которых указывают,
какие поля присутствуют во фракционной записи
(если все три бита равны нулю,
значит длина фракционной записи равна нулю, т.е. ее нет совсем).
А содержать она может целочисленные
цвет, размер шрифта и некоторый идентификатор,
которым метится данный участок текста
(этот идентификатор выполняет ту же роль, что и якорь HTML,
и сообщается видеокартой программному обеспечению,
когда пользователь кликает на фразу).
Последние четыре бита байта-предсказателя указывают,
что фраза подчеркнута, жирная, наклонная или имеет тень.
Условимся участок текста от символа "начало фракции" до
символа "конец фракции" называть фракцией,
и договоримся, что фракции не могут быть вложенными
- для упрощения аппаратуры, отображающей текст.
Дмитрий Тюрин (DmitryTurin.narod.ru):
dima.turin@centrum.cz
(все письма из домена .ru попадают в спам),
dima.turin@gmail.com