Коли виздихає ASCII? & Створення української кодової сторінки

[Python]

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

Досі нічого кращого ніхто не запропонував.

У цій темі в мене була ідея юнікодівського кодування на основі KOI8-RU, але щось подібне можна було б зробити і на основі чистого ASCII — так навіть простіше, і більше кодів можна задіяти.

Ключові відмінності від UTF-8:
1) Символи кодуються одним чи кількома префіксними байтами і одним кінцевим байтом (принцип, аналогічний сішним рядкам з кінцевим нуль-символом, але кінцевий байт теж є кодуючим — напр., може бути 64 різних префіксних байтів і 64 різних кінцевих байтів, тоді послідовність з n байтів (один з яких кінцевий, всі інші — префіксні) може кодувати 2⁶ⁿ символів).
2) Коди не дублюються. Коли при читанні обчислюється код n-байтного символа, до нього додається найбільший код (n-1)-байтного символа плюс 1.

[Andrey Lukyanov]

У цій темі в мене була ідея юнікодівського кодування на основі KOI8-RU, але щось подібне можна було б зробити і на основі чистого ASCII — так навіть простіше, і більше кодів можна задіяти.

Ключові відмінності від UTF-8:
1) Символи кодуються одним чи кількома префіксними байтами і одним кінцевим байтом (принцип, аналогічний сішним рядкам з кінцевим нуль-символом, але кінцевий байт теж є кодуючим — напр., може бути 64 різних префіксних байтів і 64 різних кінцевих байтів, тоді послідовність з n байтів (один з яких кінцевий, всі інші — префіксні) може кодувати 2⁶ⁿ символів).
2) Коди не дублюються. Коли при читанні обчислюється код n-байтного символа, до нього додається найбільший код (n-1)-байтного символа плюс 1.

Можно ещё немного сэкономить, если чистые ASCII-байты также использовать в качестве завершающих (если перед ними не стоит другой завершающий байт).

[Python]

В принципі, можу погодитися, що задавати довжину першим байтом, а не маркувати кінець останнім байтом, краще з точки зору пошуку — це дає гарантію від співпадінь символа з частиною іншого символа. Хоча варіант з маркуванням кінця може бути економнішим з точки зору кількості байтів на символ: спочатку я пробував втиснути щось схоже на utf у 52 незайняті кодові позиції KOI8-RU — зі збільшенням коду символа, довжина його багатобайтного коду зростала надто швидко, а сам алгоритм вийшов переускладненим — тому прийшов до рішення з 32 кодами префіксних байтів та 20 кінцевих і без дублювання наддовгими кодами.

От дублюючі наддовгі коди, які при цьому ще й не можна використовувати взагалі — навіщо? Виглядає як травма збереження сумісності з чимось, що більше не підтримується (чи, скоріш, ніколи толком і не підтримувалось). Якби наддовгі коди були повністю легальними, то їх би можна було використати, наприклад, для спрощеного перекодування в UTF-8, працюючи з ним як з кодуванням фіксованої довжини — але цього робити не можна. В utf-подібному алгоритмі теж цілком можна було б звільнитись від дублювання (напр., в UTF-8 2-байтні коди кодують діапазон юнікоду від 0 до 2¹¹, хоча могли б від 128 до 2¹¹+128, діапазон 3-байтних можна було починати не від 0, а від кінця діапазону 2-байтних, і т.д.) — тоді з самого початку не було б дірки з дублюванням, яку потім довелося латати.

[Python]

У продовження теми UTF8-сумісного кодування з однобайтними кодами для кирилиці:

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-ї

Останній рядок можна змінити таким чином, щоб покращити сумісність з кодуванням 1131 (модифікацією cp866 з повним набором українських та білоруських літер):

248-І   249-і   250-Є   251-є   252-Ґ   253-ґ   254-Ї   255-ї

Тоді літери Ўў Іі Ґґ кодуватимуться так само, як у ньому. Про повну сумісність не йдеться — букви Ёё Єє Її все одно відрізнятимуться кодами від cp866 чи cp1131, також відрізнятиметься половина малих букв основного кириличного блоку. В принципі, можна ще трохи покращити сумісність, перенісши малу букву ї на позицію 245, щоб співпала ще й вона, але виграш від цього менший, ніж незручності: велика Ї все одно лишається з кодом 254, діапазон 194...244 для кирилиці заборонений, щоб не викликати випадкового поєднання кодів початку та продовження UTF-8, тому пара Її вийде розірваною:

                                        245-ї   246-Ў   247-ў
248-І   249-і   250-Є   251-є   252-Ґ   253-ґ   254-Ї   255- 

