Лингвофорум

Верхня частина таблиці кодів для UNIKOI виглядатиме так:

128-П0     129-П1     130-П2     131-П3     132-П4     133-П5     134-П6     135-П7
136-П8     137-П9     138-П10    139-П11    140-П12    141-П13    142П14     143-П15
144-П16    145-П17    146-П18    147-П19    148-П20    149-П21    150-П22    151-П23
152-П24    153-П25    154-П26    155-П27    156-П28    157-П29    158-П30    159-П31
160-К0     161-К1     162-К2     163-ё      164-є      165-К3     166-і      167-ї
168-К4     169-К5     170-К6     171-К7     172-К8     173-ґ      174-ў      175-К9
176-К10    177-К11    178-К12    179-Ё      180-Є      181-К13    182-І      183-Ї
184-К14    185-К15    186-К16    187-К17    188-К18    189-Ґ      190-Ў      191-К19
192-ю      193-а      194-б      195-ц      196-д      197-е      198-ф      199-г
200-х      201-и      202-й      203-к      204-л      205-м      206-н      207-о
208-п      209-я      210-р      211-с      212-т      213-у      214-ж      215-в
216-ь      217-ы      218-з      219-ш      220-э      221-щ      222-ч      223-ъ
224-Ю      225-А      226-Б      227-Ц      228-Д      229-Е      230-Ф      231-Г
232-Х      233-И      234-Й      235-К      236-Л      237-М      238-Н      239-О
240-П      241-Я      242-Р      243-С      244-Т      245-У      246-Ж      247-В
248-Ь      249-Ы      250-З      251-Ш      252-Э      253-Щ      254-Ч      255-Ъ

Коди від 0 до 127, ідентичні ASCII, тут не показано.
П0...П31 та К0...К19 — кодуючі байти початку/продовження та кінця, з відповідними числовими значеннми.
Також тут залишились літери кирилиці — ті ж, що й у KOI8-RU. Псевдографіку та математичні символи замінено кодуючими байтами.

Наприклад, ми хочемо закодувати текст «Я♥UNIKOI». Літера «Я» кодується так само, як у КОІ (числовий код 241). Символ «♥» має код в юнікоді 9829. (Будемо вважати, що цей символ не змінюватиметься при трансляції, і в трансльованому юнікоді це буде той же код, що і в звичайному).
128+640 < 9829 < 128+640+20480 — отже, цей символ юнікоду кодується трьома байтами UNIKOI
>>> c=ord('♥')
>>> c
9829
>>> c-=128+640  # віднімаємо основу 3-байтного діапазону
>>> c
9061
>>> c&31        # накладаємо маску, щоб знайти перший байт П
5
>>> c>>=5       # зсув на 5 розрядів, або ділення на 32 націло, для отримання наступних байтів
>>> c
283
>>> c&31        # накладаємо маску, щоб знайти другий байт П
27
>>> c>>=5       # зсув, щоб дістатись останнього байту
>>> c           # останній байт К
8Таким чином, отримуємо кодуючі байти П5, П27, К8 — це коди 133, 155, 172.
Латинські літери U, N, I, K, O та I кодуються так само, як в ASCII. Таким чином, увесь текст кодується послідовністю байтів [241, 133, 155, 172, 85, 78, 73, 75, 79, 73].
Якщо розкодувати цю послідовність за правилами KOI8-U, отримаємо текст «Я┘⌡╛UNIKOI» — як бачимо, сердечко розсипалось на псевдографіку, але решта тексту, включно з кирилицею, збереглася незмінною. Щоб отримати з цих байтів юнікодівський текст, слід виконати зворотню послідовність дій, яку було описано в попередніх повідомленнях.

Трансльований юнікод. Таблицю трансляцій ще слід придумати, і це досить чутливе місце unikoi: зміни в ній зачіпатимуть часто використовувані символи й вестимуть до несумісностей між версіями. Бажано продумати наперед, які символи варто оптимізувати. На базові латиницю й кирилицю трансляція не вплине — лише на ті символи, що кодуються двома чи більше байтами.

Як було сказано вище, двобайтні коди в цьому кодуванні є дефіцитним ресурсом. Без трансляції вони надаються тим символам, що мають юнікодівські коди в проміжку від 128 до 767, далі починається область 3-байтних кодів. Уявімо, що якийсь часто використовуваний символ (наприклад, тире або наголос) кодується трьома-чотирма байтами. Щоб він кодувався двома, при закодовуванні юнікоду в юнікоі слід замінити його кодом з меншим значенням, а при розкодовуванні зробити зворотню заміну. Місце в юнікоді, куди ми прилаштовуємо наш символ при трансляції, вже зайнято іншим символом, хоч і менш частим — якщо в тексті він усе ж з'явиться, при трансляції його слід передати кодом оптимізованого символа, який зайняв його місце — тобто, два коди символів обмінюються місцями, С1 замінюється на С2, С2 — на С1. Можлива й складніша схема, коли С1 замінюється на С2, С2 — на С3 — в такому разі, останній символ з ланцюжка замінюватиметься на С1. При розкодовуванні відбувається зворотнє перетворення: С2 — на С1, С3 — на С2 і т.д. Тобто, треба простежити, щоб зміни кодів символів утворювали повне коло, а при зворотній трансляції це коло має бути інвертованим («звідки» стає «куди»).

