Руководство по Фокалу

Частенько встречается так-же КОИ-8, активно использовавшаяся у нас годах в

семидесятых — девяностых. (По ГОСТу 19768-74, а семибитная КОИ-7 аж еще с

шестидесятых: ГОСТ 13052-67.) В UNIX`e (а Linux это тоже разновидность UNIX`а)

это стандарт де-факто. Братья-славяне давятся кодировкой 855, тоже ДОС`овской,

где славянских (в том числе не нужных в русском языке) букв больше чем в 866,

но расположены они весьма неудобно, а псевдографика — не вся. Комитет ИСО

было расстарался эти самые кодировки хоть как-то стандартизировать, и пытаясь

угодить всем, как тот слон из басни, учинил их аж шестнадцать штук. Но в

основном для себя любимых. А для нас — ISO 8859.5 старшая часть которой почти

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

Ну так там псевдографики вообще нету.

Общее у всех перечисленных в том, что все они — расширения так называемой

ASCII. И все (кроме уникода) — восьмибитные. Семибитный ASCII у них у всех -

четыре младших "страницы" по 32 символа. (В семибитном КОИ-7 — три.)

Представляет так же некоторый интерес ебздиковская производная ДКОИ,

использовавшаяся на машинах ряда ЕС-ЭВМ. (Сдуру содранных с IBM-360/370, что

небезызвестный Дейкстра назвал величайшей победой запада в холодной войне.)

И совсем уж древняя и кстати безымянная кодировка (хотя кое кто называет её

"УПП") по ГОСТ 10859-64, интересная в частности тем, что её можно было

использовать не только в семибитном, но и в шести, пяти и даже четырёхбитном

вариантах. Но содержащая только заглавные буквы и заточенная под Алгол-60.

Заслуживает упоминания так же некая кодировка "МИК" минского НИИ ЭВМ. И та,

которая используется в яблочной машинке "Макинтош". (Две последние — расширение

ASCII, а две первые — свои собственные.)

Из кодировок, не содержащих русские буквы, интерес представляют например

Radix-50, включающая всего 40 символов, но позволяющая упаковать их по три

штуки в два байта. Еще телетайпетная МТК-2 (вот там то как раз русские буквы

есть) и разные виды "транслита"...

Можно подумать, что вон мол буржуи хорошо со своей ASCII устроились...

Впринципе сначала действительно так и было задумано. Однако, латинский алфавит

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

дополнительные буквы, при чем у всех языков — разные. (А кому дополнительные

буквы не нужны, тем латинский алфавит не годится вообще! Потому как на-поверку

пишут они иероглифами, которые и изображают непроизносимыми комбинациями из

латинских букв. Или таки получаются слова, но совершенно другого языка — вот

например как для аглицкого.) А в этом самом ASCII место после латинского

алфавита, где бы эти дополнительные буквы можно было бы разместить (хотя и

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

Без которых например в языке Си ну никак не обойтись. Да и сама эта ASCII,

действительно организованная более-менее разумно — вовсе не американская, как

нас всех уверяют, а предположительно у фашистов стащена. Их нативная,

известная как "ебздик" (EBCDIC) просто безобразна и тоже существует минимум в

шести несовместимых друг с дружкой вариантах. В точности как и сам аглицкий

язык: исходный примитивизм (та самая "простота", которая хуже воровства),

желание здесь и сейчас облегчить себе жизнь, неизбежно порождает хаос и

переусложнение на следующем уровне.

Но потом появился "уникод"... Типа решили взять вообще все какие ни есть

символы и пронумеровать двадцатиразрядными (!) числами. Нет, сначала — 16-и

разрядными, что было бы еще ничего. Но потом спохватились, что шестидесяти

пяти тысяч (!) позиций для самых редких китайских иероглифов может и не

хватить... (Хотя, полагаю, скорее беспокоились о заделе на будущее.) Но как ни

тужились, смогли заполнить только около ста тысяч позиций из этого миллиона...

А сначала вообще пытались тупо узаконить имеющий место хаос, просто выделив под

каждую буковку два байта и разместив в одном её код, а в другом — номер

национальной кодировки. Наплевав на то, что большинство из них различается

всего несколькими символами...

Так что двух байтов под символ уникода видите-ли мало, а четыре — явный

перебор, да и расточительно, но бывает. Ну так оно еще может быть как старшим

так и младшим байтом вперёд! А главное — в старших байтах частенько — ноль.

В общем — маразм крепчал...

Однако, разумные люди нашлись и там — придумали то, что называется Утф-8,

вещь вполне приличную, но увы — существенно неравномерную...

Однако, это только способы записи (хранения, передачи) вот этих вот номеров

символов. Не путать с самой нумерацией! А вот сама она — гигантизм и

узаконенный хаос, пусть даже и немножко причесанный: нормальный человек

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

предположим, нужно раз в десять больше. Но там штук сорок одних только

звёздочек (тогда как нужна только одна), да и псевдографики невесть сколько

сортов, а вот кое-чего, самого, казалось бы, очевидного — нет! Нет, я понимаю,

что им надо на что-то тратить избыточную производительность: кризис

перепроизводства всё нарастает... (Это когда даже если все ходят в рванье и

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

которые всё это и производят, денег раздают меньше, чем стоит то, что они

произвели...)

Но эти растратчики ресурсов нам не указ! Нам нужно совсем другое...

Вот в данном конкретном случае нам нужна такая (промежуточная,

вспомогательная) кодировка, которая была бы не просто перечнем символов (как

тот же уникод), а позволяла бы легко распознавать их "сорта", а так же

преобразовывать их друг в дружку. Вот например как в КОИ-8, где все виды

букв — в одном и том же алфавитном порядке. В результате определить тип

буквы — по одному или двум старшим битам, а преобразовать — их изменением.

Что предполагает такую же "страничную" организацию. Но во-первых пусть

каждый алфавит занимает свою страницу целиком. (А не как в ASCII.) А во-вторых

пусть страница будет не 32, а 64 символа. Что, полагаю, будет достаточно не

только для любого алфавита со всеми его необходимыми расширениями (но без

излишеств!), но и для слоговых типов письменности. Для алфавитных письменностей

в первой половинке страницы разместим "основные" буквы, а во второй -

"дополнительные", типа нашей Ё, которыми, если что, можно пожертвовать,

преоброазовав их в "основные". А все полезные значки, включая цифры, скобки и

прочие знаки препинания — в "нулевую" страницу. При чем из "слепых" символов

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

не для управления удалённым оборудованием, как в той же ASCII...

Это:

— пробел — для разделения слов

— ПС (перевод строки — n) для разделения строк

— ** (код 0х17) "конец абзаца" — для разделения абзацев (параграфов)

— ПФ (прогон формата — f) для разделения страниц

а так же:

— ГТ (горизонтальная табуляция — t) для разделения полей (ячеек таблицы)

— ВТ (вертикальная табуляция — v) её аналог, но по вертикали

и кроме того:

— ВШ (возврат на шаг — b) для наложения символов

— ВК (возврат каретки — r) для наложения строк

— ** неразрывный пробел нулевой ширины — для образования лигатур

— ЗВ (звонок a) для привлечения внимания (хотя по-мне он тут лишний)

— АР2 (авто-регистр 2, он же "эскейп") начало сложных многосимвольных команд

Еще на нулевой странице предполагается заразервировать три кода (2 3 и 4)

под начало и конец текста, а так же конец файла, пакета или что там у нас?...

И еще три (отличающиеся от них одним битом) — под команды переключения страниц.

(Символы с кодами 3 и 4 — это небезызвестные Cntrl/Ц и Cntrl/Д.)

Вот предположим у нас линия связи. Некоторые, работающие в асинхроном

режиме, например по "старт-стопному" протоколу, постоянно находятся в

состоянии когда нету передачи данных. А те, которые в синхронном — должны

постоянно что-то передавать в линию, обозначая "наличие несущей". (Пропадание

которой означает обрыв канала связи.) Ну так в этом качестве передаётся

неразрывный пробел нулевой ширины с кодом 0х16, начало собственно передачи

обозначается символом с кодом 1, а конец (и переход вот вот в такой режим,

только поддержки синхронизации) — соответственно 4.

Начало файла обычно изображать не надо, надо только конец: некоторые

файловые системы выделяют место с точностью не до байта (как UNIX), а только

до блока. Поэтому код 4 там востребован, а код 1 — нет.

Но полученный из линии код 1 как правило указывает на начало заголовка

пакета. Тело пакета начинается с кода 2 и завершается кодом 3, после чего

например хвостовик с контрольной суммой. (Это от пользователя, сидящего за

терминалом, ничего такого не требуется, а вот от оборудования — да.) А мы

будем считать, что код 3 (Cntrl/Ц) переводит систему в некий управляющий

режим. Где можно, например, указать тип кодировки, или способ её упаковки, или

что-то еще нужное и важное. (Вдруг например китайцы захотят перевести систему

в режим три байта на иероглиф...) После чего код 2 опять переведёт систему в

состояние текста.

А три (из четырёх в нулевой странице ASCII) команды — резервируются для

переключения страниц: да, описываемая кодировка — сугубо вспомогательная,

условно девяти— или даже двенадцати-битная (я еще не решил) и "наружу"

вытаскивать её не планируется... Однако, это вполне возможно. Но в имеющем

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

которых предполагается сделать переключаемыми. (А нулевая — соответственно нет.)

На "непереключаемый случай" в качестве страницы 1 — псевдографика, а 2 и 3

— "рукописный" (системный) алфавит — русские буквы в алфавитном порядке в

первой половине страницы и несовпадающие с ними по написанию латинские — во

второй на тех же позициях. Плюс специфические буквы разных языков в свободных

позициях, в соответствии с их произношением. (Буква Q — под Щ, как и

полагается.) Однако для заглавных и строчных букв это соответсвие несколько

отличается...

— Ишь размечтался! Когда это еще понадобится? А вспомогательная кодировка

нужна уже сейчас. И сейчас в ней пока что шесть страниц: по две на алфавит,

псевдографика и вышеописанная "нулевая". (Куда упихано всё нужное из ASCII,

что не буква — на вышеописанных принципах.)

Однако, к такой кодировке требуется и средство проверки/изменения вот этих

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

обозначаем одной буквой, то как указать в каком направлении выполнить

преобразование (из указанной в текущую или наоборот) — это еще можно придумать:

например из указанной в текущую — строчная буква, а наоборот — заглавная.

А вот если попутно понадобится сделать что-то еще... (Например все заглавные

буквы в перекодируемом тексте сделать строчными.) Не знаю как это обозначить

так, чтобы самому не запутаться. Вот и нечего огород городить: промежуточная

кодировка с вышеописанными свойствами и честные побитовые операции!

Забегая вперёд, скажем, что это средство уже таки есть. Даже два.

— два средства?

— ну вот так оно получилось — ей богу совершенно неожиданно. Сперва "реверс"

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

каждом байте указанного (маркером) фрагмента. (Заметим, это РАЗНЫЕ операции:

чаще всего нам надо переставлять буковки — превратить "ТОПОР" в "РОПОТ",

а "ROMA" что значи Рим в "AMOR", что значит любовь. Но бывает что надо и

битики...)

Вот и ввели две операции 'r' и 'R' — для каждого байта в отдельности и

для всего фрагмента разом. Ага. А если (в форме '%r' и '%R') передать им еще и

аргумент... А вот ничего путного в этом случае не получается. (Группами по N

байт, чтобы один вид уникода в другой преобразовывать... Глупости! Префикс

повторения нам на что?!) В общем решили поручить временно безработному '%r'

выполнять те самые побитовые операции. Указав такую операцию аргументом. Но

куда конь с копытом, туда и рак с клешнёй! Тоже безработный '%R' возжелал

делать всё то же самое, но не с каждым байтом персонально, а разом со всем

фрагментом!

А еще были сделаны встроенные операции 'о' и 'О' ("объединение"), которые

сами по себе ничего не делают — только предписывают следующей после них

операции поиска не различать большие и маленькие буквы, а так же русские и

латинские. Их вариант '%о' и '%О' — тоже указывает разные вещи. Например

включить или выключить (с аргументами + и -) это самое отождествление навсегда.

(И если например включено '%о+' то теперь 'о' его временно выключает.) А с

числовым аргументом (типа '%о123') указывают вид уникода: входного — единицы и

выходного — десятки. Сейчас (а это уже не первый вариант) 1 — utf-8, 2 — utf16,

4 — utf32... А три? Три — трёхбайтный вариант! Далее 5 — опять utf16, но другим

концом вперёд. То было младшим, а это — старшим. 6 и 7 — аналогично. 8 и 9

сейчас тоже utf16, но без т.н. "суррогатных пар", каковые в данном случае

просто игнорируются, но это не окончательно: про транслит забыли!... А вот

нулевое значение — признак, что пока неизвестно. То есть для входного-то

по умолчанию utf-8 (а для выходного — такой же как входной), но если встретися

символ с кодом FEFF (неразрывный пробел нулевой ширины) вот тут мы и узнаем...

Для входного. А вот как узнать, что мы узнали — увы, пока не придумано.

Очень даже придумано! *<%О> (Но 'О' здесь — обязательно О-русская).

Забегая вперёд: это так называемый "шаблон". Он же "регулярное выражение".

При чем шаблон — "генерирующий". Потому что является правым аргументом

операции вставки * (звёздочка). А конструкция %О в нём вот как раз и генерит

текст типа "%о123", указывающий установленный сейчас вид входного и выходного

уникода. (А если бы 'О' была латинская — выдавало бы что-то типа: "%о+" или

"%о-" — состояние признака объединения заглавных букв со строчными. Или "%О+"

"%О-" — -//— русских с латинскими, буде 'О' была заглавная.)

Других встроенных операций (не перекодировок) на настоящий момент пока тоже

не придумано. Но — договорились... (Кто и с кем? Ну естественно я с самим

собой!) ...Что пусть все перекодировки обозначаются исключительно русскими

буквами: маленькая (строчная) — к нам, в текущую кодировку, которая, напомню,

у нас ДОС`овская — 886-я. А заглавная — соответственно от нас в этой буквой