[Python]

Не можу звільнитися від думки: «Коли виздихає UTF-8?».

Утім, надлишковість UTF-8 (у його повному варіанті) робить його цікавим у якості основи для кодувань, похідних від нього. Про кодування на основі болгарського MIK та UTF-8 вже писав вище, але можливі й інші поєднання.

Наприклад, в області 0...127 можна розмістити замість стандартного ASCII щось інше (напр., KOI-7 чи інше 7-бітне кодування — модифіковані варіанти ASCII тих часів, коли 8-бітні кодування ще не поширились, або своє власне 7-бітне кодування). Символи стандартного ASCII, які при цьому буде викинуто з однобайтної області, все ще можна передавати наддовгими двобайтними кодами.

Або можна змінити правила валідності багатобайтних кодів, щоб сумістити UTF-8 та якесь із більш поширених 8-бітних кодувань. МІК-кодування такої модифікації UTF-8 не потребує, бо всі його кириличні коди розміщено так, що їх комбінації в реальному тексті не можуть утворювати валідних багатобайтних кодів, тому ці кодування можна неконфліктно змішувати.

Якщо ж узяти, наприклад, кириличні букви в cp866, то їх можна неконфліктним чином поєднати лише з 1- та 2-байтними кодами UTF-8. Область байтів початку 3-байтних кодів заповнено буквами р...я — отже, 3-байтні коди в цьому гібридному кодуванні слід вважати невалідними, байти початку 3-байтних кодів обробляти як 1-байтні літери кирилиці, а символи, що в стандартному utf-8 кодуються 3-байтними послідовностями, передавати наддовгими (4- чи більше -байтними) кодами. Далі виникає проблема: наддовгі 4-байтні коди починаються з того ж байту, який кодує букву Ё, і інші байти початку 4-байтних послідовностей теж заповнено додатковою кирилицею (українською та білоруською). Можна пожертвувати буквою Ё (кодувати її лише 2-байтним кодом чи перенести її 1-байтний код на місце якогось із символів пунктуації наприкінці таблиці), використовувати цей байт для наддовгих 4-байтних кодів; що ж стосується решти 4-байтних кодів, то їх можна замінити сурогатними парами (які кодуються, в нормі, двома 3-байтними кодами, які в нас стають двома 4-байтними наддовгими). Таким чином, базове ASCII та українська/російська/білоруська кирилиця (крім великої Ё) кодується 1-байтними кодами (аналогічно до cp866, cp1125 чи, найкраще, cp1131), 2-байтні коди UTF-8 лишаються як є, 3-байтні замінюються 4-байтними, а ще частина 4-байтних замінюється 8-байтними.

Або ж можна зберегти всі літери кирилиці, включно з Ё, а замість 3- та 4-байтних кодів використовувати наддовгі 5-байтні, що починаються з байту 0xF8. В cp866 у цій кодовій позиції стоїть знак градусу, але інші споріднені кодування використовують його для літер Ї (cp1125) чи кириличної І (cp1131). Якщо для cp1125 ще лишається варіант з наддовгими 6-байтними кодами (що починаються з 0xFC, який у ньому кодує знак №), то в cp1131 у цій позиції стоїть літера Ґ, а наддовгих 7-байтних кодів в UTF-8 не існує — тобто, в cp1131 доведеться пожертвувати або Ё, або І, або Ґ.

[Python]

Щось подібне можна спробувати зробити і з кодуваннями, основний кириличний блок яких розміщено в області байтів початку utf-8-послідовностей, але зробити це буде складніше. Вірніше, якби кирилиця займала лише область 0xC0...0xFF, це б труднощів не викликало, але, в випадку cp1251 та KOI8-U/-RU/-F, частина українських літер лежить в області 0x80...0xBF — байтів продовження, розміщення яких поруч з байтами початку буде сприйнято як код UTF-8.

Отже, в гібриді KOI8-* та UTF-8 вводиться правило: якщо після байту початку йде байт продовження, що відповідає кириличній літері, то ці два байти обробляються як дві кириличні літери. Якщо ж юнікодівський символ в UTF-8 кодується n-байтним кодом, в якому другий байт є кириличною літерою, то його слід замінити наддовгим (n+1)-байтним кодом; якщо другий байт є кириличною літерою і в ньому, то замінити наддовгим (n+2)-байтним кодом. В (n+2)-байтному наддовгому коді другий байт гарантовано буде 0x80, що в KOI8-U, KOI8-RU, KOI8-F містить нелітерний символ, тому ще довші наддовгі коди не знадобляться. Зрозуміло, що в KOI8-U таких замін буде менше, а в KOI8-F — більше, бо більше додаткових кириличних літер, комбінацій з якими доведеться уникати.