Переносити можна як окремі символьні коди, так і цілі блоки (напр., по 16 кодів, що зручно, якщо ми хочемо покращити кодування якогось алфавіту). Слід простежити, щоб трансляція блоків та окремих символів не конфліктували між собою. Узагалі, перетворення мають бути неконфліктними: кожному коду справжнього юнікоду має відповідати рівно один код, у який він транслюється, і в кожного цільового трансльованого коду має бути рівно одне джерело.

Можливі кандидати на оптимізацію до 2 байтів: типова пунктуація (тире, «правильні» лапки тощо, але не екзотичні символи); часто вживані комбіновані діакритики (знак наголосу та деякі інші); знаки валют (особливо поширених у країнах з кириличним письмом — у першу чергу, гривня та євро); розширена кирилиця (південнослов'янські, старослов'янські тощо букви; деякі історичні букви, втім можна не оптимізувати).

Можливі кандидати на перенесення в більш віддалені області: керуючі символи, що рідко з'являються в тексті; символи основної кирилиці (дублюються однобайтними кодами, тому доцільно перенести їх якомога далі, а звільнене місце, що потрапляє в область 3-байтних кодів, заповнити чимось кориснішим); історична латиниця, неєвропейські латиниці, знаки МФА, лігатури тощо — в латинській області юнікоду залишити нетрансльованими варто лише літери європейських мов, з якими носіям кириличних писемностей доводиться контактувати.

Цитата: Python от апреля 24, 2023, 21:10в юнікодівському КОІ літери інших алфавітів можна кодувати за схожою схемою — додаючи перед літерою кирилиці префікс алфавіту.

Це принципово інший підхід (назвімо його METAKOI), порівняно з описаним вище (UNIKOI), але його можна реалізувати на основі тих же кодуючих байтів. Кодуючі послідовності в цих двох випадках відрізнятимуться, тому можна поєднати їх в одному кодуванні — до конфлікту це не призведе. Має сенс використовувати метакоі для літер алфавітів, а юнікоі — для того, що літерою не є.

Якщо кодуюча послідовність UNIKOI складається з одного чи кількох байтів типу П й одного байту типу К, то в МЕТАКОІ послідовність складається з байтів типу П та літери кирилиці. Кожна така послідовність кодує літеру певного алфавіту, кирилична літера при цьому виступає як транслітерація літери іншого алфавіту — подібно до того, як сама КОІ-кирилиця транслітерується ASCII-латиницею, але якщо для отримання кирилиці в латинській літері змінюється один чи два біти, то для отримання інших алфавітів до кириличної літери додається префікс з одного чи кількох байтів. Текст (грецький, глаголичний, грузинський тощо) у МЕТАКОІ прочитуватиметься в KOI8-U як кирилиця, розбавлена псевдографікою. Або ж, якщо відкинути символи префіксів та змінити старший біт у літерах, отримаємо латинську транслітерацію цього ж тексту.

Таблиці транслітерацій треба буде скласти — в самому юнікоді їх нема. Кожному алфавіту присвоюється певний префікс (напр., П0 — для грецького, П1 — для додаткових літер кирилиці, і т.п.; префікси різної довжини, напр., П1 та П0 П1, вважаються різними префіксами; алфавіти, що містять більш ніж 38 пар літер, розділяються на частини, кожна з яких має свій префікс). П0...П31 у префіксі — позначення кодуючих байтів, поданих у таблиці вище.
Таблиця для кожного алфавіту аналогічна таблиці КОІ з заміною кириличних літер літерами відповідного алфавіту. Наприклад, для грецького це може виглядати так:

                                 163-έ      164-ή                 166-ί      167-ϊ
                                                       173-ϝ      174-ύ            
                                 179-Έ      180-Ή                 182-Ί      183-Ϊ
                                                       189-Ϝ      190-Ύ             
192-ϋ      193-α      194-β      195-χ      196-δ      197-ε      198-φ      199-γ
200-η      201-ι      202-ϛ      203-κ      204-λ      205-μ      206-ν      207-ο
208-π      209-ς      210-ρ      211-σ      212-τ      213-υ      214-θ      215-ω
216-ξ      217-ψ      218-ζ      219-ώ      220-ϡ      221-ό      222-ϟ      223-ά
224-Ϋ      225-Α      226-Β      227-Χ      228-Δ      229-Ε      230-Φ      231-Γ
232-Η      233-Ι      234-Ϛ      235-Κ      236-Λ      237-Μ      238-Ν      239-Ο
240-Π      241-ϖ      242-Ρ      243-Σ      244-Τ      245-Υ      246-Θ      247-Ω
248-Ξ      249-Ψ      250-Ζ      251-Ώ      252-Ϡ      253-Ό      254-Ϟ      255-Ά

Якщо для грецької використовується префікс П0 (байт з кодом 128), то текст «Πυθαγόρας» кодуватиметься послідовністю [128, 240, 128, 213, 128, 214, 128, 193, 128, 199, 128, 221, 128, 210, 128, 193, 128, 209].Можна спробувати декодувати її за правилами КОІ8 — результат виглядатиме як «─П─у─ж─а─г─щ─р─а─я» (що не дуже схоже на «Піфагорас», але принаймні частина літер вгадується).

Цитата: mnashe от марта 27, 2023, 13:20Вот такой кодовой страницей я пользуюсь в Multi-Edit'е уже много лет. Здесь ивритица на своём месте и, что очень удобно, строчные русские буквы на своём месте, так что текст без капсов, набранный в обычной CP-866, прекрасно читается (вместо заглавных букв выходит ивритица).