На жаль, для windows-1251 цей метод не працює: байт 0x80 там кодує літеру Ђ, тому частину кодів принципово неможливо буде замінити наддовгими так, щоб другий байт не був кириличною літерою. Хіба що можна перенести Ђ в іншу кодову позицію чи зробити урізаний варіант цього кодування без сербських літер. Утім, навіть без них додатковий кириличний блок windows-1251 настільки жахливий, що питання «коли виздихає?» супроводжуватиме це кодування завжди.

[Python]

Гібрид ДОС-кирилиці з UTF-8 можна зробити ще таким чином: кодувати більшість 3-байтних символів як наддовгі 4-байтні (що починаються з 0xF0), а більшість 4-байтних — як 6-байтні послідовності CESU-8 (що починаються з 0xED), також деяка частина 3- та 4-байтних кодів, що починаються з цих байтів, але не є ні наддовгими, ні CESU-8, може кодуватись як в UTF-8. У ДОС-кодуваннях ці байти початку відповідають літерам «Ё» та «э» — на їх місці необхідно розмістити нелітерні символи, щоб уникнути злипання однобайтних літер у слові в багатобайтні коди. Тоді  велика «Э» та мала́ «ё» залишаться без пари — щоб це виправити, можна викинути малу «ё» й розмістити на її місці малу «э». Такий набір символів стане несумісним з білоруською мовою (де Ёё є обов'язковою буквою на письмі, на відміну від російської, де без цих витребеньок можна обійтися), тому має сенс узяти за основу такого кодування не cp866, а cp1125, в якому білоруська початково не підтримується, зате є повний український алфавіт. Я взяв за основу кодування FreeDOS 30039 — варіант 1125 з заміною ¤ на ₴ та деякими іншими відмінностями; у кодових позиціях, які довелося звільнити від літер, можна розмістити знаки валют € та ₿. Таким чином, набіо однобайтних кодів цього кодування матиме такий вигляд:

Однобайтний варіант лишається повністю сумісним з українськими (а також болгарськими) текстами в cp1125, російські тексти в cp866/cp1125 стають частково несумісними (через іншу позицію малої «э»), потребують перекодування.

У багатобайтному варіанті використовуються всі однобайтні коди, але поєднання байтів початку (0xC0...0xDF, 0xED, 0xF0) з байтами продовження (0x80...0xBF) обробляються як коди utf-8 (стандартні та наддовгі). Більша частина байтів продовження є одночасно кириличними літерами, але жоден з байтів початку не є літерою — таким чином, випадкове утворення цих комбінацій у словах є малоймовірним.

[Python]

Як можете бачити зі скріншоту вище, зараз бавлюся з DOSBox'ом.
Одразу виникає питання: чи не можна в ньому якось збільшити кількість символів по вертикалі (та, в ідеалі, вертикальний розмір вікна)? Майкрософтівський edit (що входить у комплект windows) під DOSBox'ом може збільшувати кількість символів (зменшуючи їх розмір), але лише на час своєї роботи. Було б зручно мати аналогічну можливість у середовищі командної оболонки.

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

Поки що не розібрався, що собою являють рідні DOSBox'івські розкладки, які підключаються командою keyb — як замінити вбудовані своїми власними (наскільки можу зрозуміти, вони мають лежати в cpi-файлах, що підключаються тією ж командою keyb, але ті CPX/CPI, що мені досі траплялись, містили лише шрифти для кодових сторінок). Утім, розкладки досить легко робляться за допомогою keyrus (причому, редагувати їх можна й тим же макрософтівським edit'ом у двійковому режимі, задавши ширину 53). Додаткові кодові сторінки (шрифти) можна брати з архівів та репозиторіїв FreeDOS, попередньо розпакувавши CPX y CPI за допомогою UPX, і підключати командою
keyb none номер_кодової_сторінки файл.cpi
або ж драйвери для саморобних шрифтів може створювати й сам evafont.

[mnashe]

Multi-Edit умеет менять высоту символа (и, следовательно, количество строк на экране); насколько я помню, это работает и под DOSbox. Если из-под Multi-Edit'а запустить DOS shell (или напрямую какую-нибудь программу), то он не меняет перед этим режим экрана (вот после возврата — проверяет, не изменился ли режим и, если надо, восстанавливает).

[mnashe]