Заглавные буквы распихал где попало, пришлось даже область символов управления (00-1F) задействовать. Но я встроил в редактор специальный механизм, позволяющий отображать текст, набранный в CP-866 (или любой другой — карта настраивается) в шрифте, сделанном в этой моей модифицированной кодовой странице на базе CP-862.
Для украинских букв места не хватило, но если отказаться от размещения строчных букв на своих местах, то освободятся ещё 7 позиций, так что влезут все три буквы (×2).

Що собою являє формат кодової сторінки в даному випадку? Це щось назразок растрового шрифту? Чи існують якісь редактори або конвертери для таких шрифтів?

Нещодавно дізнався, що FreeDOS має декілька українських кириличних кодових сторінок, яких більш нема ніде. Але, схоже, ці сторінки ніде не описано — єдиним джерелом інформації про їх вміст є самі .cpx-файли (які є стиснутим .cpi), і незовсім зрозуміло, як їх проглянути, не встановлюючи FreeDOS.

У свій час я зробив ковертер  для створення кодових сторінок у форматі .nls з кодувань, підтримуваних Джавою. Але цей формат містить інформацію лише про юнікодівські коди символів кодової сторінки і не містить шрифтових даних (кодова сторінка типу ANSI, для використання якої потрібні векторні шрифти, повноекранний текстовий режим не підтримується).

Цитата: Python от мая 13, 2023, 04:42Що собою являє формат кодової сторінки в даному випадку? Це щось назразок растрового шрифту? Чи існують якісь редактори або конвертери для таких шрифтів?

Звичайно. Я колись користувався evafont, він ішов разом із KeyRus-ом.
http://old-dos.ru/index.php?page=files&mode=files&do=show&id=3404

Цікава річ. (Скачав з іншого джерела, бо на це не пускав провайдер, але все одно дякую).

Схоже, шрифти з різних систем несумісні між собою. EVAFONT може редагувати шрифти з цього архіву, але тільки їх. На windows вони не ставляться. FontForge підтримує якісь точкові шрифти .fnt, але не ці. FreeDOS надає кодові сторінки зі шрифтовою інформацією у форматі .cpx, але для evafont i fontforge цей формат неїстівний.

В принципі, .cpx можна конвертувати в нестиснутий .cpi, але чим його потім відкрити? Поки що знайшов тільки опис цього формату (без деталей про шрифтові дані в ньому). А ще гуглиться сторінка з битим посиланням на редактор шрифтів .cpi, з чого користі теж небагато, але дещо корисне може бути в коментарях...

Але в той час я про інші формати навіть не чув. Крім KeyRus-а користувався шрифтами зробленими в evafont у власних програмах. Тоді брат мені допоміг зробити на Паскалі модуль для читання й відображення цих шрифтів у графічному режимі. А потім я сам у якійсь книжці знайшов функцію, яка дозволяє змінювати шрифт у текстовому режимі. Там НЯП ці fnt файли навіть обробляти не треба було -- передавалися в int 10h напряму. Особливо для текстових ігор зручно було малювати в evafont всілякі ключі, двері, персонажів і т.п.

Upd: Подивився, так, формат .fnt максимально "сирий" і не містить жодних даних крім зображень символів. Навіть висоту символа evafont визначає лише за розміром файла. Ось так виглядає функція для застосування шрифта.
Procedure SetFont(Var C;Count : Word;Height : Byte); Assembler;
asm
  push   es
  push   bp
  mov    bh,Height
  mov    ax,1100h
  mov    cx,Count
  les    bp,C
  xor    dx,dx
  xor    bl,bl
  int    10h
  pop    bp
  pop    es
end;
Цікаво через 25 років згадати про такий прикол як Var C -- параметр взагалі без типу даних. Якщо Pointer то аналог void *C, то Var С то аналог void &C, якого в С++ нема, а в Паскалі є.

Цитата: Python от мая 13, 2023, 17:52В принципі, .cpx можна конвертувати в нестиснутий .cpi, але чим його потім відкрити?

Ось тут є проги, якими можна сконвертувати cpi в fnt:
http://www.kostis.net/freeware/
в архіві "cpi120.zip"
> cpilist ega.cpi
Code pages found: 437 850 852...
> cpiget ega.cpi 437
CPIget: extracting Codepage 437 to file cp437.cp
> cp2fnt 437


Цитата: Python от мая 13, 2023, 04:42

Код Выделить Развернуть

import java.io.*;