Да, работает. Более того, оказалось, что DOSbox и режимы со 132 символами в строке успешно эмулирует, правда, с некоторой ошибкой: начиная с какой-то там строки выдаётся снова начало текстового буфера. Надо посмотреть, может, это можно исправить в настройках DOSbox (дать больше памяти под буфер, если есть такая опция).

[Python]

Знайшов дещо на ДОСБоксівському форумі — набір утиліт для перемикання текстових режимів.

[mnashe]

Режимы как таковые можно переключать и командами DOS: mode co80 и ещё несколько.
Или зайти в debug (в комплекте к DOS) и набрать несколько команд, чтобы запустить программное прерывание BIOS для переключения экрана.
Но изменение высоты символа должно сопровождаться загрузкой кастомного шрифта под этот размер, а этого нет ни в комплекте, ни в прерываниях (кроме стандартных высот: 8, 14, 16).
В моём Мulti-Edit'е такие шрифты под разные высоты есть, и есть редактор, позволяющий их создавать, копировать, редактировать.

[Python]

Досбоксівський  набір команд дещо урізаний — там нема mode. Той  mode, що входить входить у комплект windows, під  дос не працює (хоча й  .com). Треба буде поекспериментувати  з запуском під досбоксом утиліт з повноцінної ДОС.

[mnashe]

Кстати, все эти эксперименты с нестандартными кодировками вполне можно проводить в самом Multi-Edit'е. Там есть для этого все средства. И редактор символов (с возможностью копирования, конечно), и настраиваемая высота символа, и разные настройки функций разных символов (я выше приводил пример формата). Если бы дополнительно к этому нужно было ещё что-то, я бы это сделал его же средствами. (И сейчас могу, если тебе понадобится что-то, что мне не пришло в голову в своё время).

[Upliner]

Да, работает. Более того, оказалось, что DOSbox и режимы со 132 символами в строке успешно эмулирует, правда, с некоторой ошибкой: начиная с какой-то там строки выдаётся снова начало текстового буфера. Надо посмотреть, может, это можно исправить в настройках DOSbox (дать больше памяти под буфер, если есть такая опция).

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

Розвиток оригінального DosBox-а вже давно зупинився, замість нього прийшов DosBox-X. Спробував evafont -- так, під DosBox дійсно глючить, під X працює нормально. А останній навчився емулювати навіть приколи з растром. Все дивуюся, як це працює??? Як буде час, постараюся розібратися в сирцях. Ось порівняння DosBox 0.74-3 та DosBox-X 2023.05.01

[Python]

Схоже, evafont намагається завантажити за замовчуванням шрифт для інтерфейсу з BIOS, який у DOSBox'і за замовчуванням порожній чи несумісний з ним. Якщо перед запуском evafont запустити драйвер шрифту, згенерований самим же evafont'ом, то в інтерфейс підвантажується шрифт з драйвера.

[Python]

Є щонайменше 2 способи завантаження шрифтів, що конфліктують між собою. Метод, що використовує keyb, відрізняється від методу, що використовують драйвери, згенеровані evafont'ом. При перемиканні текстових відеорежимів згаданими вище утилітами, може одночасно відбуватись перемикання з одного шрифту на інший (при однаковому розмірі). У деяких режимах один з методів, використаний після іншого, перестає давати ефект, тоді як інші лишаються сприйнятливими до обох методів.

[mnashe]

В Multi-Edit'е всё работает корректно, никаких проблем со шрифтами нет.

[Upliner]

В Multi-Edit'е всё работает корректно, никаких проблем со шрифтами нет.

Ну, зрозуміло, что нема TSR (Terminate & Stay Resident) -- нема проблем. Я так зрозумів, Python хоче зробити шрифти й використовувати їх в інших програмах.

[mnashe]

Кстати, смену шрифтов при помощи TSR я реализовал ещё на монохромной видеоплате Hercules, где функции смены шрифтов нет вообще. Программа устанавливала адрес буфера графической памяти  отличным от адреса текстового буфера; создавала в обычной памяти буфер, куда копировала текст с экрана, затем переводила экран в графический режим, выводила текст на экран в выбранном шрифте, и затем по таймеру периодически сверяла содержимое текстового буфера контроллера и своего собственного, и выводила на графический экран только то, что изменилось. Таким образом даже на моём 386SX поддерживалась приемлемая скорость.

Но тут я имел в виду, что, возможно, средств Multi-Edit'а, запущенного под эмулятором, хватит вообще для всех задач, связанных со шрифтами. Недостающий функционал, если и есть, легко написать в нём же, плюс есть возможность запуска программ из-под него (в памяти при этом остаётся порядка 70 килобайт, что, конечно, много в сравнении с TSR, но для многих применений некритично).