public class nls3charset
{
//see http://webcenter.ru/~kazarn/eng/nls.htm#nt4
public static void main(String[] args) throws Exception
{
//args are: CODEPAGE CHARSET
//generates c_CODEPAGE.nls from CHARSET
short codepage=(short)(int)Integer.valueOf(args[0]);
String encoding=args[1];
short[] header=new short[]
{
(short)0x000D,
codepage,
(short)0x0001,
(short)0x003f, (short)0x003f, (short)0x003f, (short)0x003f
};
int SKIP_WORDS1=6;//not described in the article
short[] tables1= new short[]
{
(short)0x0103,//ANSI codepage. 0x0203 for OEM
};
short[] byte2unicode=new short[256];
//short[] byte2unicodeOEM=new short[256];
int SKIP_WORDS2=3;//reserve
byte[]  unicode2byte=new byte[65536];
for(int i=0; i<unicode2byte.length; i++)
unicode2byte[i]=(byte)'?';//fill it with default values
for(int i=0; i<256; i++)
{
int c=charcode((byte)i, encoding);
byte2unicode[i]=(short)c;
//byte2unicodeOEM[i]=(short)c;
unicode2byte[c]=(byte)i;
}
//add smiles to byte2unicodeOEM
//write them to .nls:
OutputStream nls=new FileOutputStream("c_"+codepage+".nls");
nls.write(bytes(header));
nls.write(bytes(SKIP_WORDS1));
nls.write(bytes(tables1));
nls.write(bytes(byte2unicode));
//nls.write(bytes(byte2unicodeOEM));
nls.write(bytes(SKIP_WORDS2));
nls.write(bytes(unicode2byte));
nls.close();
//also generate .reg file (smth like the next):
/*
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Nls\CodePage]
"10000"="c_10000.nls"
*/
//(or, m.b. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage])
//PrintStream reg=new PrintStream("c_"+codepage+".reg", "x-UTF-16LE-BOM");
PrintStream reg=new PrintStream("c_"+codepage+".reg");//ascii is fine too :)
reg.print("Windows Registry Editor Version 5.00\r\n"
  +"\r\n"
  +"[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Nls\\CodePage]\r\n"
  +String.format("\"%d\"=\"c_%1$d.nls\"\r\n", codepage));
reg.close();

}
static byte[] bytes(short[] a)
{
byte[]res=new byte[a.length<<1];
for(int i=0; i<a.length; i++)
{
res[(i<<1)]  =(byte)(a[i]);
res[(i<<1)+1]=(byte)(a[i]>>8);
}
return res;
}
static byte[] bytes(int emptyWords)
{
return new byte[emptyWords<<1];
}
static byte[] bytes(byte[] a)
{
return a;
}
static int charcode(byte b, String encoding) throws Exception
{
return new String(new byte[]{b}, encoding).charAt(0);
}
}

Є проблема з відображенням коду у спойлерах

Цитата: Python от мая 13, 2023, 04:42Що собою являє формат кодової сторінки в даному випадку? Це щось назразок растрового шрифту? Чи існують якісь редактори або конвертери для таких шрифтів?

Там несколько слоёв.
Сначала я просто сделал возможность загружать свои шрифты в соответствующую область (цветной монитор и, соответственно, VGA-плата у меня уже появились, а Windows ещё был неактуален). Я сделал свой простенький формат шрифтовых файлов, где, кроме набора таблиц под разную высоту символа, есть только раскладка клавиатуры. Дополнительные параметры — таблицы перекодирования caps/low и набор символов, входящих в слова (для поиска по словам и перемещения курсора к следующему / предыдущему слову), вычисляются программно из раскладок.
Редактор шрифтов я написал средствами самого Multi-Edit'а, в виде скрипта (ядро для этого модифицировать не нужно).
Потом появился Windows 95, а с ним и работа в окне, а не только в полноэкранном режиме. Для этого мне пришлось написать свой шрифт Terminal. Для рисования шрифта в формате FNT я использовал программу (редактор ресурсов), идущую в составе какого-то из борландовских пакетов, не помню, турбо C или турбо паскаль.

И тут уже я столкнулся с проблемой: в ўиндоўсовском окне я не могу переключать шрифт на лету, как «у себя дома», парой щелчков мыши или сочетанием клавиш. Там шрифт консольных окон всегда один и тот же. Выкрутился так: сделал почти под каждое разрешение два варианта, в одном стандартная cp866, а в другом иврит + маленькие русские. Чтобы отличать, я сделал размер шрифта одного из вариантов на единицу больше другого: 11×20 с cp866, 12×20 с моей смешанной, 13×22 со смешанной, 13×23 cp866. Остальными шрифтами пришлось пожертвовать (для их использования я переключался в полноэкранный режим).
Но и тут неудобства. Во-первых, слишком далеко это: лезть в свойства окна, оттуда в шрифты, и менять выбор. А если у меня загружены разные файлы одновременно, то все эти манипуляции надо проделывать при каждом переключении. Во-вторых, ивритица у меня есть и в самом интерфейсе программы (дата по еврейскому календарю). В полноэкранном режиме это не проблема: интерфейс автоматически меняется в зависимости от доступности ивритицы в шрифте. Но о том, что я выбрал в настройках окна, программа узнать не может.