[Python]

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

Виникає питання, як ці дві частини можуть обмінюватись даними. Перше, що можу придумати — змонтувати директорію на диску (можливо, на віртуальному диску в оперативці) і обмінюватись даними через файлову систему. Недоліком такого підходу є те, що DOSBox взаємодіє з файловою системою, використовуючи кеш, і зміни на диску, зробені зовнішньою програмою у windows,  стають видимими для DOS-програм лише після того, як цей кеш очищено командою rescan. Тобто, доведеться викликати rescan при кожній перевірці повідомлень зовнішньої програми (напр., по кілька разів на секунду).

Цікаво, чи не існує якогось більш цивілізованого способу взаємодії між DOS-програмою в DOSBox'i та зовнішньою програмою у windows?

[Andrey Lukyanov]

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

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

[mnashe]

Виникає питання, як ці дві частини можуть обмінюватись даними. Перше, що можу придумати — змонтувати директорію на диску (можливо, на віртуальному диску в оперативці) і обмінюватись даними через файлову систему. Недоліком такого підходу є те, що DOSBox взаємодіє з файловою системою, використовуючи кеш, і зміни на диску, зробені зовнішньою програмою у windows,  стають видимими для DOS-програм лише після того, як цей кеш очищено командою rescan. Тобто, доведеться викликати rescan при кожній перевірці повідомлень зовнішньої програми (напр., по кілька разів на секунду).

Цікаво, чи не існує якогось більш цивілізованого способу взаємодії між DOS-програмою в DOSBox'i та зовнішньою програмою у windows?

Эта задача очень близка к моей, о которой я писал. Только у меня наоборот: основная работа идёт в Multi-Edit'е, исполняемом в виртуальной машине (XP или 7), но поскольку Multi-Edit, кроме прочего, это и «оболочка», запускающая прочие программы (скажем, запустить выбранный просмотровщик, загрузив в него текущий файл), то я хочу, чтобы запуск происходил не виртуалке, где память ограничена и не все программы есть, а в хосте. То есть мне надо из виртуалки послать команду хосту.
Простейшая реализация — записывать в определённый файл информацию о запуске (командная строка, каталог, параметры), а в хосте сканировать несколько раз в секунду, не изменилось ли время создания файла, и если изменилось, запускать. Но это уж очень неоправданный перерасход. Более умное решение — функция ожидания изменений в каталоге, которая возвращается только тогда, когда эти изменения произошли. Я уже даже нагуглил в WinApi, как это делается, но надо сесть и написать, а я уже много лет ничего не писал прямо под Windows, и надо вспоминать / учить почти с нуля.

[Eitanbor]

Виникає питання, як ці дві частини можуть обмінюватись даними. Перше, що можу придумати — змонтувати директорію на диску (можливо, на віртуальному диску в оперативці) і обмінюватись даними через файлову систему. Недоліком такого підходу є те, що DOSBox взаємодіє з файловою системою, використовуючи кеш, і зміни на диску, зробені зовнішньою програмою у windows,  стають видимими для DOS-програм лише після того, як цей кеш очищено командою rescan. Тобто, доведеться викликати rescan при кожній перевірці повідомлень зовнішньої програми (напр., по кілька разів на секунду).

Цікаво, чи не існує якогось більш цивілізованого способу взаємодії між DOS-програмою в DOSBox'i та зовнішньою програмою у windows?

Эта задача очень близка к моей, о которой я писал. Только у меня наоборот: основная работа идёт в Multi-Edit'е, исполняемом в виртуальной машине (XP или 7), но поскольку Multi-Edit, кроме прочего, это и «оболочка», запускающая прочие программы (скажем, запустить выбранный просмотровщик, загрузив в него текущий файл), то я хочу, чтобы запуск происходил не виртуалке, где память ограничена и не все программы есть, а в хосте. То есть мне надо из виртуалки послать команду хосту.
Простейшая реализация — записывать в определённый файл информацию о запуске (командная строка, каталог, параметры), а в хосте сканировать несколько раз в секунду, не изменилось ли время создания файла, и если изменилось, запускать. Но это уж очень неоправданный перерасход. Более умное решение — функция ожидания изменений в каталоге, которая возвращается только тогда, когда эти изменения произошли. Я уже даже нагуглил в WinApi, как это делается, но надо сесть и написать, а я уже много лет ничего не писал прямо под Windows, и надо вспоминать / учить почти с нуля.

Ещё надо, чтобы все это работало на 64-битных системах

[Upliner]

Ещё надо, чтобы все это работало на 64-битных системах

А какие проблемы? DosBox 64-битный есть.