Помучившись так несколько лет, я придумал механизм, в котором редактор может отображать текст не напрямую, а через таблицу перекодировки, выбирающую некоторое подмножество доступного шрифта (жаль, что окно NTVDM не эмулирует режим с 512 символами, это бы полностью решило проблему). Соответственно, пришлось усложнить систему, введя фактически механизм кодовых страниц, только не из уникода, а всего из 256 доступных символов.
Пример определения пары кодовых страниц (условной cp866 и условной Win1255) в файле codepage.ini в составе multi-edit'а:
[866]
DOS Cyrillic using HebRus font
F=HEBRUS
M=אAБBГДEЖ3ИЙKЛMHOПPCTУФXЦЧШЩЪЫЬЭЮЯабвгдежзийклмноп░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐▀рстуфхцчшщъыьэюяЁё≥≤☼☼«»°··√ⁿ²■☼
W=БГ• ♂♀☼►◄↕‼П§▬Й↑↓→←⌐↔▲▼ !"%&'()*+,-./:;<=>?@[\]^`{|}~░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐▀«»°··√ⁿ²■
>=0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzתשרקצץפףעסנןמםלכךיטחזוהדגבאЫУЭЮЯабвгдежзийклмнопрстуфхцчшщъыьэюяЁё≥≤ШЩ
l=%"«»;:,.'[]-=%%йцукенгшщзхъ%%фывапролджэ` ?ячсмитьбюё
L=%%%ⁿ%%%%%%%%%%%בУעטלסקЯ% %ЭזהכמנןאגЫפ%%תץחשרדםוךףציЮЁ
a=%1234567890%%%%%%%%%%%%·§%%%%%%%%%%%%%%%%%\%°%%%%%<>/
/=►◄↕‼П§▬Й↑↓→←▲▼ !"#$%&'(,-./012345
▲=azAапאряנЖёЁ≤≥ЩШ
▼=AZaןאаנЯрЖЁё≥≤ШЩ
A=%%%#%%%%%%%%%%%%%%%%%%%·■{}%%%%%%%%%%%%%%%%%%%%%%%≤≥?
[1255]
Windows Hebrew
F=HEBRUS
M=א☼☼,☼☼▬☼☼☼☼☼<☼☼☼☼☼`'""•──~☼☼>☼☼☼☼%☼☼☼☼☼|§"☼%«⌐-☼~°╧²ⁿ'☼П·☼ⁿ☼»☼☼☼☼··············~~│··:☼☼☼'"☼☼☼☼☼☼☼תשרקצץפףעסנןמםלכךיטחזוהדגבא
W=БГ• ♀☼►◄↕‼П§▬Й↑↓→←⌐↔▲▼ !"&'()*+,-./:;<=>?@[\]^`{|}~רקצץפףעסכוגЫажзиклмп░▒┤╢╖╣║╗╬╧╨╙
>=%.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
<=%.└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪рстуфхцчшщъыьэюяЁё≥≤ШЩ«»°··
r=%%%%%%%%%%%%%+\/'»°ршхяэШ%%}e·уты≥щчьъ≤,;:%цёсфЁю«·Щ.
R=%%%%%%%%%%%%%%%`
▲=azA
▼=AZa
a=%%%%%%%%%%%%%%%%%%%%%%%ץз%%%%%%%%%%%%%:קצ%%%░%%%%ו<>/
A=%%%%%%%%%%%קצ%%%%%%%%%%╖а%%%%%%%%%%%%%%%%%ж
Первая строка после заголовка — просто описание.
Дальше:
F=имя файла шрифта (имеет значение только в полноэкранном режиме)
М=таблица перекодировки для 80h-FFh
W=список символов, считающихся разграничителями слов
>=список символов, задающих направление LtR
<=список символов, задающих направление RtL
l=раскладка (таблица scan→char) для нормального регистра в направлении LtR
L=раскладка для верхнего регистра в направлении LtR
r=раскладка для нормального регистра в направлении RtL
R=раскладка для верхнего регистра в направлении RtL
r=раскладка для нормального регистра в направлении RtL
a=раскладка с правым Alt
A=раскладка с правым Alt+Shift
▲=таблица перекодировки в верхний регистр (caps): сначала триплеты <начало диапазона> <конец диапазона> <во что перекодировать начало диапазона>, потом после разделителя пары (где весь диапазон состоит из одного символа).
▼=аналогичная таблица для противоположной операции (они не всегда обратимы: в кодовой страницы без кириллических букв, совпадающих по виду с латинскими, невозможно корректно преобразовать из верхнего в нижний).

Гадаю, можна створити кодування, яке буде поєднувати в собі можливості utf-8 (зберігаючи з ним односторонню сумісність) та 1-байтних національних кодувань. Тобто, валідний текст в utf-8 гарантовано можна буде прочитати за правилами цього кодування (але не навпаки), текст у цьому кодуванні може містити будь-які символи юнікоду, закодовані тим же способом, що в чистому utf-8 — але при цьому до 256 символів можуть кодуватися однобайтними кодами. Якщо в звичайному utf-8 лише 128 символів ascii кодуються однобайтним способом, і ще 128 однобайтних кодів є невалідними, то в «національному utf-8» ці однобайтні коди стають валідними. Якщо ж обмежитися використанням лише однобайтних кодів, то таке кодування можна обробляти і як звичайне однобайтне — наприклад, створити для нього кодову сторінку в ДОС.

Байти багатобайтних кодів в UTF-8 бувають двох типів: початкові байти (в межах 0xC0...0xFF, але частина з них не використовується валідним чином, тому насправді лише 0xC2...0xF4) та байти продовження (0x80...0xBF). Багатобайтний код складається з одного початкового байту та одного чи кількох байтів продовження після нього. Послідовність з самих лише байтів продовження, як і послідовність з самих лише початкових байтів, не утворює багатобайтних кодів і в валідному чистому utf-8 з'являтися не може, а отже, її можна обробляти як однобайтні коди. Послідовності з таких однобайтних символів можуть іти перед чи після символів основного ascii та багатобайтних символів utf-8 — до конфлікту це не призведе. Але, якщо після символа, що кодується початковим байтом, з'являється символ, що кодується байтом продовження, то один із них слід передати багатобайтним кодом, щоб його можна було правильно розкодувати при читанні.

Узагалі, треба зробити так, щоб однобайтні символи, що кодуються байтами початку та байтами продовження, в реальному тексті не опинялися поруч. Наприклад, байти початку кодують символи одного алфавіту, байти продовження — іншого, поєднання їх в одному слові малоймовірне. Таким чином, усі кириличні однобайтні коди мають бути або в діапазоні 0x80...0xBF, або в 0xC0...0xFF, але не в них обох одночасно. У кожному з цих діапазонів лише 64 коди (придатні для 32 літер у двох регістах) — цього достатньо для короткого російського алфавіту (без Ёё) й сучасного болгарського, або для неповного українського (без Іі чи без Ґґ), але в загальному випадку цього мало, решту кирилиці доведеться передавати багатобайтними кодами. Утім, до діапазону байтів продовження (0x80...0xBF) можна приєднати діапазон невалідних байтів початку (0xC0, 0xC1, 0xF5...0xFF), разом вийде 77 кодів — цього достатньо, щоб охопити всі літери українського, болгарського, білоруського й російського алфавітів та ще один непарний символ (наголос, літера-апостроф, м'який перенос тощо — бажано витратити цей код на символ, що може стояти поруч з літерами кирилиці). Що ж стосується другого діапазону, в ньому можна розмістити розширену латиницю, грецькі літери, математичні символи, знаки валют тощо — всі ті символи, що в нормі не з'являються безпосередньо біля кириличних літер. Розширену пунктуацію дещо складніше розмістити таким способом: якщо кирилиця кодується байтами продовження, то в діапазоні байтів початку можна розмістити лише ті розділові знаки, що не з'являються перед словом (наприклад, кінцеві лапки можна розмістити в діапазоні байтів початку, тоді як початкові лапки мають разом з кирилицею бути серед байтів продовження); якщо ж кирилиця кодується байтами початку, то знаки після слів мають кодуватися теж байтами початку, а знаки перед словом можуть бути і байтами продовження (тобто, приблизно так само, з різницею в «мають/можуть»); ті розділові знаки та спецсимволи, що з'являються між словами чи всередині слів, мають належати до того ж діапазону, що й кирилиця.

Тепер, з якими однобайтними кодуваннями «національний utf-8» може бути сумісним. Усі відомі кириличні кодування (включно з юнікодівським блоком кирилиці) вибудувано навколо короткого російського алфавіту — кодувань з українським алфавітом в основі не існує, українські літери, відсутні в російському алфавіті, розміщуються поза цим основним блоком. Такі кодування, як cp1251 та koi8, розміщують короткий російський алфавіт у діапазоні 0xC0...0xFF (що відповідає байтам початку символьного коду в utf-8), додаткова кирилиця (зокрема, українська) опиняється в іншому діапазоні — якщо нам потрібне однобайтне українське кодування, доведеться внести зміни в основний блок. CP866, cp1125 та інші варіанти ДОС-кирилиці неможливо повноцінно сумістити з «національним utf-8» у жодному варіанті: кирилицю в них розділено між двома діапазонами (втім, великі літери основного кириличного блоку повністю вкладаються в діапазон байтів продовження). Приблизно це ж можна сказати й про ISO-кирилицю, що лягла в основу юнікодівського кириличного блоку: великі літери опинились між двома діапазонами, але малі російські й неросійські кириличні літери повністю розмістились у діапазоні байтів початку (що цікаво, але нікуди не веде).

Нарешті, нині малопоширене болгарське кириличне кодування (кодова сторінка 3021 у FreeDOS, Cyrillic MIK Bulgarian) має основний кириличний блок, що збігається з діапазоном байтів продовження 0x80...0xBF — такий варіант здається найбільш перспективним, оскільки байти продовження можна поєднати з невалідними байтами початку, як було описано вище. Великі літери основного кириличного блоку в цьому кодуванні збігаються з cp866, але українських та інших неросійських кириличних літер нема (що дає нам свободу їх розміщення). Великі літери основної кирилиці в цьому кодуванні збігаються з cp866 — таким чином, «національний utf-8» на основі болгарського кодування зберігатиме цю часткову сумісність з DOS-кирилицею.
Кирилична частина виглядатиме, наприклад, так:

128-А   129-Б   130-В   131-Г   132-Д   133-Е   134-Ж   135-З
136-И   137-Й   138-К   139-Л   140-М   141-Н   142-О   143-П
144-Р   145-С   146-Т   147-У   148-Ф   149-Х   150-Ц   151-Ч
152-Ш   153-Щ   154-Ъ   155-Ы   156-Ь   157-Э   158-Ю   159-Я
160-а   161-б   162-в   163-г   164-д   165-е   166-ж   167-з
168-и   169-й   170-к   171-л   172-м   173-н   174-о   175-п
176-р   177-с   178-т   179-у   180-ф   181-х   182-ц   183-ч
184-ш   185-щ   186-ъ   187-ы   188-ь   189-э   190-ю   191-я
192-Ё   193-ё  
..............................................................
                                        245-́    246-Ў   247-ў
248-І   249-і   250-Ґ   251-ґ   252-Є   253-є   254-Ї   255-ї

Або варіант з лапками:

                                244-»   245-«   246-Ў   247-ў

Показані тут кінцеві лапки "»" з кодом 244 потрапляють до діапазону валідних байтів початку і не є частиною кириличного діапазону, складеного з байтів продовження та невалідних байтів. Використані за стандартними правилами пунктуації, вони ніколи не опиняться перед кириличною літерою, якщо ж таке станеться, то замість однобайтного коду кінцевих лапок буде використано багатобайтний utf-8.
Або ж можна лишити половинки інтегралу там же, де вони були в болгарському кодуванні:

                                244-⌠   245-⌡   246-Ў   247-ў

Як використати решту кодів? (Нагадаю, це мають бути символи, що в реальному тексті не з'являються поруч із кириличними буквами). 50 чи 51 код — цього недостатньо для розміщення повного грецького алфавіту навіть без тоносів, хоча, якщо відвести цю область для математичних символів, там можна розмістити грецькі букви, графічно відмінні від латинських, подібно до того, як це було в оригінальному болгарському кодуванні, також можна зберегти №, §, частину математичних символів на своїх старих позиціях. Від більшості символів малювання рамок, імовірно, доведеться відмовитись — вони можуть опинятись поруч біля кириличних букв, що створить неоднозначність (хіба що можна залишити вертикальну лінію, потрібну для збірного символа інтегралу, якщо він нам потрібен). На їхнє місце можна додати знаки валют (гривня, євро, біткоїн...), перенести ті математичні символи, що опинились в області додаткової кирилиці, додати більше грецьких літер та математики:

128-А   129-Б   130-В   131-Г   132-Д   133-Е   134-Ж   135-З
136-И   137-Й   138-К   139-Л   140-М   141-Н   142-О   143-П
144-Р   145-С   146-Т   147-У   148-Ф   149-Х   150-Ц   151-Ч
152-Ш   153-Щ   154-Ъ   155-Ы   156-Ь   157-Э   158-Ю   159-Я
160-а   161-б   162-в   163-г   164-д   165-е   166-ж   167-з
168-и   169-й   170-к   171-л   172-м   173-н   174-о   175-п
176-р   177-с   178-т   179-у   180-ф   181-х   182-ц   183-ч
184-ш   185-щ   186-ъ   187-ы   188-ь   189-э   190-ю   191-я
192-Ё   193-ё   194-₴   195-€   196-₿   197-¤   198-ρ   199-ι
200-ξ   201-η   202-γ   203-Δ   204-∇   205-φ   206-ε   207-∪
208-ψ   209-θ   210-ω   211-│   212-÷   213-№   214-§   215-≈
216-°   217-∙   218-·   219-√   220-ⁿ   221-²   222-³   223-≠
224-α   225-ß   226-Γ   227-π   228-Σ   229-σ   230-µ   231-τ
232-Φ   233-Θ   234-Ω   235-δ   236-∞   237-∅   238-∈   239-∩
240-≡   241-±   242-≥   243-≤   244-⌠   245-⌡   246-Ў   247-ў
248-І   249-і   250-Ґ   251-ґ   252-Є   253-є   254-Ї   255-ї

(Можливі й інші варіанти заповнення некириличної області. В даному випадку, я намагався зберегти сумісність з болгарським кодуванням, де це можливо).

Цитата: Upliner от мая 13, 2023, 23:33Upd: Подивився, так, формат .fnt максимально "сирий" і не містить жодних даних крім зображень символів. Навіть висоту символа evafont визначає лише за розміром файла.

Справді, максимально простий формат. Написав скрипт для друку шрифтів .fnt в консолі за допомогою шрифту Брайля.

Сам модифікований шрифт зі збільшеними точками у брайлівських символах я зробив колись раніше для гри «Життя», хоча існують і інші шрифти, придатні для такого використання. Брайлівські символи являють собою прямокутні матриці з 2х4 точок — усього 256 таких символів для всіх можливих комбінацій. Фактично це дає можливість працювати з грубою піксельною графікою як з текстом (друкувати в консолі, копіювати в текстовий редактор і т.п.). Наприклад, якщо гліф у .fnt має розмір 8х16, то його можна намалювати як квадрат з 4х4 брайлівських символів:
⣀⣀⣠⡆
⢸⡇⠀⠀
⢸⡇⠀⠀
⠉⠉⠀⠀

Цитата: Python от мая 17, 2023, 00:26Таким чином, усі кириличні однобайтні коди мають бути або в діапазоні 0xA0...0xBF, або в 0xC0...0xFF, але не в них обох одночасно. У кожному з цих діапазонів лише 64 коди

А, так, тут помилка (яку я ще й скопіював кілька разів). Замість 0xA0 має бути 0x80. Дякую, зараз виправлю.

Цитата: Python от мая 18, 2023, 02:36Брайлівські символи являють собою прямокутні матриці з 2х4 точок — усього 256 таких символів для всіх можливих комбінацій. Фактично це дає можливість працювати з грубою піксельною графікою як з текстом

До речі, можна створити кодову сторінку й екранний шрифт з матрицями назразок брайлівських — щоб мати змогу відображати і текст, і графіку, лишаючись у текстовому режимі. Якщо система підтримує роботу з двома шрифтами («512-символьний режим»), то один шрифт виводитиме 256 текстових символів, другий — 256 брайлівських матриць.

Якщо ж система підтримує лише один екранний шрифт, то поєднати всі 256 матриць і ще й текстові символи в одній кодовій сторінці неможливо. Можна замінити 8-точкові матриці на 6-точкові — тоді вони займатимуть 64 кодові позиції — таким чином, маємо 128 кодів базового ascii, 64 коди для псевдопіксельної графіки і ще 64 коди для якихось інших цілей.

Задіяти для графіки всі 128 кодів, не зайнятих базовим ascii, дещо складніше: 7 ні на що не ділиться, 7-бітну матрицю з точок неможливо розкласти прямокутником, як 6-бітну (2х3) чи 8-бітну (2х4). Можна розділити прямокутник на 7 компактних областей тим чи іншим способом і будувати матриці з них. Або ж можна використати 8-точкові матриці, але не всі їх, а лише частину.

За основу береться 8-бітний формат, який буде відображатися з утрами. При перекодуванні з 8-бітного формату в 7-бітний, старший біт відкидається. 7 точок з 8 кодуються одним бітом кожна. Восьма ж відображається наступним чином: якщо більшість сусідніх точок біля неї світлі, то вона теж світла, інакше — темна. Тобто, наприклад,

8-бітна матриця:    відобразиться як:

⢺                    ⠺
. #                  . # 
# #                  # #
. #                  . #
. #                  . .


⡪                    ⣪
. #                  . #
# .                  # .
. #                  . #
# .                  # #


⣿                    ⣿
# #                  # #
# #                  # #
# #                  # #
# #                  # #

Щоб часткво зменшити втрати, можна додатково закодувати частину матриць в області базового ascii (на місці керуючих символів, чи навіть частини друкованих, яких нам не шкода), а перед відображенням перетворювати 8-бітні коди за допомогою XLAT — тоді можна буде відобразити всі 8-бітні матриці, яким пощастить отримати власний код (а ті, яким не пощастило, зазнають корекції, як описано вище).

Звичайно, все це має сенс, лише якщо символи в текстовому режимі достатньо дрібні, і їх на екрані достатньо багато. Жаль, не можу оцінити все це на власні очі — з windows-8 викинули підтримку повноекранного текстового режиму, бо не змогли сумістити драйвери для нього з драйверами для напівпрозорих вікон, потрібних переважно для самореклами та псування зору користувачам

В принципі в текстовому режимі можна взагалі виставити висоту символа в 1, завантажити в 0-255 всі варіанти з 8 точок і малювати що завгодно А також при проході scanline можна змінювати палітру й мати більше ніж 256 кольорів одночасно.

Це перетворює текстовий режим на аналог графічного, але хотілось би мати можливість працювати одночасно і з текстом. Тому треба шукати компроміс — щоб і символи були придатними для читання, і псевдопікселі були дрібними, наскільки це можливо.

А що там з шириною символів, кількістю стовпчиків? Особливо в контексті сучасних широких моніторів. Класичні 80-символьні рядки на них виглядатимуть страшно...

Цитата: Python от мая 21, 2023, 09:45А що там з шириною символів, кількістю стовпчиків? Особливо в контексті сучасних широких моніторів. Класичні 80-символьні рядки на них виглядатимуть страшно...

От із цим, боюся, нічого не зробиш, у текстовому режимі VGA доступні тільки два варіанти: 8 та 9 пікселів, відповідно 640 та 720 пікселів на рядок. Хіба що можна зробити 350 рядків замість звичайних 480, буде хоч трошки "широкоформатно". Хоча може й можна збільшити кількість символів на рядок, але точно не пам'ятаю.

Цитата: Upliner от мая 21, 2023, 09:14А також при проході scanline можна змінювати палітру й мати більше ніж 256 кольорів одночасно.

Як часто це можна робити — після кожного символа, після кожного рядка, безпосередньо під час малювання символа? Чи можна таким робом увіпхнути більш ніж два кольори в один символ?

Цитата: Upliner от мая 21, 2023, 09:50От із цим, боюся, нічого не зробиш, у текстовому режимі VGA доступні тільки два варіанти: 8 та 9 пікселів, відповідно 640 та 720 пікселів на рядок. Хіба що можна зробити 350 рядків замість звичайних 480, буде хоч трошки "широкоформатно". Хоча може й можна збільшити кількість символів на рядок, але точно не пам'ятаю.

Видеокарты S3 в своё время поддерживали «большие» текстовые видеорежимы, вплоть до 160×60 символов. На линуксовой консоли можно было таким баловаться.

Цитата: Python от мая 21, 2023, 01:05windows-8 викинули підтримку повноекранного текстового режиму

Уже в семёрке.

Цитата: Python от мая 21, 2023, 01:05бо не змогли сумістити драйвери для нього з драйверами для напівпрозорих вікон, потрібних переважно для самореклами та псування зору користувачам

А, я не знал.

Но у меня есть компьютеры с XP. Вот сейчас из-под XP пишу, на работе. Но дома тоже есть, хоть и не подключённый.

Цитата: Python от мая 21, 2023, 09:45Класичні 80-символьні рядки на них виглядатимуть страшно...

Да, так и есть, на ЖК-экранах текстовый режим выглядит плохо, прежде всего из-за масштабирования 720×480 → 1920×1080, приводящего к размытию.

В ME я реализовал поддержку 132-символьных текстовых режимов; их поддерживали некоторые SVGA, в частности, Trident, которая была у меня в те годы. Но в современных видеоплатах (и интегрированной графике) их, кажется, нет.

Цитата: Python от мая 21, 2023, 09:56Як часто це можна робити — після кожного символа, після кожного рядка, безпосередньо під час малювання символа? Чи можна таким робом увіпхнути більш ніж два кольори в один символ?

На практиці можна змінити палітру після кожного рядка, тобто в одному рядку все ж таки буде обмеження в 16 кольорів.

Цитата: Andrey Lukyanov от мая 21, 2023, 09:58Видеокарты S3 в своё время поддерживали «большие» текстовые видеорежимы, вплоть до 160×60 символов. На линуксовой консоли можно было таким баловаться.

Це точно нативний текстовий режим, а не емуляція через fbdev? Так-то я в fbdev-консолі й фільми дивився без жодних X11