Прошу шановних лінгвохворумців висловити свою думку з приводу доцільності створення української кодової сторінки, яка б дозволяла записувати тексти історичними правописами. Наявні кодові сторінки це якась ганьба, окрім коі8-у, але там ганебне сама мета його створення - щоб при передачі тексту через стародавні модеми, які урізають восьмий біт, текст залишався читаємим. Я розвів срач на форумі програмістів, тепер хочу вашої думки спитати.
Коротка вижимка з того срачу:
Цитировать
Я деякий час займався алгоритмами шифрування/кодування інформації та розробкою компілера, і побачив, наскільки застарілі й вбогі сучасні стандарти кодування інформації. Приклади:
1) Стандарт ASCII - з перших 32 кодів дійсно використовується лише 2 кода - наступний рядок і пробіл. Наприклад, код 07 огидно дзвякав у ДОСі, а до того на терміналах. Зараз те все обладнання на звалищі історії.
2) Кирилична кодова сторінка могла б вмістити знаки усіх історичних українських правописів(з того, що зараз пригадую - желехівка, кулішівка(чинний), галицький в довоєнній польщі(латиниця), ярижка в рос. імперії, максимовичка) і про білорусів з росіянами не забули б, бо сучасна іміджбордова культура включає слово Няўка з кратким у. Проте, сучасні кириличні кодові сторінки поділяються на ті що з ґ і ті що без ґ. А нещасний оцифровувач давніх українськи рукописів (ізборник) вигадував свій шрифт.
3) В XML для кодування і зберігання бінарних даних можливо використовувати лише BASE64. Хоча кодування BASE85 має кращу щільність, його використання неможливе через співпадіння абетки BASE85 з керуючими символами XML.
4) Багато мережевих програм сприймають лише 7-бітові послідовності, а тому все що виходить за межі кодується BASE64 або в кращому разі BASE85.
5) Використання кодувань з родини ЮНІКОД'ів часто не вирішує питання, а лише жере машинні ресурси, що унеможливлює або затрудняє використання потрібних символів у вбудованих системах.
Цитировать
1. Пробіл не входить в перші 32 символи; обмежене використання мають backspace, linefeed (в парі з CR), ESC.
2. Хіба за рахунок псевдографіки. А вона теж ще використовується.
3. XML за структурою має низьку щільність. Хочете високої - пакуйте.
4. А ви тільки що за розширення кодової сторінки ратували... Нащо, якщо все одно не влазить?
5. Юнікод вирішує практично всі проблеми, пов'язані з кодуванням. Так, щільність низька - але то вже до ущільнювачів питання, не до кодування. Неможливо закодувати 100500 алфавітів так, щоб запис на будь-якому з них мав високу щільність.
Цитировать
1. Я розумію що CR/LF/CRLF використовуються та ще й табуляція, але (особливо перше) навіщо? Коли в останнє отой CRLF використовувався в принтерах "ромашка" - гібриду принтера із друкарською машинкою, який окремо вертав каретку і окремо переходив до нового рядка? Мабуть давно це було і вже тоді можна було обійтися без цього.
2. В сучасній CP1251 є все що завгодно, окрім того, що використовується. Навіть складно уявити, як можна писати тексти без ¤, ¦, †, ‡, резерву 0x98 і 10 символів лапок. До речі в кодуванні СР866 була відсутня літера і, а обходилися західноєвропейською. Треба ще визначитися, чи потрібно взагалі дублювати аналогічні латинським літери. Якщо раніше ніхто не відчував себе ущємльонним за язик, то може не треба і інші літери дублювати?
3,4. Використання кодових сторінок ще доцільно з міркувань підтримки застарілим або просто нескладним обладнанням. Наприклад, ІБМ-ПЦ архітектура має текстовий режим роботи відеосистеми, який навіть досі використовується - нейтів віндовз програми. Я ратую скоріше за одмежування ASCII від мережевих технологій, бо страшне - де-факто використовується 6 біт замість 8. Занадто вже важка спадщина сумісності.
5. Погоджуюсь, ЮНІКОД і ЮТФ8 мені самому подобається, але європейських абеток всеж не 100500 і тим більше не всі з них одночасно використовуються в одному документі.
Цитировать
1. Можна, але з історичних причин краще залишити як є - бо тоді виникає питання, що саме пхати на місце старих символів, а тут можливі різні погляди. Ви хочете ще 100500 різновидів utf-8 з різницею в перших 32 кодах?
2. Так, в CP1251 є одне, в CP866 інше, а в KOI8-U - третє. І це - природний наслідок однобайтності: різним людям треба запхати різне, а кодування не гумове.
3, 4. Як ви пропонуєте відмежовуватися - розробити новий, 100500-й, UTF, що не базуватиметься на ASCII?
5. А що, в світі існують тільки європейські абетки? Чи ви пропонуєте, щоб були окремі кодування для різних частин світу? Чи навіть створювати своє унікальне і неповторне кодування для кожної комбінації абеток і спеціальних символів в документі?
Давайте скажемо так: здавна існувало 100500 різних алфавітів. Вони мають різний ступінь спорідненості, купу діакритики і інших особливостей. І один з цих алфавітів, базований на англійському, зветься ASCII; і нема жодних підстав проігнорувати його, особливо з урахуванням його значення в розвитку комп'ютерних технологій. І якщо ми хочемо створити мати єдине кодування для всіх (а без цього буде безлад), то це кодування має певним чином відображати символи ASCII (і всіх інших поширених кодувань).
Цитировать
Цитировать2. Так, в CP1251 є одне, в CP866 інше, а в KOI8-U - третє. І це - природний наслідок однобайтності: різним людям треба запхати різне, а кодування не гумове.
Вірно, проте мене турбує не природній наслідок однобайтності, а неприродній наслідок Сталіна, Постишева і Косіора. Білорусів до того дореформували, що вже мови вважай що нема. Того я вважаю, що українська кодова сторінка має включати спадок
Цитировать3, 4. Як ви пропонуєте відмежовуватися - розробити новий, 100500-й, UTF, що не базуватиметься на ASCII?
Більш за всього мене вразив формат електронного листа - коди більш за 127 не можна, бо 30 років тому модеми передвавли лише 7 біт і коди менше за 33 не можна, бо програма для зворотньої сумісності ігнорує ті символи, тому всі вкладення кодуються БЕЙС64. Так жить нізя! Треба ті технології викинути на звалище історії.
Цитировать5. А що, в світі існують тільки європейські абетки? Чи ви пропонуєте, щоб були окремі кодування для різних частин світу?
І так і ні, бо Європа самодостатнє утворення, яке створює контент, тому очевидно, що суто двобайтне кодування задовільнить 98% її потреб, а все інше - "духовність" і "самобутність". Для китайців і 3 байти буде замало. Кількість байт я навів лише для прикладу. Сам я поки схиляюся до перемикання "кодових сторінок" і в деяких випадках - власна абетка документа. Тобто існує "головна" системна абетка, а в заголовці документа прописується її підмножина для ущільненого кодування.
Цитировать
А я вважаю, що не має бути української кодової сторінки взагалі - має бути український розділ в єдиному кодуванні.
Для того, аби щось викинути, треба спершу придумати заміну. І вона існує - різні XMPP, Skype і т.д. Там все гаразд з кодуванням. А не подобається e-mail - то не користуйтеся.
Самодостатній тільки Господь Бог. Європа потребувала, потребує і потребуватиме купу різного контенту з інших країн, причому ця взаємозалежність тільки посилюється. Це не добре і не погано, це є. До речі, для історичних європейських алфавітів 1 байту не вистачить, навіть якщо не вважати вірмен і грузин за європейців.
А китайцям для 99,99% випадків вистачає 2 байтів (більшість незвичайних ієрогліфів - терміни китайської традиційної медицини, введені конкретними лікарями для конкретних, давно спростованих, теорій).
Що ви думаєте?
В часи поширеності UTF-8 та інших юнікодівських форматів кодування, проблема створення національних кодових сторінок є не настільки актуальною. Хоча технічно реалізувати підтримку ще одного кодування не складно, як на рівні ОС, так і на рівні допоміжних платформ назразок JVM.
А чим саме Вас не влаштовують існуючі 8-бітні кодування (CP1251, KOI8-U)? Щодо CP866 зрозуміло — там є не всі українські літери (хоча також існує трохи призабуте українське ГОСТ-кодування (воно ж CP1125 або RUSCII), близьке до CP866 (хоч і несумісне з ним у частині українських літер), де український алфавіт представлено повністю).
Якщо ж мова йде про історичні правописи, мені здається, простіше використовувати UTF-8, де всі чи більшість історичних літер кирилиці або вже є, або можуть бути замінені візуально схожими символами. Недолік такого способу — неможливість використовувати юнікод у застарілому програмному забезпеченні, розрахованому на 8-бітне кодування. Звичайно, можна погратися (напр., узяти CP1251 і замінити частину символів історичними літерами), але зробити таке кодування загальноприйнятим стандартом буде складно — UTF-8 насьогодні значно поширеніше й має деякі переваги перед 8-бітними кодуваннями.
До речі, питання в заголовку поставлено некоректно. Бо ASCII в чистому вигляді включає в себе лише коди 0...127, які в більшості національних кодувань заповнені тими ж символами (англійський алфавіт, цифри, пунктуація, математичні та ін. знаки, службові коди). UTF-8 — також ASCII-сумісне кодування. ASCII як семибітне кодування «виздихало» вже, але продовжує існувати як частина сумісних із ним 8-бітних кодувань, які «виздихувати» поки що не збираються.
Ймовірно, задумане Вами кодування — також ASCII-сумісне. Чи Ви плануєте зробити українську кодову сторінку ASCII-несумісною (але навіщо?)?
Ще одне кодування? Ні, дякую. І так доводиться згадувати незлим тихим тих, хто в час Юнікоду використовує подібні збочення.
ЦитироватьА чим саме Вас не влаштовують існуючі 8-бітні кодування (CP1251, KOI8-U)? Щодо CP866 зрозуміло — там є не всі українські літери (хоча також існує трохи призабуте українське ГОСТ-кодування (воно ж CP1125 або RUSCII), близьке до CP866 (хоч і несумісне з ним у частині українських літер), де український алфавіт представлено повністю).
Найменше, чому КОІ8-U не підходить - відсутність ня
ўок. Хоча я вважаю його найкращим серед наявних. CP1251 занадто схиблений на копірастії. Мене бісить, що на ізборнику замість православного ѣ - сербське страхолюдіє - Ђ >( . Кодова сторінка потрібна не тільки для застарілого обладнання, а й для використання в текстовому режимі сучасних відеоадаптерів, який часто застосовується на початкових етапах завантаження системи (БІОС, завантажувачі ОС, віндовз нейтів програми).
ЦитироватьЗвичайно, можна погратися (напр., узяти CP1251 і замінити частину символів історичними літерами), але зробити таке кодування загальноприйнятим стандартом буде складно — UTF-8 насьогодні значно поширеніше й має деякі переваги перед
8-бітними кодуваннями.
Я не кажу про світове панування, тут скоріше питання в тому, щоб забрати монополію на абетку в товариша Сталіна з копірастами. UTF-8 безперечно набагато краще, ніж плутанина з кодовими сторінками, але по-перше вони забагато віддають ASCII, яке застаріле - я вище писав про використання кодів 0-31, по-друге я чув невдоволеність китайських товаришів уніфікацією їхніх єрогліфів.
ЦитироватьДо речі, питання в заголовку поставлено некоректно. Бо ASCII в чистому вигляді включає в себе лише коди 0...127.
Питання поставлене коректно, бо це мене теж цікавить. Але я розумію, що кодові сторінки будуть жити принаймні доки живий АйБіЕм ПіСі, я вище написав чому.
ЦитироватьХоча технічно реалізувати підтримку ще одного кодування не складно, як на рівні ОС, так і на рівні допоміжних платформ назразок JVM.
Зараз я розробляю таку допоміжну платформу, яку можна буде використовувати в будь-якому "тостері" - від мс-дос до зх спектруму з 16кб пам'яті. Особливістю платформи буде висока оптимізованість мовою асемблера з усілякими біт-хаками. На він32 х86 платформі результат вже перевершив мої сподівання. Тому я й подумав, що непогано було б дати доступ до українського контенту з кожної "праски".
Цитата: DADA11C7 от марта 2, 2014, 03:19
CP1251 занадто схиблений на копірастії.
Що саме мається на увазі?
Цитата: DADA11C7 от марта 1, 2014, 02:31
А нещасний оцифровувач давніх українськи рукописів (ізборник) вигадував свій шрифт.
ІМНО, Ізборник давно треба переконвертувати на нормальний UTF-8. Ять та інші архаїчні літери є в багатьох шрифтах, що постачаються разом із сучасними операційними системами. Модифікований шрифт, зроблений для передачі давньої кирилиці засобами CP1251, сьогодні вже виглядає як анахронізм.
Цитата: DADA11C7 от марта 2, 2014, 03:19
Найменше, чому КОІ8-U не підходить - відсутність няўок.
Білоруське Ў є в (wiki/uk) KOI-8#Кодування_KOI8-RU_(російсько-українсько-білоруське) (http://uk.wikipedia.org/wiki/KOI-8#.D0.9A.D0.BE.D0.B4.D1.83.D0.B2.D0.B0.D0.BD.D0.BD.D1.8F_KOI8-RU_.28.D1.80.D0.BE.D1.81.D1.96.D0.B9.D1.81.D1.8C.D0.BA.D0.BE-.D1.83.D0.BA.D1.80.D0.B0.D1.97.D0.BD.D1.81.D1.8C.D0.BA.D0.BE-.D0.B1.D1.96.D0.BB.D0.BE.D1.80.D1.83.D1.81.D1.8C.D0.BA.D0.B5.29) (не плутати з KOI8-R).
Цитата: DADA11C7 от марта 2, 2014, 03:19
Кодова сторінка потрібна не тільки для застарілого обладнання, а й для використання в текстовому режимі сучасних відеоадаптерів, який часто застосовується на початкових етапах завантаження системи (БІОС, завантажувачі ОС, віндовз нейтів програми).
Чи справді потрібна історична кирилиця на етапі завантаження операційної системи? Як правило, там усе англійською пишеться...
З погляду сучасності (8 років після старту теми). Попри те, що ніша 8-бітних національних кодувань вузька і продовжує звужуватись, не можна сказати, що вона зникла остаточно. За час, відколи було створено останню восьмибітку з повним українським алфавітом, з'явились деякі нові випадки, пов'язані з українською графікою, не враховані в жодному з цих кодувань:
— символ гривні ₴ (з'явився раніше символа рубля, але вже після євро. CP1251 має лише євро).
— апостроф-літера ʼ (рідко використовується, але в кириличних доменних іменах можна використовувати лише цей апостроф. В cp1251 є два інші апострофи, це не рахуючи гравісу, який теж інколи використовують у цій ролі. Можна розмістити на місці верхніх одинарних лапо́к ' , які часто використовуються в ролі правильного апострофа й графічно тотожні апострофу-літері).
З того, що було б варто додати давно, але так і не додали:
— комбінований наголос ́ (здавна використовується в українській мові, подекуди є змістотворчим; протЕз у вИгляді велИких лІтер нікУди не годИться. cp1251 комбінованих діакритиків не містить, хоча її використання і не обмежується шрифтами з фіксованою шириною символів, тому, в принципі, це не заборонено).
— комбінована надрядкова дужка ͡ (використовується в мовознавстві при позначенні звуків д͡ж та д͡з, хоча в загальному випадку не вживається, тому можна обійтися).
Для передачі текстів ХІХ ст.:
— ять Ѣѣ. (Якщо не дбати про сумісність з сербською графікою, можна ввіткнути на місце Ђђ, хоча можна й підшукати інші кодові позиції).
— комбінований циркумфлекс ̂ (літери з ним присутні в максимовичівці та похідних від неї орфографіях. Як варіант, можна виділити окремі позиції для всіх літер з дашком, що має сенс з точки зору текстової консолі, але місця для всіх обмаль, тому ні).
— інші давні літери (Ѳѳ, Ѵѵ, вже не кажучи про Ѫѫ, Ѧѧ, Ѯѯ, Ѱѱ тощо) в українських текстах якщо й використовуються, то рідко. Сюди ж — титло, діакритики з правопису Гацука та інша церковна архаїка. У спеціалізованому кодуванні, розрахованому на стару кирилицю (старо-/церковнослов'янську, староукраїнську), це б мало сенс, але в загальному випадку без них можна обійтися.
Таким чином, маємо три символи (₴, ʼ, ́ ), які дуже бажано включити до кодування на основі cp1251 для повноцінної передачі сучасних українських текстів та використання в доменних іменах. Ще три (Ѣ, ѣ, ̂ ) зробили б це кодування придатним і для більшості українських текстів ХІХ ст. Якщо cp1251 має одну порожню кодову позицію, і ще ряд символів з неї в українській мові не використовуються, то простір для змін є...
Цитата: Python от марта 2, 2014, 05:40
Цитата: DADA11C7 от марта 1, 2014, 02:31
А нещасний оцифровувач давніх українськи рукописів (ізборник) вигадував свій шрифт.
ІМНО, Ізборник давно треба переконвертувати на нормальний UTF-8. Ять та інші архаїчні літери є в багатьох шрифтах, що постачаються разом із сучасними операційними системами. Модифікований шрифт, зроблений для передачі давньої кирилиці засобами CP1251, сьогодні вже виглядає як анахронізм.
Так,
ґєрвь ґерев бісить.
Цитата: Python от марта 2, 2014, 05:40
ІМНО, Ізборник давно треба переконвертувати на нормальний UTF-8.
Я теж так казав. Як мінімум можна було використовувати Ѣѣ для ятів, що цілком відповідає сучасним стандартам незалежно від обраної кодової сторінки.
Цитата: Python от января 13, 2022, 15:13
— комбінована надрядкова дужка ͡ (використовується в мовознавстві при позначенні звуків д͡ж та д͡з, хоча в загальному випадку не вживається, тому можна обійтися).
Для них є букви Ԫ ԫ Ꚉ ꚉ.
Цитата: Drundia от марта 22, 2022, 01:30
Для них є букви Ԫ ԫ Ꚉ ꚉ.
Або Џџ та Ѕѕ. Проте, сучасним українцям ні ці лігатури, ні сербо-македонські літери невідомі (в історичних українських правописах лише Џ пофункціонувало в цій ролі, решта ж або використовувались лише іншими мовами, або, в випадку Ѕ, в місцевих історичних правописах виконували дещо іншу функцію), а диграфи з надрядковою дужкою відомі, принаймні, з підручників української мови, використовуваних у наш час.
Цитата: Python от марта 22, 2022, 02:03
Проте, сучасним українцям ні ці лігатури
Так само відомі з підручників і словників.
Цитата: Drundia от марта 24, 2022, 01:53
Цитата: Python от марта 22, 2022, 02:03
Проте, сучасним українцям ні ці лігатури
Так само відомі з підручників і словників.
Я бачив їх використання лише на сканах старих газет, причому, неукраїнських — якась із ранніх радянських неслов'янських кирилиць. В українських джерелах, може, десь хтось колись і задіяв ці лігатури, але мені такі приклади бачити на власні очі не доводилось. На відміну від д͡ж та д͡з, які кочують з підручника в підручник, а в одному словнику навіть регулярно використовувались у тексті, поруч із регулярно проставленими наголосами.
Цитата: Python от марта 24, 2022, 05:25
В українських джерелах, може, десь хтось колись і задіяв ці лігатури, але мені такі приклади бачити на власні очі не доводилось.
Орфоепічні словники.
Повертаючись до ідеї української кодової сторінки, не на користь лігатур чи окремих літер також і те, що для них доведеться відвести чотири кодові позиції (що, в випадку восьмибітних кодувань, марнотратство), тоді як діакритик займе лише одну. Тим більше, варіант із діакритиком в українських мовознавчих текстах найбільш поширений — отже, реалізувати слід у першу чергу його.
Діакритики, однак — вічна головна болячка для шрифтів з фіксованою шириною символів (якщо в нас кодова сторінка для дисплеїв, то там саме такі шрифти) — з цієї точки зору, варіант з окремими літерами має сенс. В принципі, можна виділити чотири кодові позиції, а графічну реалізацію залишити на розсуд розробників шрифтів (або Џ џ Ѕ ѕ, або Ԫ ԫ Ꚉ ꚉ, або навіть Д͡ж д͡ж Д͡з д͡з — утиснувши кожен диграф у гліф стандартного розміру; проте, літера «ж» сама по собі широка — стиснення надто кидатиметься в вічі).
Ще одна фантазія на тему українського восьмибітного кодування. Як ми знаємо, кодова сторінка 866 окремого коду для кириличної Іі не має — натомість можна використовувати графічно тотожну їй латинську. Що, як поширити цю практику й на інші кириличні літери, що мають графічних двійників у базовому наборі ASCII? Особливо якщо взяти за основу «болгарські» шрифти — тоді функція кириличної літери додатково ляже на Aa6BDgEe3uIiKkMHOonPpCcTmyXx, а додаткового місця в кодовій таблиці потребуватимуть лише БвГ㥴ЄєЖжзИЇїЙйЛлмнПУФфЦцЧчШшЩщЬьЮюЯя — всього 38 (замість 66 для повної української кирилиці).
Звичайно, такий підхід має недоліки (складніше сортувати текст, робити перетворення між великими й малими літерами тощо). Але можна використовувати це кодування лише для виводу даних, тоді як замість внутрішнього використати, наприклад, юнікодівські коди.
38 літер кирилиці. В принципі, таку кількість можна втиснути навіть і в 7-бітне кодування, споріднене з ASCII — розмістивши кирилицю на місці невикористовуваних керуючих кодів (понад два десятки в проміжку між нуль-символом та пробілом) та частини малозатребуваних в українській мові символів (@, #, $... Втім, це надто радикально).
Отже, в нас лишається сотня з гаком вільних кодів у верхній частині таблиці (тобто, з кодами 128 і вище). Чим їх заповнити? Наприклад, символами алфавітів інших мов, історично поширених на нашій території (польські додаткові літери, єврейське письмо).
Ще треба дивитись, які можливості дає наш анахронічний пристрій виводу. Якщо це текстовий дисплей з прямокутним растровим малюнком для кожного символа без можливості їхнього накладення, нічого особливо цікавого ми не придумаємо. Трохи цікавіше, якщо малюнок симола може продовжуватись в області сусідніх символів — це дозволить нам використовувати приєднувані діакрити (акут, огонек, верхня крапка, діерезис, кратка...) замість окремих кодів для літер (польські додаткові літери, кириличні ЇїЙй тепер збиратимуться з літери та діакритика, також можна ставити наголос та збирати білоруські ЁёЎў; огонек, як у польській ą, якщо його правильно позиціонувати, зійде й за хвостик літер цЩщ). Якщо ж це, наприклад, щось назразок електронної друкарської машинки, що може накладати символи один на одного шляхом переміщення каретки, це ще краще з точки зору економії кодів, адже тепер можна частину діакритиків сумістити з замостійними символами (акут як накладений апостроф, діерезис як накладені лапки...). Варіант з діакритиками чи накладеннями зможе охопити не лише польську, а й деякі інші латиниці (литовську, чеську тощо).
Забув про білорусько-російське Ээ. В принципі, можна виділити окремі коди й для цієї літери, якщо буде місце. Або ж скористатися тим, що в жодному з сучасних алфавітів нема Э та Є одночасно — тоді Є зійде за сурогат Э. Щоб цей сурогат менш кидався в вічі, літеру Єє можна зробити погано промальованою, щоб дірку в ній можна було побачити з однаковим успіхом і праворуч, і ліворуч (утім, така шрифтова маніпуляція погіршить вигляд українського тексту). Що ж стосується Ъъ, замість нього в російській мові дозволяється, в разі необхідності, писати апостроф — виходить, він потрібен, лише якщо ми хочемо зробити підтримку болгарської мови (цікаво, чи можлива одноєрова система в сучасній болгарській, з Ь у ролі Ъ?). Білорусько-російське Ы збираємо з двох літер: ЬI (ьі, проте, кидатиметься в вічі — краще виділити для ы окремий код).
Вот такой кодовой страницей я пользуюсь в Multi-Edit'е уже много лет. Здесь ивритица на своём месте и, что очень удобно, строчные русские буквы на своём месте, так что текст без капсов, набранный в обычной CP-866, прекрасно читается (вместо заглавных букв выходит ивритица).
(https://images.lingvoforum.net/images/2023/03/27/862R.png)
Заглавные буквы распихал где попало, пришлось даже область символов управления (00-1F) задействовать. Но я встроил в редактор специальный механизм, позволяющий отображать текст, набранный в CP-866 (или любой другой — карта настраивается) в шрифте, сделанном в этой моей модифицированной кодовой странице на базе CP-862.
Для украинских букв места не хватило, но если отказаться от размещения строчных букв на своих местах, то освободятся ещё 7 позиций, так что влезут все три буквы (×2).
Цитата: mnashe от марта 27, 2023, 13:20Вот такой кодовой страницей я пользуюсь в Multi-Edit'е уже много лет. Здесь ивритица на своём месте и, что очень удобно, строчные русские буквы на своём месте, так что текст без капсов, набранный в обычной CP-866, прекрасно читается (вместо заглавных букв выходит ивритица).
(https://images.lingvoforum.net/images/2023/03/27/862R.png)
Заглавные буквы распихал где попало, пришлось даже область символов управления (00-1F) задействовать. Но я встроил в редактор специальный механизм, позволяющий отображать текст, набранный в CP-866 (или любой другой — карта настраивается) в шрифте, сделанном в этой моей модифицированной кодовой странице на базе CP-862.
Для украинских букв места не хватило, но если отказаться от размещения строчных букв на своих местах, то освободятся ещё 7 позиций, так что влезут все три буквы (×2).
А є там Юнікод?
Цитата: mnashe от марта 27, 2023, 13:20Вот такой кодовой страницей я пользуюсь в Multi-Edit'е уже много лет. Здесь ивритица на своём месте и, что очень удобно, строчные русские буквы на своём месте, так что текст без капсов, набранный в обычной CP-866, прекрасно читается (вместо заглавных букв выходит ивритица).
(https://images.lingvoforum.net/images/2023/03/27/862R.png)
Заглавные буквы распихал где попало, пришлось даже область символов управления (00-1F) задействовать. Но я встроил в редактор специальный механизм, позволяющий отображать текст, набранный в CP-866 (или любой другой — карта настраивается) в шрифте, сделанном в этой моей модифицированной кодовой странице на базе CP-862.
Для украинских букв места не хватило, но если отказаться от размещения строчных букв на своих местах, то освободятся ещё 7 позиций, так что влезут все три буквы (×2).
А що там роблять символи B0-DF, можна запитати?
Цитата: mnashe от марта 27, 2023, 13:20Заглавные буквы распихал где попало, пришлось даже область символов управления (00-1F) задействовать.
В принципі, це те, що я пропонував вище, але деякі з кодів (08, 09, 0a, 0d) я б оминув. Якщо вивід здійснюється прямим записом у відеопам'ять текстового дисплея, графіку можна повісити й на них, але якщо виводити їх через стандартний вивід, то вони потрібні для керування рухом курсора, і їхні гліфи не відображатимуться.
Цитата: Eitanbor от марта 27, 2023, 15:13А що там роблять символи B0-DF, можна запитати?
Очевидно, потрібні для малювання інтерфейсу Multi-Edit'а. Втім, якщо переробити його так, щоб він псевдографіку відображав символами базового ASCII, то цю область можна буде використати для якихось інших символів.
Цитата: Python от марта 27, 2023, 16:28Цитата: Eitanbor от марта 27, 2023, 15:13А що там роблять символи B0-DF, можна запитати?
Очевидно, потрібні для малювання інтерфейсу Multi-Edit'а. Втім, якщо переробити його так, щоб він псевдографіку відображав символами базового ASCII, то цю область можна буде використати для якихось інших символів.
Це щє з MS-DOS?
Так кажете, ніби є щось погане в користуванні софтом, який їсть кілобайти оперативки замість гігабайтів, при тому ж функціоналі.
Цитата: Python от марта 27, 2023, 21:19Так кажете, ніби є щось погане в користуванні софтом, який їсть кілобайти оперативки замість гігабайтів, при тому ж функціоналі.
1) Тоді як його запускати без емуляторів?
2) Чи можна на MS-DOS використовувати графічні відеорежими з Unicode'ом та Widechar'ом замість текстових?
Цитата: Eitanbor от марта 27, 2023, 23:262) Чи можна на MS-DOS використовувати графічні відеорежими з Unicode'ом та Widechar'ом замість текстових?
Можна ще з часів CGA, але це не так цікаво, і там зовсім інший підхід.
Якщо ж ми хочемо працювати з текстовою відеопам'яттю, то схоже, що ні, але можна забезпечити підтримку підмножини юнікоду за допомогою саморобної кодової сторінки. Тобто, можна зробити текстовий редактор для файлів в UTF-8, що містять латиницю, кирилицю й іврит одночасно, який працюватиме під чистим MS-DOS у текстовому режимі, конвертуючи utf-8 у коди цієї сторінки. Якщо треба щось за межами цієї підмножини (напр., глаголиця, руни чи просто символ, що не потрапив до нашої кодової сторінки), то такий редактор відобразити це не зможе, звичайно.
Ну, а так, можна зробити й програму під віндовс, що працює в консольному текстововму вікні з юнікодівськими символами. Але тоді питання кодової сторінки стає непринциповим (якщо тільки ми не хочемо ще й працювати в повноекранному текстовому режимі, але його прибрали ще в Windows-8).
Цитата: Eitanbor от марта 27, 2023, 23:261) Тоді як його запускати без емуляторів?
Навіщо без емуляторів? Тобто, так, можна паралельно поставити MS-DOS як ще одну операційну систему й працювати без емулятора, але в чому проблема запускати з емулятором?
Цитата: Python от марта 28, 2023, 00:09Цитата: Eitanbor от марта 27, 2023, 23:261) Тоді як його запускати без емуляторів?
Навіщо без емуляторів? Тобто, так, можна паралельно поставити MS-DOS як ще одну операційну систему й працювати без емулятора, але в чому проблема запускати з емулятором?
Не у всіх він є (якщо, звісно, не йде мова про ретрокомпьютинг. Тоді це нишеве, для MS-DOS).
Якщо вісімка чи щось старіше, то додатково встановлювати емулятор для ДОС ще непотрібно, наскільки я розумію.
Цитата: Python от марта 1, 2014, 02:58Якщо ж мова йде про історичні правописи, мені здається, простіше використовувати UTF-8, де всі чи більшість історичних літер кирилиці або вже є, або можуть бути замінені візуально схожими символами. Недолік такого способу — неможливість використовувати юнікод у застарілому програмному забезпеченні, розрахованому на 8-бітне кодування. Звичайно, можна погратися (напр., узяти CP1251 і замінити частину символів історичними літерами), але зробити таке кодування загальноприйнятим стандартом буде складно — UTF-8 насьогодні значно поширеніше й має деякі переваги перед 8-бітними кодуваннями.
На Windows 10 можна поставити 8-бітне кодування не тільки різноманітні кодування, такі як Windows-1251, але навіть UTF-8
EGA/VGA дозволяє використовувати 512 символів одночасно, але за рахунок використання меншої кількості кольорів (8 замість 16).
Цитата: Andrey Lukyanov от марта 28, 2023, 09:34EGA/VGA дозволяє використовувати 512 символів одночасно, але за рахунок використання меншої кількості кольорів (8 замість 16).
Менша кількість кольорів на символ, чи на фон?
Цитата: Eitanbor от марта 28, 2023, 10:11Цитата: Andrey Lukyanov от марта 28, 2023, 09:34EGA/VGA дозволяє використовувати 512 символів одночасно, але за рахунок використання меншої кількості кольорів (8 замість 16).
Менша кількість кольорів на символ, чи на фон?
Начебто на символ.
Як програміст, мушу зазначити, що ASCII дуже зручна і подекуди незамінна. Звісно, якщо ти працюєш із простими текстами, простими повідомленнями, які не вимагають нестандартних символів.
Не можу бажати зникнення цьому кодуванню.
Цитата: DarkMax2 от марта 28, 2023, 11:55Як програміст, мушу зазначити, що ASCII дуже зручна і подекуди незамінна. Звісно, якщо ти працюєш із простими текстами, простими повідомленнями, які не вимагають нестандартних символів.
Не можу бажати зникнення цьому кодуванню.
Ба більше, UTF-8 сумісний з ASCII
Цитата: mnashe от марта 28, 2023, 21:13Цитата: Eitanbor от марта 27, 2023, 15:11А є там Юнікод?
Нема, це DOS-програма.
DOS-програма також може використовувати Юнікод. Але всі перекодування вона повинна робити сама.
Поправляйте, пожалуйста, мои ошибки, если заметите
Цитата: Python от марта 27, 2023, 16:12Якщо вивід здійснюється прямим записом у відеопам'ять текстового дисплея, графіку можна повісити й на них, але якщо виводити їх через стандартний вивід, то вони потрібні для керування рухом курсора, і їхні гліфи не відображатимуться.
Так :yes:
Цитата: Python от марта 27, 2023, 16:28ЦитироватьА що там роблять символи B0-DF, можна запитати?
Очевидно, потрібні для малювання інтерфейсу Multi-Edit'а
Рамка на моєму скриншоті ілюструє використання псевдографіки.
Без неї неможливо робити таблиці, багато елементів інтерфейсу...
Цитата: Python от марта 27, 2023, 21:19Так кажете, ніби є щось погане в користуванні софтом, який їсть кілобайти оперативки замість гігабайтів, при тому ж функціоналі.
Так, без нього я як без рук.
Цитата: Eitanbor от марта 27, 2023, 23:261) Тоді як його запускати без емуляторів?
Емулятор встановити простіше ніж віртуалку, але це дуже незручно. По-перше, емуляція працює дуже повільно. По-друге, емулятор емулює лише DOS, але моя програма вміє інтегруватись у Windows: запускати програми, працювати з Clipboard та з LFN (long file names). В емуляторі все це недоступно.
Цитата: Eitanbor от марта 27, 2023, 23:262) Чи можна на MS-DOS використовувати графічні відеорежими з Unicode'ом та Widechar'ом замість текстових?
Це можливо, якщо переробити програму. Але це дуже багато роботи.
Цитата: Andrey Lukyanov от марта 28, 2023, 09:34EGA/VGA дозволяє використовувати 512 символів одночасно, але за рахунок використання меншої кількості кольорів (8 замість 16).
Більш ніж 20 років тому я ще планував зробити цю фічу, після важливіших за неї змін: використання XMS, довги строки (рядки?). Але руки не дійшли навіть до цього: строка залишилася ≤ 254, доступна пам'ять ≈ 500 КБ...
Цитата: Python от марта 28, 2023, 00:06Якщо ж ми хочемо працювати з текстовою відеопам'яттю, то схоже, що ні, але можна забезпечити підтримку підмножини юнікоду за допомогою саморобної кодової сторінки. Тобто, можна зробити текстовий редактор для файлів в UTF-8, що містять латиницю, кирилицю й іврит одночасно, який працюватиме під чистим MS-DOS у текстовому режимі, конвертуючи utf-8 у коди цієї сторінки. Якщо треба щось за межами цієї підмножини (напр., глаголиця, руни чи просто символ, що не потрапив до нашої кодової сторінки), то такий редактор відобразити це не зможе, звичайно.
В епоху DOS я перемикав кодові сторінки a.k.a. шрифти двома кликами :)
Але у вікні це неможливо, там завжди використовується вибраний шрифт.
Тому я додав вишезгаданий remapper.
Цитата: Python от марта 28, 2023, 01:16Якщо вісімка чи щось старіше, то додатково встановлювати емулятор для ДОС ще непотрібно, наскільки я розумію.
Ні, це не залежить від версії Windows. Я запускаю Multi-Edit у Windows XP, у Windows 7 32 бiт, у Windows 10 32 бiт (зараз я маю все це в віртуальних машинах). Але не можу запустити її у 64-бiтних системах.
Цитата: Andrey Lukyanov от марта 28, 2023, 21:40DOS-програма також може використовувати Юнікод. Але всі перекодування вона повинна робити сама.
Це як? :o
(Ми говорили про відображення, не про файли, там зрозуміло що можна).
Цитата: Andrey Lukyanov от марта 28, 2023, 11:19Начебто на символ.
Так.
Третій (=старший) біт кольору фону можна використати як blink, третій біт кольору символу можна використати як поширення символьного байту.
Цитата: mnashe от марта 28, 2023, 21:52Ні, це не залежить від версії Windows. Я запускаю Multi-Edit у Windows XP, у Windows 7 32 бiт, у Windows 10 32 бiт (зараз я маю все це в віртуальних машинах). Але не можу запустити її у 64-бiтних системах.
Можна цю программу перекомпілювати на 32/64 біти?
Цитата: mnashe от марта 28, 2023, 21:52Поправляйте, пожалуйста, мои ошибки, если заметите
Цитата: mnashe от марта 28, 2023, 21:52довги строки (рядки?)
Так,
довгі рядки. Слова «строка» нема (є слово «строк» чоловічого роду, еквівалентне рос. «срок»). Дехто з україномовної колокомп'ютерної спільноти пропонує використовувати слово «стрічка» (причому, пропонується вживати лише в значенні string, а line перекладати як «рядок»), але, ІМНО, це неправильно — в українській літературі випадки використання слова «стрічка» в значенні «рядок тексту» надто рідкісні, і в ХХ ст. це не практикувалось; основне ж значення слова «стрічка» відповідає рос. «лента» (напр., «стрічка новин»).
Цитата: mnashe от марта 28, 2023, 21:52двома кликами
двома
клікамиЦитата: mnashe от марта 28, 2023, 22:05третій біт кольору символу можна використати як поширення символьного байту.
Краще
розширення,
продовження чи
доповнення. «Поширення» сприймається як синонім «розповсюдження».
Дякую, Пѵѳоне!
Здається, я зустрічав слово «стрічка», але не «строка».
А, «поширення» використовується як переклад Share, так?
Ага, розширення = расширение, це точно що я хотів сказати, але не пам'ятав, чи воно є в українській.
Цитата: Eitanbor от марта 28, 2023, 23:51Можна цю программу перекомпілювати на 32/64 біти?
Ні, лише переписати з нуля 100% кода.
x86 real mode фактически можно считать отдельной архитектурой, в сравнении с x86 protected mode и тем более с режимом 64 бит. Так что портирование DOS-программ на Windows — того же уровня задача, что и портирование на Android, и даже, наверно, сложнее, чем портирование с Windows на Android, хотя в последнем случае совсем другая система команд, а тут 90% команд совпадают, но полное различие схемы памяти и принципов работы с лихвой перекрывает общность команд.
Даже если бы программа была написана на языке высокого уровня, это была бы огромная работа, а тем более когда всё ядро написано на ассемблере.
(Изначальная версия американского Multi-Edit'а, на которой я основывался, написана на Turbo Pascal, но я её полностью дизассемблировал и переделал; от первоначального кода сохранилось порядка 20%, и то оптимизированного мной, и от нынешней версии этот код составляет порядка 5–7%).
Цитата: mnashe от марта 29, 2023, 09:54оптимизированного мной
Все беды — от излишней оптимизации.
Цитата: mnashe от марта 29, 2023, 09:54x86 real mode фактически можно считать отдельной архитектурой, в сравнении с x86 protected mode и тем более с режимом 64 бит. Так что портирование DOS-программ на Windows — того же уровня задача, что и портирование на Android, и даже, наверно, сложнее, чем портирование с Windows на Android, хотя в последнем случае совсем другая система команд, а тут 90% команд совпадают, но полное различие схемы памяти и принципов работы с лихвой перекрывает общность команд.
Даже если бы программа была написана на языке высокого уровня, это была бы огромная работа, а тем более когда всё ядро написано на ассемблере.
Можно использовать программу-конвертер; а также писать на Kotlin
Цитата: mnashe от марта 29, 2023, 09:54(Изначальная версия американского Multi-Edit'а, на которой я основывался, написана на Turbo Pascal, но я её полностью дизассемблировал и переделал; от первоначального кода сохранилось порядка 20%, и то оптимизированного мной, и от нынешней версии этот код составляет порядка 5–7%).
Это вообще-то законно? Они разрешают?
Цитата: Andrey Lukyanov от марта 29, 2023, 10:24Все беды — от излишней оптимизации.
Не, до оптимизации это с трудом читалось из-за обилия мусора.
И сейчас то, что оптимизировано меньше всего (функция поиска с регулярными выражениями), едва читается.
Цитата: Eitanbor от марта 29, 2023, 12:28Это вообще-то законно? Они разрешают?
Сомневаюсь. Но я их не спрашивал. И программу не продавал, для себя делал.
(Правда, продавал свою программу, опирающуюся на мою переделку, но тоже в довольно узком кругу: в школах одной религиозной сети).
А, ну так это ж всё равно с нуля, какая разница, на чём.
Цитата: mnashe от марта 29, 2023, 12:41Цитироватьа также писать на Kotlin
Що це таке?
Це мова програмування. Можна писати на JVM, на Native, на JS, здається, на ще щось
Проблема же вообще не в языке, язык можно взять любой. Проблема в несовместимой аппаратной платформе. При этом программа написана без малейшей оглядки на совместимость, она полностью привязана к x86 платформе. Без DOS-прерываний там обойтись ещё можно (они не так много используются, только для работы с файлами, что легко переделать), а вот все команды, работающие с памятью, надо менять. То есть 100% программы.
Цитата: mnashe от марта 29, 2023, 13:17а вот все команды, работающие с памятью, надо менять. То есть 100% программы.
На C також потрібно переписувати сам код? Він же потім компілюється
Цитата: Eitanbor от марта 29, 2023, 13:47На C також потрібно переписувати сам код? Він же потім компілюється
На C в принципе можно писать так, чтобы минимизировать необходимые изменения при переходе на другую платформу (хотя не всегда это получается; или получается лишь ценой серьёзного снижения скорости или функциональности). В C сопряжение с операционной системой и аппаратурой берёт на себя среда.
А на ассемблере это априори невозможно.
Цитата: mnashe от марта 30, 2023, 09:52Цитата: Eitanbor от марта 29, 2023, 13:47На C також потрібно переписувати сам код? Він же потім компілюється
На C в принципе можно писать так, чтобы минимизировать необходимые изменения при переходе на другую платформу (хотя не всегда это получается; или получается лишь ценой серьёзного снижения скорости или функциональности). В C сопряжение с операционной системой и аппаратурой берёт на себя среда.
А на ассемблере это априори невозможно.
Интересно, на Kotlin'е можно откомпилировать код на MS-DOS?
Цитата: DarkMax2 от марта 28, 2023, 11:55Як програміст, мушу зазначити, що ASCII дуже зручна і подекуди незамінна. Звісно, якщо ти працюєш із простими текстами, простими повідомленнями, які не вимагають нестандартних символів.
Не можу бажати зникнення цьому кодуванню.
Ну, насправді в один час з ASCII було поширене ще кодування EBCDIC, несумісне з ним. Але це, мабуть, треба або відродити старовинне мистецтво перфокартного вводу, або щоб почалося повстання мейнфреймів — так склалось, що варіанти EBCDIC закріпились у цих нішах, тоді як ПК захопили варіанти ASCII.
До речі, в радянській адаптації EBCDIC — ДКОІ (точніше, ДКОІ-2; не плутати з ASCII-подібними КОІ7 та КОІ8) застосували підхід, дещо схожий на той, що я пропонував вище: окремі коди відводились лише для тих кириличних літер, що графічно відрізнялись від латинських. Очевидно, не для економії місця — в ДКОІ-1 його вистачало для повної російської кирилиці, а в ДКОІ-2 на місці викинутих букв лишились порожні клітинки — таке урізання мало сенс для спрощення пристроїв вводу/виводу та для уникнення помилок вводу (що особливо актуально, якщо програміст не сам інтерактивно працює з компом, а приносить рукопис програми перфораторниці і отримує лістинг роботи програми через кілька днів). Ну а потім усі перейшли на персональні комп'ютери з зоопарком ASCII-подібних кириличних кодувань, несумісних між собою в кириличній частині.
Разом з тим, EBCDIC-сумісні кодові сторінки (такі, як CP500 чи кирилична CP20880) доступні на Windows — при бажанні, можна в командному рядку перемкнутись на таку кодову сторінку, запускати батники в цих кодуваннях, і т.д. До речі, граючись із кодуваннями, з'ясував для себе загадку ДОСівського кінця рядка ("\r\n" — два байти з кодами 13 та 10, хоча було б достатньо й самого "\n"). Справа в тому, що ось цей зайвий "\r" (який, взагалі-то, призначений, щоб переводити курсор на початок поточного рядка) однаково кодується і в ASCII, і в EBCDIC. Тоді як символ переходу на новий рядок має різні коди в цих кодуваннях (точніше, в межах самого EBCDIC існує різнобій між двома варіантами позначення — код 21 чи 37 — і жоден з них не збігається з кодом в ASCII). Виходить, дописуючи байт з кодом 13, який скрізь інтерпретується однаково, можна маркувати кінець рядка у спосіб, сумісний з усіма системами. Зрозуміло, кодування практично всіх символів при цьому лишається несумісним між ASCII та EBCDIC, але, принаймні, в цій каші байтів можна відшукати кінці рядків. Враховуючи, що IBM — це не тільки ПК, а й мейнфрейми, збереження такої часткової сумісності могло мати сенс...
Якщо говорити про кириличні варіанти EBCDIC, усі вони (ДКОІ-1 та 2, cp880, cp20880) загалом схожі між собою. Принцип побудови аналогічний прийнятому в КОІ: кириличні букви йдуть у таблиці кодів паралельними рядами до латинських літер, фонетично подібних до них (abcd перетворюється на абцд простою зміною певних бітів), решта, що не вмістились у цей набір з 26 літер, розкидані навколо по всіх вільних місцях. Якщо в ДКОІ-2 була урізана російська кирилиця, то в 880 відновили її до стану ДКОІ-1 і доповнили літерами решти кирилиць — тобто, всі літери з windows-1251 є і в цьому кодуванні, хоч і в іншому порядку.
Цитата: Python от апреля 8, 2023, 12:33тобто, всі літери з windows-1251 є і в цьому кодуванні, хоч і в іншому порядку.
Насправді незовсім. В сучасних EBCDIC-кодуваннях з кирилицею (кодові сторінки 880, 1025 чи 20880, 21025 на windows) представлено всі слов'янські кирилиці в тому стані, як вони були в радянську добу — а отже, літеру Ґґ до них не включено. І невикористаного місця, куди її втулити, теж нема.
Active code page: 20880
64- 65- 66-ђ 67-ѓ 68-ё 69-є 70-ѕ 71-і
72-ї 73-ј 74-[ 75-. 76-< 77-( 78-+ 79-!
80-& 81-љ 82-њ 83-ћ 84-ќ 85-ў 86-џ 87-Ъ
88-№ 89-Ђ 90-] 91-$ 92-* 93-) 94-; 95-^
96-- 97-/ 98-Ѓ 99-Ё 100-Є 101-Ѕ 102-І 103-Ї
104-Ј 105-Љ 106-| 107-, 108-% 109-_ 110-> 111-?
112-Њ 113-Ћ 114-Ќ 115-� 116-Ў 117-Џ 118-ю 119-а
120-б 121-` 122-: 123-# 124-@ 125-' 126-= 127-"
128-ц 129-a 130-b 131-c 132-d 133-e 134-f 135-g
136-h 137-i 138-д 139-е 140-ф 141-г 142-х 143-и
144-й 145-j 146-k 147-l 148-m 149-n 150-o 151-p
152-q 153-r 154-к 155-л 156-м 157-н 158-о 159-п
160-я 161-~ 162-s 163-t 164-u 165-v 166-w 167-x
168-y 169-z 170-р 171-с 172-т 173-у 174-ж 175-в
176-ь 177-ы 178-з 179-ш 180-э 181-щ 182-ч 183-ъ
184-Ю 185-А 186-Б 187-Ц 188-Д 189-Е 190-Ф 191-Г
192-{ 193-A 194-B 195-C 196-D 197-E 198-F 199-G
200-H 201-I 202-Х 203-И 204-Й 205-К 206-Л 207-М
208-} 209-J 210-K 211-L 212-M 213-N 214-O 215-P
216-Q 217-R 218-Н 219-О 220-П 221-Я 222-Р 223-С
224-\ 225-¤ 226-S 227-T 228-U 229-V 230-W 231-X
232-Y 233-Z 234-Т 235-У 236-Ж 237-В 238-Ь 239-Ы
240-0 241-1 242-2 243-3 244-4 245-5 246-6 247-7
248-8 249-9 250-З 251-Ш 252-Э 253-Щ 254-Ч 255-�
Active code page: 21025
64- 65- 66-ђ 67-ѓ 68-ё 69-є 70-ѕ 71-і
72-ї 73-ј 74-[ 75-. 76-< 77-( 78-+ 79-!
80-& 81-љ 82-њ 83-ћ 84-ќ 85-ў 86-џ 87-Ъ
88-№ 89-Ђ 90-] 91-$ 92-* 93-) 94-; 95-^
96-- 97-/ 98-Ѓ 99-Ё 100-Є 101-Ѕ 102-І 103-Ї
104-Ј 105-Љ 106-| 107-, 108-% 109-_ 110-> 111-?
112-Њ 113-Ћ 114-Ќ 115-� 116-Ў 117-Џ 118-ю 119-а
120-б 121-` 122-: 123-# 124-@ 125-' 126-= 127-"
128-ц 129-a 130-b 131-c 132-d 133-e 134-f 135-g
136-h 137-i 138-д 139-е 140-ф 141-г 142-х 143-и
144-й 145-j 146-k 147-l 148-m 149-n 150-o 151-p
152-q 153-r 154-к 155-л 156-м 157-н 158-о 159-п
160-я 161-~ 162-s 163-t 164-u 165-v 166-w 167-x
168-y 169-z 170-р 171-с 172-т 173-у 174-ж 175-в
176-ь 177-ы 178-з 179-ш 180-э 181-щ 182-ч 183-ъ
184-Ю 185-А 186-Б 187-Ц 188-Д 189-Е 190-Ф 191-Г
192-{ 193-A 194-B 195-C 196-D 197-E 198-F 199-G
200-H 201-I 202-Х 203-И 204-Й 205-К 206-Л 207-М
208-} 209-J 210-K 211-L 212-M 213-N 214-O 215-P
216-Q 217-R 218-Н 219-О 220-П 221-Я 222-Р 223-С
224-\ 225-§ 226-S 227-T 228-U 229-V 230-W 231-X
232-Y 233-Z 234-Т 235-У 236-Ж 237-В 238-Ь 239-Ы
240-0 241-1 242-2 243-3 244-4 245-5 246-6 247-7
248-8 249-9 250-З 251-Ш 252-Э 253-Щ 254-Ч 255-�
Коди 0...63 та 255 є службовими — туди краще не лізти.
Очевидна ідея, яка напрошується — використати македонську Ѓѓ як сурогат української Ґґ, також це дозволить використати існуючі бібліотеки для перетворень між великими й малими літерами та інших маніпуляцій з текстом. Таким чином, гіпотетична cp880-ukr-1 відрізнятиметься від cp880 заміною Ѓѓ на Ґґ. Але тоді таке кодування стане непридатним для македонської мови, зберігаючи при цьому навіщось решту македонських літер. Шрифтове рішення — спробувати надати Ґ графічної подібності і до Ґ, і до Ѓ — так чи інакше, в одному алфавіті ці дві літери не зустрічаються.
Або ж Ґґ можна розмістити на місці якоїсь із кириличних літер, що графічно дублюються латинськими — македонську Ѕѕ, якщо на її кодовій позиції з'явиться інша літера, все ще можна замінити латинською Ss. Таким чином, cp880-ukr-2 міститиме всі літери сучасних слов'янських кирилиць, крім македонської Ѕѕ, яку слід замінювати графічним двійником.
Нарешті, можна пожертвувати малозатребуваними неалфавітними символами. Такими можуть бути chr(225) (§ чи ¤ в існуючих кодуваннях) та chr(115) — м'який перенос. (Хоча, можливо, останній слід вважати службовим символом, і туди краще теж не лізти? Але ні — західні варіанти EBCDIC відводять йому інший код chr(202), хоча й роблять це однаково між собою. Несумісності у світі кодувань EBCDIC, загалом, є нормою — навіть такі звичні символи, як \`{}@#$~ , а особливо !^[]| , змінюють свої коди від таблиці до таблиці). Позбувшись параграфу/знаку валюти та переносу, cp880-ukr-3 отримує, нарешті, повну сучасну слов'янську кирилицю.
Можливий і інший підхід, простіший, але й більш варварський. Як ми знаємо, кодування KOI8-U та KOI8-RU (але не KOI8-R) містить повний український алфавіт. Також існують готові алгоритми для перетворення між ASCII та EBCDIC (напр., утиліта dd має функцію такого конвертування). Підходи до кодування символів у KOI та ДКОІ схожі між собою — можна взяти текст у KOI8, піддати його перетворенню з ASCII в EBCDIC, і отримати щось схоже на ДКОІ, або навпаки. Як не дивно, це справді працює — навіть краще, ніж я очікував. Таблиця кодів, отримана шляхом перетворення KOI8-RU за допомогою dd, матиме ось такий вигляд:
C:\Users\py\Desktop\try\ebcdic>chcp 21866
Active code page: 21866
14.04.2023 22:17:39,17
C:\Users\py\Desktop\try\ebcdic>ebcdic|dd conv=ascii>con
64- 65-═ 66-║ 67-╒ 68-ё 69-є 70-╔ 71-і
72-ї 73-╗ 74-[ 75-. 76-< 77-( 78-+ 79-!
80-& 81-╘ 82-╙ 83-╚ 84-╛ 85-ґ 86-ў 87-╞
88-╟ 89-╠ 90-] 91-$ 92-* 93-) 94-; 95-^
96-- 97-/ 98-╡ 99-Ё 100-Є 101-╣ 102-І 103-Ї
104-╦ 105-╧ 106-| 107-, 108-% 109-_ 110-> 111-?
112-╨ 113-╩ 114-╪ 115-Ґ 116-Ў 117-© 118-ю 119-а
120-б 121-` 122-: 123-# 124-@ 125-' 126-= 127-"
128-ц 129-a 130-b 131-c 132-d 133-e 134-f 135-g
136-h 137-i 138-д 139-е 140-ф 141-г 142-х 143-и
144-й 145-j 146-k 147-l 148-m 149-n 150-o 151-p
152-q 153-r 154-к 155-л 156-м 157-н 158-о 159-п
160-я 161-~ 162-s 163-t 164-u 165-v 166-w 167-x
168-y 169-z 170-р 171-с 172-т 173-у 174-ж 175-в
176-ь 177-ы 178-з 179-ш 180-э 181-щ 182-ч 183-ъ
184-Ю 185-А 186-Б 187-Ц 188-Д 189-Е 190-Ф 191-Г
192-{ 193-A 194-B 195-C 196-D 197-E 198-F 199-G
200-H 201-I 202-Х 203-И 204-Й 205-К 206-Л 207-М
208-} 209-J 210-K 211-L 212-M 213-N 214-O 215-P
216-Q 217-R 218-Н 219-О 220-П 221-Я 222-Р 223-С
224-\ 225-÷ 226-S 227-T 228-U 229-V 230-W 231-X
232-Y 233-Z 234-Т 235-У 236-Ж 237-В 238-Ь 239-Ы
240-0 241-1 242-2 243-3 244-4 245-5 246-6 247-7
248-8 249-9 250-З 251-Ш 252-Э 253-Щ 254-Ч 255-Ъ
Російсько-українсько-білоруське KOI8-RU, воно ж кодова сторінка 21866, не має південнослов'янських літер — на їх місці псевдографіка та інше графічне сміття, яке нас не цікавить. Символи з базового ASCII опинились після перекодування точно на тих же місцях, що й у 20880 та 21025. Також стали на своє місце всі російські літери і, як не дивно, українські ЄєІіЇї та білоруська велика Ў. Не пощастило білоруській малій ў, яка посунулася з chr(85) на chr(86), звільнивши старе місце для малої ґ (велика Ґ стала на місце м'якого переносу). Зате тепер ми маємо змогу використовувати всі три східнослов'янські мови, користуючись повними алфавітами.
(Поки що мені не вдалося ідентифікувати кодування, на перетворення між якими dd була розрахована початково (імовірно, що це не cp037 чи cp500, які мають інші відповідності кодів деяких символів з базовим ASCII; за розміщенням цих символів, EBCDIC-кодування dd дає збіги з кириличними cp880 та cp1025, югославським латиничним cp870, грецьким cp875 — усе це «національні» варіанти EBCDIC, аналогічного їм кодування з західним набором символів я поки що не виявив, якщо воно існувало взагалі). Але, схоже, цей же алгоритм використовувався при створенні як ранніх, так і пізніх кодувань з родин KOI та ДКОІ.)
З можливих ідей подальшого вдосконалення: південнослов'янська кирилиця в українських умовах не надто затребувана, зате ми маємо досить близькі зв'язки з Польщею — можна поєднати український алфавіт та польський в одному кодуванні, місця для цього ніби вистачає.
Цитата: mnashe от марта 29, 2023, 13:17Проблема же вообще не в языке, язык можно взять любой. Проблема в несовместимой аппаратной платформе. При этом программа написана без малейшей оглядки на совместимость, она полностью привязана к x86 платформе. Без DOS-прерываний там обойтись ещё можно (они не так много используются, только для работы с файлами, что легко переделать), а вот все команды, работающие с памятью, надо менять. То есть 100% программы.
Якщо переносити таку програму на іншу платформу, то, мабуть, потрібна віртуальна модель фізичної машини, для якої програму було створено. Напр., там може бути масив, що імітує текстову відеопам'ять, куди програма може записувати відображуваний текст і звідки періодично він зчитується, щоб перемалюватися на реальному екрані. Щось назразок симулятора, але з акцентом не на реалістичну імітацію старої машини, а на продуктивність, практичну зручність і можливість подальшого розширення функціоналу.
Система машинних команд — наскільки точно вона має бути відтворена? Якщо той же асемблерний код відкомпілювати так, щоб він виконував такі ж дії, але ті ж команди кодувались би іншими послідовностями байтів, то така програма працюватиме, чи вона ще й виконує якісь дії зі своїм машинним кодом як з даними (сама змінює його, або й просто виконує арифметичні дії з адресами інструкцій), і це поламає всю логіку її роботи? У другому випадку, симуляція має бути більш повною, перекомпілювати код для іншої платформи стає проблематично — потрібен інтерпретатор машинного коду.
Втім, не бачу причин, чому такий симулятор не міг би існувати. Існують же платформи назразок Java, цілковито побудовані навколо виконання коду в віртуальній машині. Принципова різниця — віртуальна машина має базуватися на реальній. Але, власне, симулятори це й роблять.
Цитата: Python от апреля 14, 2023, 23:02З можливих ідей подальшого вдосконалення: південнослов'янська кирилиця в українських умовах не надто затребувана, зате ми маємо досить близькі зв'язки з Польщею — можна поєднати український алфавіт та польський в одному кодуванні, місця для цього ніби вистачає.
Ще ідея: знаки валют. Насьогодні для українців актуальними можуть бути гривня, долар, євро, а також біткоїн — знаки всіх цих валют включено в сучасні стандарти юнікоду. Якщо програма на мейнфреймі займається якимись економічними розрахунками, позначення грошей можуть знайти практичне застосування. (Чим насправді займаються мейнфрейми?..)
Р.Ѕ. Хотів був вставити для демонстрації знак біткоїна, але несподівано виявив, що тут він відображається як знак рубля. ₿ — ви теж бачите рубль замість того, що треба, чи це мій локальний глюк?
P.P.S. Схоже, що глюк локальний. Якщо в вас така ж проблема, пошукайте шрифт, який підставляється й робить таке неподобство (в моєму випадку — PT Serif, де невикористане місце в області знаків валют забили рублями).
Цитата: Python от апреля 15, 2023, 03:57Р.Ѕ. Хотів був вставити для демонстрації знак біткоїна, але несподівано виявив, що тут він відображається як знак рубля. ₿ — ви теж бачите рубль замість того, що треба, чи це мій локальний глюк?
Я бачу символ Біткойну
Цитата: Python от апреля 15, 2023, 03:57PT Serif, де невикористане місце в області знаків валют забили рублями
Занадто багато поваги до ₒккупантсько-нацистсько-фашистсько-ᵢмперсько-ₚашистської валюти
Цитата: Python от апреля 15, 2023, 03:29Якщо переносити таку програму на іншу платформу, то, мабуть, потрібна віртуальна модель фізичної машини, для якої програму було створено. Напр., там може бути масив, що імітує текстову відеопам'ять, куди програма може записувати відображуваний текст і звідки періодично він зчитується, щоб перемалюватися на реальному екрані. Щось назразок симулятора, але з акцентом не на реалістичну імітацію старої машини, а на продуктивність, практичну зручність і можливість подальшого розширення функціоналу.
Я довольно много думал в этом направлении. Ещё 15–20 лет назад, и позже время от времени. Видится вполне реалистичным.
После такого переноса можно переписать на программный код новой платформы ядро программы — нынешнюю виртуальную машину, чтобы оно работало быстрее. Остальное не так критично.
Впрочем, она и в самых обычных эмуляторах работает быстро. И на андроиде, и на Windows.
Цитата: Python от апреля 15, 2023, 03:29чи вона ще й виконує якісь дії зі своїм машинним кодом як з даними (сама змінює його, або й просто виконує арифметичні дії з адресами інструкцій)
Есть два таких места, и они изолированы, так что их несложно ликвидировать.
1. В конце инициализации программа проверяет наличие арифметического сопроцессора, если он есть, то ставит указатель начала области данных сразу после библиотеки функций действительных чисел, использующих сопроцессор, а если его нет, то копирует на её место находяющуюся за ней библиотеку, использующую эмуляцию, а затем ставит указатель на конец этой библиотеки (куда попадёт этот конец после переписывания).
2. Программа состоит из трёх файлов: основной com-файл и два оверлея. В одном собственно редактор, в другом файл-менеджер, калькулятор и ввод строки. Все вызовы подпрограмм между основным модулем и первым или вторым оверлеями сделаны как ближние вызовы, и есть специальный модуль-переключатель, который перебрасывает эти ближние вызовы в область, находящуюся в другом сегменте.
При переходе на новую платформу нужно всё это убрать и полностью разделить программную память и память данных. В программной памяти тогда можно не заморачиваться компактностью команд и всю адресацию сделать, например, 20-битной (хватит и 17 бит на основной модуль + оба оверлея, не придётся ничего свопить). Тогда память данных (куча) получит невероятные 750 кБ (от нуля до 0B8000, где начинается экранная память). А если ещё и процедуры, работающие с видеопамятью, переписать (их не так много), то куча + стек вместе получат целый мегабайт.
Есть, правда, несколько скриптов, которые напрямую запускают фрагменты машинного кода. Они, естественно, работать перестанут. Но их совсем мало.
@mnashe, можна спитати, що ця програма робить?
Цитата: Python от апреля 14, 2023, 23:02Очевидна ідея, яка напрошується — використати македонську Ѓѓ як сурогат української Ґґ, також це дозволить використати існуючі бібліотеки для перетворень між великими й малими літерами та інших маніпуляцій з текстом. Таким чином, гіпотетична cp880-ukr-1 відрізнятиметься від cp880 заміною Ѓѓ на Ґґ.
Усі очевидні ідеї реалізовано ще до мене. Кодування cp1123 — це те ж кодування 1025, але з заміною македонської Ѓѓ на українську Ґґ, решту специфічно-македонських літер залишили без змін, хоч вони в такому складі вже повноцінно використовуватись не можуть. Кодової сторінки 1123 в системі windows нема, але серед кодувань, які підтримує Java на моєму комп'ютері, це кодування є.
64- 65- 66-ђ 67-ґ 68-ё 69-є 70-ѕ 71-і
72-ї 73-ј 74-[ 75-. 76-< 77-( 78-+ 79-!
80-& 81-љ 82-њ 83-ћ 84-ќ 85-ў 86-џ 87-Ъ
88-№ 89-Ђ 90-] 91-$ 92-* 93-) 94-; 95-^
96-- 97-/ 98-Ґ 99-Ё 100-Є 101-Ѕ 102-І 103-Ї
104-Ј 105-Љ 106-| 107-, 108-% 109-_ 110-> 111-?
112-Њ 113-Ћ 114-Ќ 115-� 116-Ў 117-Џ 118-ю 119-а
120-б 121-` 122-: 123-# 124-@ 125-' 126-= 127-"
128-ц 129-a 130-b 131-c 132-d 133-e 134-f 135-g
136-h 137-i 138-д 139-е 140-ф 141-г 142-х 143-и
144-й 145-j 146-k 147-l 148-m 149-n 150-o 151-p
152-q 153-r 154-к 155-л 156-м 157-н 158-о 159-п
160-я 161-~ 162-s 163-t 164-u 165-v 166-w 167-x
168-y 169-z 170-р 171-с 172-т 173-у 174-ж 175-в
176-ь 177-ы 178-з 179-ш 180-э 181-щ 182-ч 183-ъ
184-Ю 185-А 186-Б 187-Ц 188-Д 189-Е 190-Ф 191-Г
192-{ 193-A 194-B 195-C 196-D 197-E 198-F 199-G
200-H 201-I 202-Х 203-И 204-Й 205-К 206-Л 207-М
208-} 209-J 210-K 211-L 212-M 213-N 214-O 215-P
216-Q 217-R 218-Н 219-О 220-П 221-Я 222-Р 223-С
224-\ 225-§ 226-S 227-T 228-U 229-V 230-W 231-X
232-Y 233-Z 234-Т 235-У 236-Ж 237-В 238-Ь 239-Ы
240-0 241-1 242-2 243-3 244-4 245-5 246-6 247-7
248-8 249-9 250-З 251-Ш 252-Э 253-Щ 254-Ч 255-�
Цитата: Eitanbor от апреля 16, 2023, 12:42Занадто багато поваги до ₒккупантсько-нацистсько-фашистсько-ᵢмперсько-ₚашистської валюти
Заради об'єктивності, на момент виходу шрифту, окупантами по відношенню до нашої країни вони ще не встигли стати. Тому проблема могла б лишатись непомітною деякий час — аж поки не вирішиш придбати трохи біткоїнів, а отримаєш натомість ту ж суму, але рублів :)
Цитата: Eitanbor от апреля 16, 2023, 18:49@mnashe, можна спитати, що ця програма робить?
Текстовый редактор + файл-менеджер (по типу Norton Commander, но гораздо более навороченный) с мощным скриптовым языком.
emacs не пробовали юзать?
Цитата: mnashe от апреля 18, 2023, 12:38Цитата: Eitanbor от апреля 16, 2023, 18:49@mnashe, можна спитати, що ця програма робить?
Текстовый редактор + файл-менеджер (по типу Norton Commander, но гораздо более навороченный) с мощным скриптовым языком.
Можна, будь ласка, посилання на скачування?
Цитата: Andrey Lukyanov от апреля 18, 2023, 13:22emacs не пробовали юзать?
wandrien теж згадував emacs (https://lingvoforum.net/index.php/msg=3819308.html#msg3819308). А я навіть не знаю що це :)
Цитата: Eitanbor от апреля 18, 2023, 18:39Можна, будь ласка, посилання на скачування?
Я вижу, что ссылка на attachment в старой теме не работает — то ли attachment ушёл в другой каталог, то ли пропал (была какая-то проблема при переносе форума).
Так что надо его куда-нибудь залить (в архиве меньше мегабайта)... :-\
Цитата: mnashe от апреля 19, 2023, 08:06wandrien теж згадував emacs (https://lingvoforum.net/index.php/msg=3819308.html#msg3819308). А я навіть не знаю що це :)
Текстовий редактор з можливістю розширювати функціонал, для написання плагінів використовується діалект LISP'у. Колись трохи пробував ознайомитися з ним — справляє враження чогось монструозного й архаїчного, але, здається, все, що тільки можна, в емаксі є. Хоча зараз використовую jEdit — редактор, чимось до нього подібний, зі схожими ідеями в своїй основі, але більш сучасний, і для плагінів та скриптів у ньому використовується простіший для розуміння beanshell (інтерпретована мова на основі Java).
Ще на тему урізаної кирилиці в кодуваннях. Надибав ось таке дивне еплівське кодування (здається, з 80-х чи 90-х):
(https://www.kreativekorp.com/miscpages/sabine/sabine10.png) (https://www.kreativekorp.com/miscpages/sabine/)
Кодування 10-бітне (тобто, 1024-символьне), що вже рідкість. В ньому є надмірності, назразок дублювання літер кількома почерками, багато псевдографіки; з нелатинських алфавітів є грецький та кирилиця — причому, букви, що мають двійників в іншому алфавіті, не повторюються. Так, грецька велика альфа та кирилична А передаються латинською A, кирилична велика Г — грецькою великою гаммою, і т.д. (Незовсім зрозуміло, як передавати малу кириличну г — схоже, про неї забули, або ж розробники вирішили, що латинська r чи грецька γ достатньо на неї схожа).
Я тут розмірковую над задачею, яким має бути кодування, сумісне з 8-бітною кирилицею, але при цьому придатне для передачі юнікоду в повному складі. Щось назразок UTF-8, але на основі не базового ASCII, а, наприклад, КОІ-8. Тобто, текст, набраний кирилицею чи латиницею в існуючому кодуванні, так само читатиметься і в кодуванні з юнікодівським доповненням, українські й англійські букви кодуватимуться кожна одним байтом, але також стане доступною й решта юнікоду (від додаткової пунктуції до емодзі — будь-що), символи звідки кодуватимуться двома чи більше байтами. Таке кодування зберігатиме сумісність з КОІ8-U/-RU/-R, але не матиме такої сумісності з UTF-8, хоча й охоплюватиме ту ж повну множину символів.
Чому саме КОІ, а не більш поширені в наш час windows-1251 та cp866?
По-перше, КОІ — чи не найстаріше кириличне кодування, що в якійсь формі продовжує функціонувати й дотепер — воно старе майже як ASCII, піратським клоном якого воно і було початково.
По-друге, відносно проста схема перетворення між великими й малими літерами кирилиці: в первинному блоці кирилиці (куди входять 32 літери короткого російського алфавіту) вона майже збігається з перетворенням літер латиниці; картину дещо псує вторинний блок кирилиці у KOI8-R, -U та ін. — маю на увазі область, де розміщено Ёё Єє Іі Її Ґґ Ўў — проте, і в межах цього блоку перетворення між великими й малими здійснюється однаковим способом, теж зміною одного біту (хоча й не того ж, що в первинному блоці). Для порівняння, перетворення між великими й малими літерами кирилиці в cp866 (DOSівській крилиці) здійнюється трьома способами (дещо менш зручно, але прийнятно), а от у віндовсівській кирилиці (cp1251) кирилицю за межами первинного блоку розміщено цілком хаотично.
По-третє, придатність такої кирилиці для написання українських текстів (якби я був росіянином чи сербом, пріоритетом для мене була б відповідна мова): KOI8-U та -RU (але не -R) містять повний український алфавіт (cp1251 теж це має, а от cp866 — ні; варіанти ДОС-кодування з повною українською кирилицею існують, але з windows не постачаються, в браузерах здебільшого не підтримуються й мало де використовуються).
З точки зору технічної доступності, всі три кодування достатньо добре представлені в сучасних системах. Зокрема, в командному рядку windows можна використовувати KOI8-U чи -RU (кодова сторінка 21866), поряд із більш звичними 866 та 1251. У свій час KOI8 широко використовувалось у юнікс-подібних системах — зокрема, на поштових серверах, тому це кодування в своїх листах могли використовувати й користувачі windows.
Також перевагою є велика область невикористовуваних кодів — у наш час символи малювання рамок рідко використовуються, тому можна сміливо розміщувати на їх місці байти для кодування юнікоду. З цієї точки зору, KOI8-U та ДОС-кирилиця достатньо зручні, а от 1251 містить там пунктуацію, присутню і в українських текстах.
Недоліком КОІ можна вважати порядок літер «АБЦД» замість звичного «АБВГ». Утім, насправді майже всі кириличні алфавіти потребують додаткового перекодування літер для алфавітного впорядкування — впорядкований кириличний блок у cp1251, cp866 та юнікоді охоплює лише короткий російський алфавіт (без Ё), а також болгарський, що в нього входить — решту літер порозкидали. КОІ лише робить цю проблему більш помітною. Проте, колись можливість читати кирилицю як латиницю, скинувши старший біт, розглядалась як перевага. До речі, в юнікодівському КОІ літери інших алфавітів можна кодувати за схожою схемою — додаючи перед літерою кирилиці префікс алфавіту. Тоді прядок «АБЦД» набуде додаткового сенсу, а тексти на таких алфавітах прочитуватимуться в однобайтному КОІ (це виглядатиме як кириличні букви, між якими вставлено псевдографіку).
Скоріш, проблемою є дещо хаотичний вторинний блок кирилиці в KOI8-U/-RU. Розміщуючи літери в області псевдографіки, розробники, схоже, намагались пожертвувати менш корисними з символів малювання рамок, тому замість двох рівних рядів літер маємо щось рване й ламане. Це впливатиме й на розміщення керуючих кодів у вільній області, яка також стає нерівною — потрібен дещо складніший алгоритм перетворення байтів у юнікодівські символи.
Узагалі, проблема KOI8-RU — невідповідна назва, що плутається з KOI8-R (можливості якого більш обмежені), завдяки чому розробники ПЗ здебільшого роблять підтримку лише KOI8-U (укр.+рос.) та KOI8-R (лише рос.), тоді як українсько-російсько-білоруське KOI8-RU здебільшого лишається поза увагою. Якби назву для KOI8-RU вигадував я, воно б називалось KOI8-URB — без поєднань літер, що ковтають правильні асоціації. Аналогічну проблему має, наприклад, RUSCII, назва якого з Україною взагалі не асоціюється (вгадайте, в якій країні це кодування є державним стандартом для ДОС? Так, у ньому є всі літери російського (R) й українського (U) алфавіту, але...). Поганий маркетинг — запорука провалу. Втім, у windows таки розмістили koi8-ru в кодовій сторінці 21866 (в більш ранніх версіях там було koi8-u, що відрізняється від нього відсутністю Ўў).
У своєму UNIKOI я вирішив охопити всі три східнослов'янські кирилиці, тому за основу візьму koi8-ru.
Цитата: Python от апреля 24, 2023, 21:10дещо хаотичний вторинний блок кирилиці в KOI8-U/-RU. Розміщуючи літери в області псевдографіки, розробники, схоже, намагались пожертвувати менш корисними з символів малювання рамок, тому замість двох рівних рядів літер маємо щось рване й ламане.
В принципі, можна виправити це, розмістивши Ўў Ґґ в одному ряді з рештою пізно доданих літер. Замість сучасного порядку:
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-©
зробити так:
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-©
Наслідком такої перестановки буде втрата сумісності з існуючими білоруськими текстами в КОІ, а також з українськими, що містять Ґґ. Проте, вільну область (псевдографіку, яку буде замінено кодами для юнікоду) тепер простіше відокремити від літер.
Або ж можна зробити більш радикально, відмовившись від підтримки решти мов, крім української. До 1990 український алфавіт мав 32 літери — це досить зручно, бо це степінь двійки і це та ж кількість літер, що і в російському короткому алфавіті без Ё. Можна дерусифікувати КОІ, замінивши кілька російських літер українськими. Сучасний алфавіт має 33 літери, тому доведеться якоюсь пожертвувати — це могла б бути Ґ, але доцільніше викинути кириличну І, використовуючи замість неї латинську. Таким чином, замінивши Ээ на Єє, Ыы на Її, Ъъ на Ґґ, отримуємо версію КОІ для спілкування виключно українською мовою:
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-Ґ
Область від 128 до 191 тепер вільна — можна задіяти її всю для багатобайтних юнікодівських кодів, не маневруючи між літерами (додаткові літери кирилиці, якщо ви все ще користуєтесь іншими мовами, можна брати з юнікоду). На жаль, сумісність такого кодування з KOI8-U при цьому втрачається (українські літери в ньому мають інші коди).
Тепер про власне кодування юнікоду. Область таблиці кодування, яку я збираюсь заповнити кодуючими байтами, містить 52 коди, що досить мало. В принципі, можна використати схему, аналогічну UTF, але вона надто марнотратна й надто переускладнена. Тому бачу сенс зробити трохи інакше.
Розділімо кодуючі байти на 2 категорії: байти початку/продовження (П) та байти кінця (К). Послідовність кодуючих байтів складається з одного чи кількох байтів П й рівно одного байту К. Є 32 різні байти П та 20 різних байтів К. Відповідно, кожному з них присвоюється числове значення — від 0 до 31 для П, від 0 до 19 для К. Грубо кажучи, це 32-кові цифри, якими записується код юнікодівського символа. Молодший розряд іде першим (тобто, порядок запису «цифр» протилежний звичному) — це спрощує обчислення, оскільки байт кінця має лише 20 значень, і обробка його як 20-кової цифри вимагала б під час кодування робити ділення та множення замість більш економних двійкових зсувів.
Число, отримане з послідовності кодуючих байтів, не є безпосередньо кодом юнікодівського числа. Щоб отримати юнікодівський код, до отриманого числа додається основа, яка залежить від кількості байтів у коді: для 2-байтних кодів — 128, для 3-байтних — 128+640, для 4-байтних — 128+640+20480 і т.д. Це треба для того, щоб коди різної довжини з однаковим числовим значенням не дублювали один одного, тому для кожної довжини кодуючої послідовності береться окремий діапазон юнікодівських кодів.
Отриманий юнікодівський код теж є незовсім юнікодівським — це т.зв. трансльований юнікод. У більшості випадків він не відрізняється від коду символа в юнікоді, але в частині випадків коди символів переставлено між собою. Для чого це потрібно: запропонована схема кодування дозволяє кодувати двома байтами лише 640 можливих юнікодівських символів, і було б доцільно розмістити в цьому діапазоні ті з них, які справді часто використовуватимуться, а щось більш екзотичне, назразок історичних латиниць, перенести в більш віддалені області. Саме для такої оптимізації робиться трансляція кодів, після якої отриманий код вже можна використовувати як юнікодівський.
Верхня частина таблиці кодів для 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, прекрасно читается (вместо заглавных букв выходит ивритица).
(https://images.lingvoforum.net/images/2023/03/27/862R.png)
Заглавные буквы распихал где попало, пришлось даже область символов управления (00-1F) задействовать. Но я встроил в редактор специальный механизм, позволяющий отображать текст, набранный в CP-866 (или любой другой — карта настраивается) в шрифте, сделанном в этой моей модифицированной кодовой странице на базе CP-862.
Для украинских букв места не хватило, но если отказаться от размещения строчных букв на своих местах, то освободятся ещё 7 позиций, так что влезут все три буквы (×2).
Що собою являє формат кодової сторінки в даному випадку? Це щось назразок растрового шрифту? Чи існують якісь редактори або конвертери для таких шрифтів?
Нещодавно дізнався, що FreeDOS має декілька українських кириличних кодових сторінок, яких більш нема ніде. Але, схоже, ці сторінки ніде не описано — єдиним джерелом інформації про їх вміст є самі .cpx-файли (які є стиснутим .cpi), і незовсім зрозуміло, як їх проглянути, не встановлюючи FreeDOS.
У свій час я зробив ковертер для створення кодових сторінок у форматі .nls з кодувань, підтримуваних Джавою. Але цей формат містить інформацію лише про юнікодівські коди символів кодової сторінки і не містить шрифтових даних (кодова сторінка типу ANSI, для використання якої потрібні векторні шрифти, повноекранний текстовий режим не підтримується).
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Що собою являє формат кодової сторінки в даному випадку? Це щось назразок растрового шрифту? Чи існують якісь редактори або конвертери для таких шрифтів?
Звичайно. Я колись користувався evafont, він ішов разом із KeyRus-ом.
http://old-dos.ru/index.php?page=files&mode=files&do=show&id=3404
Цікава річ. (Скачав з іншого джерела (https://softclipper.net/utility-i-soputstvuyuschie-programmy/keyrus-v7-3-rezidentnyj-drajver-displeya-i-klaviatury-dlya-dos-programm.html), бо на це не пускав провайдер, але все одно дякую).
Схоже, шрифти з різних систем несумісні між собою. EVAFONT може редагувати шрифти з цього архіву, але тільки їх. На windows вони не ставляться. FontForge підтримує якісь точкові шрифти .fnt, але не ці. FreeDOS надає кодові сторінки зі шрифтовою інформацією у форматі .cpx, але для evafont i fontforge цей формат неїстівний.
В принципі, .cpx можна конвертувати (https://raw.githubusercontent.com/upx/upx/devel/doc/upx-doc.txt) в нестиснутий .cpi, але чим його потім відкрити? Поки що знайшов тільки опис цього формату (https://www.seasip.info/DOS/CPI/cpi.html) (без деталей про шрифтові дані в ньому). А ще гуглиться сторінка (https://freedos-user.narkive.com/poVAunhz/cpi-editor-1-2b) з битим посиланням на редактор шрифтів .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 можна конвертувати (https://raw.githubusercontent.com/upx/upx/devel/doc/upx-doc.txt) в нестиснутий .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:42import 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 (https://en.wikipedia.org/wiki/Utf-8#Codepage_layout) бувають двох типів: початкові байти (в межах 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-кирилицю, що лягла в основу юнікодівського кириличного блоку: великі літери опинились між двома діапазонами, але малі російські й неросійські кириличні літери повністю розмістились у діапазоні байтів початку (що цікаво, але нікуди не веде).
Нарешті, нині малопоширене болгарське кириличне кодування (http://czyborra.com/charsets/cyrillic.html#MIK) (кодова сторінка 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 в консолі за допомогою шрифту Брайля.
(https://i.ibb.co/cyQGNtJ/18-05-2023-02-02-08.png) (https://ibb.co/wd49KCy)
Сам модифікований шрифт зі збільшеними точками у брайлівських символах я зробив колись раніше для гри «Життя», хоча існують і інші шрифти, придатні для такого використання. Брайлівські символи являють собою прямокутні матриці з 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 :)
Цитата: Upliner от мая 21, 2023, 20:29Цитата: Andrey Lukyanov от мая 21, 2023, 09:58Видеокарты S3 в своё время поддерживали «большие» текстовые видеорежимы, вплоть до 160×60 символов. На линуксовой консоли можно было таким баловаться.
Це точно нативний текстовий режим, а не емуляція через fbdev? Так-то я в fbdev-консолі й фільми дивився без жодних X11
Был настоящий текстовый режим.
В теории текстовый режим можно было и дальше развивать — не только в сторону увеличения ширины и высоты экрана в символах, но и, например, введением шрифтов произвольной ширины и высоты. А если на символ в буфере отводить не 2 байта, а 4, то можно было бы и символьный набор расширить, и количество цветов увеличить, и дополнительные атрибуты поддерживать (подчёркивание, надчёркивание...).
На практике все просто перешли на графический режим как более универсальный.
Так, щось починаю пригадувати. Здається, колись навіть пробував перепрограммовувати регістри Horizontal total та End Horizontal Display. Але при перевищенні роздільности 720х480 монітор починав шипіти й до 800 його вже не вдавалось "розігнати". Але теоретично можна довести до 250 (2250px) симовлів у ширину.
http://www.osdever.net/FreeVGA/vga/crtcreg.htm
Але от якраз на "пентіумах" і на S3 Virge я не проводив таких експриментів. Метою було з'ясувати саме можливості звичайного VGA адаптера на 386-м комп'ютері.
Ага, я тоже экспериментировал с перепрограммированием регистров, исследуя пределы.
Правда, так и монитор можно спалить. Мой 14″ Phillips сгорел именно от неподходящего режима, правда, послал ему его не я, а Windows.
Цитата: mnashe от мая 22, 2023, 15:07Ага, я тоже экспериментировал с перепрограммированием регистров, исследуя пределы.
Правда, так и монитор можно спалить. Мой 14″ Phillips сгорел именно от неподходящего режима, правда, послал ему его не я, а Windows.
Эх, классно что сегодня не надо программировать регистры!
Тоді програмістам доводилось посилати коди в регістри, щоб залізо згоріло.
Тепер у програмістів забрали прямий доступ до регістрів, і їм доводиться роздувати програмне забезпечення, щоб залізо застаріло.
Цитата: Python от мая 23, 2023, 22:53Тепер у програмістів забрали прямий доступ до регістрів
Коли в них це забрали? Коли з'явився Windows?
Цитата: Eitanbor от мая 24, 2023, 08:10Коли в них це забрали? Коли з'явився Windows?
Коли поховали Win 9х і повністю перейшли на Windows NT.
Цитата: Upliner от мая 24, 2023, 09:17Цитата: Eitanbor от мая 24, 2023, 08:10Коли в них це забрали? Коли з'явився Windows?
Коли поховали Win 9х і повністю перейшли на Windows NT.
Но под администратором-то всё равно можно писать в регистры?
Цитата: Andrey Lukyanov от мая 24, 2023, 09:26Но под администратором-то всё равно можно писать в регистры?
У теорії так, але треба продиратися нетрями WDK і невідомо як воно буде взаємодіяти з іншими драйверами. Тож у кожному разі зручніше таке робити або у FreeDOS, або в Linux без X11, взявши за основу svgalib.
Цитата: Eitanbor от мая 23, 2023, 13:05Эх, классно что сегодня не надо программировать регистры!
Теперь я полюбил микроконтроллеры: там и сегодня надо программировать регистры!
А вот то, что настройки BIOS устанавливаются в меню, а не перемычками, — очень здорово.
Цитата: mnashe от мая 24, 2023, 12:39А вот то, что настройки BIOS устанавливаются в меню, а не перемычками, — очень здорово.
Не кошер. Еще и plug&pray придумали.
«Встав і молись»? Звучить як план на початок дня віруючої людини, але там інший омонім.
В іншому фонетичному варіанті, «устав і молись», додається третій омонім, а ще виникає російсько-український фальшивий друг.
Цитата: Upliner от мая 24, 2023, 10:17Цитата: Andrey Lukyanov от мая 24, 2023, 09:26Но под администратором-то всё равно можно писать в регистры?
У теорії так, але треба продиратися нетрями WDK і невідомо як воно буде взаємодіяти з іншими драйверами. Тож у кожному разі зручніше таке робити або у FreeDOS, або в Linux без X11, взявши за основу svgalib.
Интересно: на Java'е тоже можно так делать?
Цитата: Eitanbor от мая 25, 2023, 16:03Интересно: на Java'е тоже можно так делать?
Подивіться що там з JNode. В інших операціонках навряд чи.
UPD: Щось таки є
https://github.com/jnode/jnode/blob/master/gui/src/driver/org/jnode/driver/video/vga/VGABitmapGraphics.java
Цитата: Upliner от мая 25, 2023, 16:12В інших операціонках навряд чи.
Чому ж, якщо це Java з використанням нативного коду, то такий Java-проект може робити все, що може робити нативний код. Зрозуміло, це вже не чиста Java, а поєднання її, наприклад, з C++.
Ну тут і справді теба уточнити, що саме має на увазі Eitanbor. І треба зазначити, що потрібен не просто нативний код, а код модуля ядра; а запхати JVM у ядро операціонки -- задача далеко нетривіальна, мало де крім JNode це реалізовано на практиці. А якщо "ядерна" частка проекту буде чисто на C/C++ -- чи це справді те, чого хотів Eitanbor?
Все це звісно стусується звичайних ПК, на всіляких вбудованих пристроях та мікроконтроллерах все може бути простіше, і там також може бути вбудований JVM.
Якщо ОС надає свободу дій, як Win9x, то чи потрібна інтеграція в ядро?
Цитата: Python от мая 25, 2023, 21:00Якщо ОС надає свободу дій, як Win9x, то чи потрібна інтеграція в ядро?
Отут уже важко відповісти. Свобода Win9х здебільшого стосується DOS-підсистеми, чи можна було цим скористатися з Java -- не можу відразу сказати.
Добре. А через OpenGL можна?
Цитата: Eitanbor от мая 25, 2023, 23:44Добре. А через OpenGL можна?
Оце скільки завгодно. І Vulkan теж можна.
Цитата: Upliner от мая 25, 2023, 23:53Цитата: Eitanbor от мая 25, 2023, 23:44Добре. А через OpenGL можна?
Оце скільки завгодно. І Vulkan теж можна.
Тоді, виходить, можна з Джави все це робити, за допомогою LWJGL, наприклад
Цитата: Upliner от мая 21, 2023, 20:29На практиці можна змінити палітру після кожного рядка, тобто в одному рядку все ж таки буде обмеження в 16 кольорів.
Шрифти міняти після кожного рядка теж так можна? Якщо так, це дозволило б відобразити стільки різних гліфів одночасно, скільки є місця на екрані.
Можливо, але не пробував...
Глибше розібрався в питанні, як влаштовано UTF-8. Не можу звільнитися від думки: «Коли виздихає UTF-8?».
Ні, кодування влаштовано цікаво — у повній реалізації з «теоретично можливими» варіантами воно просто цікаве як іграшка для програміста. Схоже, що це і сприяло його закріпленню як основного стандарту: програмісти просто загралися в нього, замість того, щоб спробувати розвивати щось більш просте й логічне і менш надлишкове. Біда в тому, що найсмачніша частина UTF-8 — альтернативні «наддовгі» коди — стала джерелом вразливостей, і її вирішили просто заборонити. Те, що залишилось — так, воно ASCII-сумісне й охоплює юнікод — але цю ж задачу можна було б виконати безліччю інших способів, і обраний спосіб не є найоптимальнішим. Зараз це просто монструозне кодування з купою обмежень, яке, проте, вже стало загальним стандартом для всіх — як у свій час стандартом став перфокартний код, що перекодовувався в проміжний EBCDIC (ДКОІ), який потім перекодовувався в ASCII (КОІ), і в той час таке подвійне перекодування при вводі сприймалось як норма.
Цитата: Python от июня 3, 2023, 12:40Те, що залишилось — так, воно ASCII-сумісне й охоплює юнікод — але цю ж задачу можна було б виконати безліччю інших способів, і обраний спосіб не є найоптимальнішим.
Досі нічого кращого ніхто не запропонував.
Цитата: Andrey Lukyanov от июня 3, 2023, 13:31Цитата: Python от июня 3, 2023, 12:40Те, що залишилось — так, воно ASCII-сумісне й охоплює юнікод — але цю ж задачу можна було б виконати безліччю інших способів, і обраний спосіб не є найоптимальнішим.
Досі нічого кращого ніхто не запропонував.
У цій темі в мене була ідея юнікодівського кодування на основі KOI8-RU, але щось подібне можна було б зробити і на основі чистого ASCII — так навіть простіше, і більше кодів можна задіяти.
Ключові відмінності від UTF-8:
1) Символи кодуються одним чи кількома префіксними байтами і одним кінцевим байтом (принцип, аналогічний сішним рядкам з кінцевим нуль-символом, але кінцевий байт теж є кодуючим — напр., може бути 64 різних префіксних байтів і 64 різних кінцевих байтів, тоді послідовність з n байтів (один з яких кінцевий, всі інші — префіксні) може кодувати 2
6n символів).
2) Коди не дублюються. Коли при читанні обчислюється код n-байтного символа, до нього додається найбільший код (n-1)-байтного символа плюс 1.
Цитата: Python от июня 3, 2023, 13:52У цій темі в мене була ідея юнікодівського кодування на основі KOI8-RU, але щось подібне можна було б зробити і на основі чистого ASCII — так навіть простіше, і більше кодів можна задіяти.
Ключові відмінності від UTF-8:
1) Символи кодуються одним чи кількома префіксними байтами і одним кінцевим байтом (принцип, аналогічний сішним рядкам з кінцевим нуль-символом, але кінцевий байт теж є кодуючим — напр., може бути 64 різних префіксних байтів і 64 різних кінцевих байтів, тоді послідовність з n байтів (один з яких кінцевий, всі інші — префіксні) може кодувати 26n символів).
2) Коди не дублюються. Коли при читанні обчислюється код n-байтного символа, до нього додається найбільший код (n-1)-байтного символа плюс 1.
Можно ещё немного сэкономить, если чистые ASCII-байты также использовать в качестве завершающих (если перед ними не стоит другой завершающий байт).
В принципі, можу погодитися, що задавати довжину першим байтом, а не маркувати кінець останнім байтом, краще з точки зору пошуку — це дає гарантію від співпадінь символа з частиною іншого символа. Хоча варіант з маркуванням кінця може бути економнішим з точки зору кількості байтів на символ: спочатку я пробував втиснути щось схоже на utf у 52 незайняті кодові позиції KOI8-RU — зі збільшенням коду символа, довжина його багатобайтного коду зростала надто швидко, а сам алгоритм вийшов переускладненим — тому прийшов до рішення з 32 кодами префіксних байтів та 20 кінцевих і без дублювання наддовгими кодами.
От дублюючі наддовгі коди, які при цьому ще й не можна використовувати взагалі — навіщо? Виглядає як травма збереження сумісності з чимось, що більше не підтримується (чи, скоріш, ніколи толком і не підтримувалось). Якби наддовгі коди були повністю легальними, то їх би можна було використати, наприклад, для спрощеного перекодування в UTF-8, працюючи з ним як з кодуванням фіксованої довжини — але цього робити не можна. В utf-подібному алгоритмі теж цілком можна було б звільнитись від дублювання (напр., в UTF-8 2-байтні коди кодують діапазон юнікоду від 0 до 211, хоча могли б від 128 до 211+128, діапазон 3-байтних можна було починати не від 0, а від кінця діапазону 2-байтних, і т.д.) — тоді з самого початку не було б дірки з дублюванням, яку потім довелося латати.
У продовження теми UTF8-сумісного кодування з однобайтними кодами для кирилиці:
Цитата: Python от мая 17, 2023, 00:26128-А 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 (https://en.wikipedia.org/wiki/Cp866#Ukrainian_and_Belarusian_variants) (модифікацією 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 от июня 3, 2023, 12:40Не можу звільнитися від думки: «Коли виздихає 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 доведеться пожертвувати або Ё, або І, або Ґ.
Щось подібне можна спробувати зробити і з кодуваннями, основний кириличний блок яких розміщено в області байтів початку 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 (https://en.wikipedia.org/wiki/KOI8-U), KOI8-RU (https://en.wikipedia.org/wiki/KOI8-RU), KOI8-F (https://en.wikipedia.org/wiki/KOI8-F) містить нелітерний символ, тому ще довші наддовгі коди не знадобляться. Зрозуміло, що в KOI8-U таких замін буде менше, а в KOI8-F — більше, бо більше додаткових кириличних літер, комбінацій з якими доведеться уникати.
На жаль, для windows-1251 цей метод не працює: байт 0x80 там кодує літеру Ђ, тому частину кодів принципово неможливо буде замінити наддовгими так, щоб другий байт не був кириличною літерою. Хіба що можна перенести Ђ в іншу кодову позицію чи зробити урізаний варіант цього кодування без сербських літер. Утім, навіть без них додатковий кириличний блок windows-1251 настільки жахливий, що питання «коли виздихає?» супроводжуватиме це кодування завжди.
Гібрид ДОС-кирилиці з UTF-8 можна зробити ще таким чином: кодувати більшість 3-байтних символів як наддовгі 4-байтні (що починаються з 0xF0), а більшість 4-байтних — як 6-байтні послідовності CESU-8 (https://en.wikipedia.org/wiki/CESU-8) (що починаються з 0xED), також деяка частина 3- та 4-байтних кодів, що починаються з цих байтів, але не є ні наддовгими, ні CESU-8, може кодуватись як в UTF-8. У ДОС-кодуваннях ці байти початку відповідають літерам «Ё» та «э» — на їх місці необхідно розмістити нелітерні символи, щоб уникнути злипання однобайтних літер у слові в багатобайтні коди. Тоді велика «Э» та мала́ «ё» залишаться без пари — щоб це виправити, можна викинути малу «ё» й розмістити на її місці малу «э». Такий набір символів стане несумісним з білоруською мовою (де Ёё є обов'язковою буквою на письмі, на відміну від російської, де без цих витребеньок можна обійтися), тому має сенс узяти за основу такого кодування не cp866, а cp1125, в якому білоруська початково не підтримується, зате є повний український алфавіт. Я взяв за основу кодування FreeDOS 30039 — варіант 1125 з заміною ¤ на ₴ та деякими іншими відмінностями; у кодових позиціях, які довелося звільнити від літер, можна розмістити знаки валют € та ₿. Таким чином, набіо однобайтних кодів цього кодування матиме такий вигляд:
(https://i.ibb.co/X4RNTm5/26-06-2023-13-22-40.png) (https://ibb.co/wLm31DQ)
Однобайтний варіант лишається повністю сумісним з українськими (а також болгарськими) текстами в cp1125, російські тексти в cp866/cp1125 стають частково несумісними (через іншу позицію малої «э»), потребують перекодування.
У багатобайтному варіанті використовуються всі однобайтні коди, але поєднання байтів початку (0xC0...0xDF, 0xED, 0xF0) з байтами продовження (0x80...0xBF) обробляються як коди utf-8 (стандартні та наддовгі). Більша частина байтів продовження є одночасно кириличними літерами, але жоден з байтів початку не є літерою — таким чином, випадкове утворення цих комбінацій у словах є малоймовірним.
Як можете бачити зі скріншоту вище, зараз бавлюся з DOSBox'ом.
Одразу виникає питання: чи не можна в ньому якось збільшити кількість символів по вертикалі (та, в ідеалі, вертикальний розмір вікна)? Майкрософтівський edit (що входить у комплект windows) під DOSBox'ом може збільшувати кількість символів (зменшуючи їх розмір), але лише на час своєї роботи. Було б зручно мати аналогічну можливість у середовищі командної оболонки.
EVAFONT, схоже, намагається відображати текст двома шрифтами (окремо для інтерфейсу і той, що редагується), але це не працює, інтерфейс стає без букв — доводиться відключати цю можливість опцією /f.
Поки що не розібрався, що собою являють рідні DOSBox'івські розкладки, які підключаються командою keyb — як замінити вбудовані своїми власними (наскільки можу зрозуміти, вони мають лежати в cpi-файлах, що підключаються тією ж командою keyb, але ті CPX/CPI, що мені досі траплялись, містили лише шрифти для кодових сторінок). Утім, розкладки досить легко робляться за допомогою keyrus (причому, редагувати їх можна й тим же макрософтівським edit'ом у двійковому режимі, задавши ширину 53). Додаткові кодові сторінки (шрифти) можна брати з архівів (https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/cpi/3.0/) та репозиторіїв FreeDOS (https://github.com/FDOS/cpi), попередньо розпакувавши CPX y CPI за допомогою UPX (https://en.wikipedia.org/wiki/UPX), і підключати командою
keyb none номер_кодової_сторінки файл.cpi
або ж драйвери для саморобних шрифтів може створювати й сам evafont.
Multi-Edit умеет менять высоту символа (и, следовательно, количество строк на экране); насколько я помню, это работает и под DOSbox. Если из-под Multi-Edit'а запустить DOS shell (или напрямую какую-нибудь программу), то он не меняет перед этим режим экрана (вот после возврата — проверяет, не изменился ли режим и, если надо, восстанавливает).
Да, работает. Более того, оказалось, что DOSbox и режимы со 132 символами в строке успешно эмулирует, правда, с некоторой ошибкой: начиная с какой-то там строки выдаётся снова начало текстового буфера. Надо посмотреть, может, это можно исправить в настройках DOSbox (дать больше памяти под буфер, если есть такая опция).
Знайшов дещо на ДОСБоксівському форумі (https://www.vogons.org/viewtopic.php?t=22617&start=19) — набір утиліт для перемикання текстових режимів.
Режимы как таковые можно переключать и командами DOS: mode co80 и ещё несколько.
Или зайти в debug (в комплекте к DOS) и набрать несколько команд, чтобы запустить программное прерывание BIOS для переключения экрана.
Но изменение высоты символа должно сопровождаться загрузкой кастомного шрифта под этот размер, а этого нет ни в комплекте, ни в прерываниях (кроме стандартных высот: 8, 14, 16).
В моём Мulti-Edit'е такие шрифты под разные высоты есть, и есть редактор, позволяющий их создавать, копировать, редактировать.
Досбоксівський набір команд дещо урізаний — там нема mode. Той mode, що входить входить у комплект windows, під дос не працює (хоча й .com). Треба буде поекспериментувати з запуском під досбоксом утиліт з повноцінної ДОС.
Кстати, все эти эксперименты с нестандартными кодировками вполне можно проводить в самом Multi-Edit'е. Там есть для этого все средства. И редактор символов (с возможностью копирования, конечно), и настраиваемая высота символа, и разные настройки функций разных символов (я выше приводил пример формата). Если бы дополнительно к этому нужно было ещё что-то, я бы это сделал его же средствами. (И сейчас могу, если тебе понадобится что-то, что мне не пришло в голову в своё время).
Цитата: mnashe от июня 28, 2023, 13:11Да, работает. Более того, оказалось, что DOSbox и режимы со 132 символами в строке успешно эмулирует, правда, с некоторой ошибкой: начиная с какой-то там строки выдаётся снова начало текстового буфера. Надо посмотреть, может, это можно исправить в настройках DOSbox (дать больше памяти под буфер, если есть такая опция).
Цитата: Python от июня 27, 2023, 15:31EVAFONT, схоже, намагається відображати текст двома шрифтами (окремо для інтерфейсу і той, що редагується), але це не працює, інтерфейс стає без букв — доводиться відключати цю можливість опцією /f.
Розвиток оригінального DosBox-а вже давно зупинився, замість нього прийшов DosBox-X. Спробував evafont -- так, під DosBox дійсно глючить, під X працює нормально. А останній навчився емулювати навіть приколи з растром. Все дивуюся, як це працює??? Як буде час, постараюся розібратися в сирцях. Ось порівняння DosBox 0.74-3 та DosBox-X 2023.05.01
(https://images.lingvoforum.net/images/2023/07/03/dosbox.th.png) (https://images.lingvoforum.net/image/iu1Qa) (https://images.lingvoforum.net/images/2023/07/03/dosbox-x.th.png) (https://images.lingvoforum.net/image/iu6zQ)
Схоже, evafont намагається завантажити за замовчуванням шрифт для інтерфейсу з BIOS, який у DOSBox'і за замовчуванням порожній чи несумісний з ним. Якщо перед запуском evafont запустити драйвер шрифту, згенерований самим же evafont'ом, то в інтерфейс підвантажується шрифт з драйвера.
Є щонайменше 2 способи завантаження шрифтів, що конфліктують між собою. Метод, що використовує keyb, відрізняється від методу, що використовують драйвери, згенеровані evafont'ом. При перемиканні текстових відеорежимів згаданими вище утилітами, може одночасно відбуватись перемикання з одного шрифту на інший (при однаковому розмірі). У деяких режимах один з методів, використаний після іншого, перестає давати ефект, тоді як інші лишаються сприйнятливими до обох методів.
В Multi-Edit'е всё работает корректно, никаких проблем со шрифтами нет.
Цитата: mnashe от июля 4, 2023, 00:21В Multi-Edit'е всё работает корректно, никаких проблем со шрифтами нет.
Ну, зрозуміло, что нема TSR (Terminate & Stay Resident) -- нема проблем. Я так зрозумів, Python хоче зробити шрифти й використовувати їх в інших програмах.
Кстати, смену шрифтов при помощи TSR я реализовал ещё на монохромной видеоплате Hercules, где функции смены шрифтов нет вообще. Программа устанавливала адрес буфера графической памяти отличным от адреса текстового буфера; создавала в обычной памяти буфер, куда копировала текст с экрана, затем переводила экран в графический режим, выводила текст на экран в выбранном шрифте, и затем по таймеру периодически сверяла содержимое текстового буфера контроллера и своего собственного, и выводила на графический экран только то, что изменилось. Таким образом даже на моём 386SX поддерживалась приемлемая скорость.
Но тут я имел в виду, что, возможно, средств Multi-Edit'а, запущенного под эмулятором, хватит вообще для всех задач, связанных со шрифтами. Недостающий функционал, если и есть, легко написать в нём же, плюс есть возможность запуска программ из-под него (в памяти при этом остаётся порядка 70 килобайт, что, конечно, много в сравнении с TSR, но для многих применений некритично).
DOSBox цікавить мене, в першу чергу, як емулятор текстової консолі (з підтримкою можливостей, відсутніх у стандартному вікні командного рядка windows). Але при цьому було б непогано, щоб основна частина програми виконувалась у самій windows (чи іншій операційній системі, що працює на верхньому рівні), а DOSBox використовувався для її вводу-виводу як термінал.
Виникає питання, як ці дві частини можуть обмінюватись даними. Перше, що можу придумати — змонтувати директорію на диску (можливо, на віртуальному диску в оперативці) і обмінюватись даними через файлову систему. Недоліком такого підходу є те, що DOSBox взаємодіє з файловою системою, використовуючи кеш, і зміни на диску, зробені зовнішньою програмою у windows, стають видимими для DOS-програм лише після того, як цей кеш очищено командою rescan. Тобто, доведеться викликати rescan при кожній перевірці повідомлень зовнішньої програми (напр., по кілька разів на секунду).
Цікаво, чи не існує якогось більш цивілізованого способу взаємодії між DOS-програмою в DOSBox'i та зовнішньою програмою у windows?
Цитата: Python от июля 9, 2023, 11:48DOSBox цікавить мене, в першу чергу, як емулятор текстової консолі (з підтримкою можливостей, відсутніх у стандартному вікні командного рядка windows). Але при цьому було б непогано, щоб основна частина програми виконувалась у самій windows (чи іншій операційній системі, що працює на верхньому рівні), а DOSBox використовувався для її вводу-виводу як термінал.
Можливо, краще створити якусь програму емулятора терміналу безпосередньо, без жодного DOS.
Цитата: Python от июля 9, 2023, 11:48Виникає питання, як ці дві частини можуть обмінюватись даними. Перше, що можу придумати — змонтувати директорію на диску (можливо, на віртуальному диску в оперативці) і обмінюватись даними через файлову систему. Недоліком такого підходу є те, що DOSBox взаємодіє з файловою системою, використовуючи кеш, і зміни на диску, зробені зовнішньою програмою у windows, стають видимими для DOS-програм лише після того, як цей кеш очищено командою rescan. Тобто, доведеться викликати rescan при кожній перевірці повідомлень зовнішньої програми (напр., по кілька разів на секунду).
Цікаво, чи не існує якогось більш цивілізованого способу взаємодії між DOS-програмою в DOSBox'i та зовнішньою програмою у windows?
Эта задача очень близка к моей, о которой я писал. Только у меня наоборот: основная работа идёт в Multi-Edit'е, исполняемом в виртуальной машине (XP или 7), но поскольку Multi-Edit, кроме прочего, это и «оболочка», запускающая прочие программы (скажем, запустить выбранный просмотровщик, загрузив в него текущий файл), то я хочу, чтобы запуск происходил не виртуалке, где память ограничена и не все программы есть, а в хосте. То есть мне надо из виртуалки послать команду хосту.
Простейшая реализация — записывать в определённый файл информацию о запуске (командная строка, каталог, параметры), а в хосте сканировать несколько раз в секунду, не изменилось ли время создания файла, и если изменилось, запускать. Но это уж очень неоправданный перерасход. Более умное решение — функция ожидания изменений в каталоге, которая возвращается только тогда, когда эти изменения произошли. Я уже даже нагуглил в WinApi, как это делается, но надо сесть и написать, а я уже много лет ничего не писал прямо под Windows, и надо вспоминать / учить почти с нуля.
Цитата: mnashe от июля 10, 2023, 00:04Цитата: Python от июля 9, 2023, 11:48Виникає питання, як ці дві частини можуть обмінюватись даними. Перше, що можу придумати — змонтувати директорію на диску (можливо, на віртуальному диску в оперативці) і обмінюватись даними через файлову систему. Недоліком такого підходу є те, що DOSBox взаємодіє з файловою системою, використовуючи кеш, і зміни на диску, зробені зовнішньою програмою у windows, стають видимими для DOS-програм лише після того, як цей кеш очищено командою rescan. Тобто, доведеться викликати rescan при кожній перевірці повідомлень зовнішньої програми (напр., по кілька разів на секунду).
Цікаво, чи не існує якогось більш цивілізованого способу взаємодії між DOS-програмою в DOSBox'i та зовнішньою програмою у windows?
Эта задача очень близка к моей, о которой я писал. Только у меня наоборот: основная работа идёт в Multi-Edit'е, исполняемом в виртуальной машине (XP или 7), но поскольку Multi-Edit, кроме прочего, это и «оболочка», запускающая прочие программы (скажем, запустить выбранный просмотровщик, загрузив в него текущий файл), то я хочу, чтобы запуск происходил не виртуалке, где память ограничена и не все программы есть, а в хосте. То есть мне надо из виртуалки послать команду хосту.
Простейшая реализация — записывать в определённый файл информацию о запуске (командная строка, каталог, параметры), а в хосте сканировать несколько раз в секунду, не изменилось ли время создания файла, и если изменилось, запускать. Но это уж очень неоправданный перерасход. Более умное решение — функция ожидания изменений в каталоге, которая возвращается только тогда, когда эти изменения произошли. Я уже даже нагуглил в WinApi, как это делается, но надо сесть и написать, а я уже много лет ничего не писал прямо под Windows, и надо вспоминать / учить почти с нуля.
Ещё надо, чтобы все это работало на 64-битных системах
Цитата: Eitanbor от июля 10, 2023, 00:24Ещё надо, чтобы все это работало на 64-битных системах
А какие проблемы? DosBox 64-битный есть.
Цитата: Upliner от июля 10, 2023, 03:35Цитата: Eitanbor от июля 10, 2023, 00:24Ещё надо, чтобы все это работало на 64-битных системах
А какие проблемы? DosBox 64-битный есть.
Да, но была идея запускать программы без эмуляции, только можно эмулировать ввод-вывод
Цитата: Eitanbor от июля 10, 2023, 00:24Ещё надо, чтобы все это работало на 64-битных системах
А какая разница? С чего бы функции отслеживания изменений в каталоге работать по-разному в 32 и 64? :what:
Цитата: mnashe от июля 10, 2023, 12:44Цитата: Eitanbor от июля 10, 2023, 00:24Ещё надо, чтобы все это работало на 64-битных системах
А какая разница? С чего бы функции отслеживания изменений в каталоге работать по-разному в 32 и 64? :what:
Эти функции находятся в ОС или в Вашей программе?
Если в ОС, то, допустим, использовать регистры разных величин (rax вместо eax)
Цитата: Andrey Lukyanov от июля 9, 2023, 22:34Цитата: Python от июля 9, 2023, 11:48DOSBox цікавить мене, в першу чергу, як емулятор текстової консолі (з підтримкою можливостей, відсутніх у стандартному вікні командного рядка windows). Але при цьому було б непогано, щоб основна частина програми виконувалась у самій windows (чи іншій операційній системі, що працює на верхньому рівні), а DOSBox використовувався для її вводу-виводу як термінал.
Можливо, краще створити якусь програму емулятора терміналу безпосередньо, без жодного DOS.
Теж варіант, але не думаю, що написати свій емулятор з нуля буде простіше.
Також, у перспективі, програма-термінал могла б запускатись не в емуляторі, а, наприклад, в реальному режимі з доступом до апаратного текстового відеоадаптера, розділяючи процесорний час з прикладною програмою, запущеною в урізаній ОС без графіки (windows чи linux). Або ж термінал міг би бути фізично відокремленим від прикладної частини, запущеної на окремій машині.
Цитата: Eitanbor от июля 10, 2023, 13:17Если в ОС, то, допустим, использовать регистры разных величин (rax вместо eax)
Эти вещи, не на ассемблере, а на сях (можно даже на C#) собираются делать, так что без разницы.
Цитата: Eitanbor от июля 10, 2023, 13:17Эти функции находятся в ОС или в Вашей программе?
Le premier (https://learn.microsoft.com/en-us/windows/win32/fileio/obtaining-directory-change-notifications)
Цитата: Upliner от июля 10, 2023, 19:14Эти вещи, не на ассемблере, а на сях (можно даже на C#) собираются делать, так что без разницы.
Кстати, как раз-таки думал на ассемблере, просто потому что он у меня уже есть, а си какие-нибудь надо ещё где-то брать и устанавливать...
Цитата: Eitanbor от июля 10, 2023, 13:17Если в ОС, то, допустим, использовать регистры разных величин (rax вместо eax)
Так вроде 32-битные программы полностью поддерживаются в 64-битной ОС, разве нет?
Мне вроде нет резона писать именно 64-битную. Хотя, с другой стороны, в 32-битной ОС всё это вообще ни к чему, там 16-битная программа и без всяких виртуалок запускается.
В українському алфавіті є 7 літер, що мають графічних двійників у латиниці, відповідність з якими зберігається при зміні регістру: Аа Ее Іі Оо Рр Сс Хх. (Сюди не входять літери, що мають двійника лише в одному регістрі, як Вв, або великий і малий регістр яких відповідають різним латинським, як
Тm у курсиві). Якщо використовувати замість них латинські двійники, то в українському алфавіті (сучасному) залишиться 26 літер — рівно стільки ж, як у базовій латиниці. Якби в часи семибітних кодувань сучасний український алфавіт використовувався в комп'ютерній техніці, можна було б створити кодування, де літери одного з регістрів латиниці замінено українськими іншого регістру:
32- 33-! 34-" 35-# 36-$ 37-% 38-& 39-'
40-( 41-) 42-* 43-+ 44-, 45-- 46-. 47-/
48-0 49-1 50-2 51-3 52-4 53-5 54-6 55-7
56-8 57-9 58-: 59-; 60-< 61-= 62-> 63-?
64-@ 65-A 66-B 67-C 68-D 69-E 70-F 71-G
72-H 73-I 74-J 75-K 76-L 77-M 78-N 79-O
80-P 81-Q 82-R 83-S 84-T 85-U 86-V 87-W
88-X 89-Y 90-Z 91-[ 92-\ 93-] 94-^ 95-_
96-` 97-Я 98-Б 99-Ц 100-Д 101-Є 102-Ф 103-Ґ
104-Г 105-Ї 106-Й 107-К 108-Л 109-М 110-Н 111-Ю
112-П 113-Ч 114-Ь 115-Щ 116-Т 117-У 118-В 119-Ш
120-Ж 121-И 122-З 123-{ 124-| 125-} 126-~ 127-�
Перемикання між великими й малими літерами можна зробити керуючими символами (SI та SO, що кодуються як 0x0F та 0x0E), подібно до того, як це було реалізовано в КОІ-7 (одному з варіантів) — латинські літери, використані замість відсутніх кириличних, лишаються придатними для використання в обох регістрах. Подібно до KOI-7, таке кодування можливо прочитати, якщо хибно розкодувати його як стандартне ASCII.
Зробив реалізацію UTF-EBCDIC — просто щоб подивитись, як воно працює. (Поки що лише модуль з функціями encode() й decode(), оформити це як повноцінний кодек руки поки не дійшли).
def bytelen(firstbyte):
'''UTF-8 char len by first byte
No check if this byte valid, any byte, that does not begin multibyte sequence, gives length 1'''
if firstbyte<0xC0:
return 1
elif firstbyte<0xE0:
return 2
elif firstbyte<0xF0:
return 3
elif firstbyte<0xF8:
return 4
elif firstbyte<0xFC:
return 5
elif firstbyte<0xFE:
return 6
else:
return 7
def byteval(b):
'''Value of start or continuation byte'''
if b<0xA0:
return -1
elif b<0xC0:
return b&31
elif b<0xE0:
return b&31
elif b<0xF0:
return b&15
elif b<0xF8:
return b&7
elif b<0xFC:
return b&3
elif b<0xFE:
return b&1
else:return -1
def charminlen(cc):
if cc<=0x9F: return 1
if cc<=0x3FF: return 2
if cc<=0x3FFF: return 3
if cc<=0x3FFFF: return 4
else: return 5
def str2i8(s):
res=bytearray()
'''if cesu:
bs=s.encode('utf-16le')
codes=[bs[i]|(bs[i+1]<<8) for i in range(0, len(bs), 2)]
else:'''
codes=map(ord, s)
for c in codes:
# clen=max(minlen, charminlen(c))-1
clen=charminlen(c)-1
l=len(res)
for _ in range(clen):
res.insert(l, 160|(c&31))
c>>=5
res.insert(l, c|[0, 0xC0, 0xE0, 0xF0, 0xF8, 0xFC][clen]) #, 0xFE, 0xFF (?)
return bytes(res)
i2e=bytes(int(i,16) for i in '''
00 01 02 03 37 2D 2E 2F 16 05 15 0B 0C 0D 0E 0F
10 11 12 13 3C 3D 32 26 18 19 3F 27 1C 1D 1E 1F
40 5A 7F 7B 5B 6C 50 7D 4D 5D 5C 4E 6B 60 4B 61
F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 7A 5E 4C 7E 6E 6F
7C C1 C2 C3 C4 C5 C6 C7 C8 C9 D1 D2 D3 D4 D5 D6
D7 D8 D9 E2 E3 E4 E5 E6 E7 E8 E9 AD E0 BD 5F 6D
79 81 82 83 84 85 86 87 88 89 91 92 93 94 95 96
97 98 99 A2 A3 A4 A5 A6 A7 A8 A9 C0 4F D0 A1 07
20 21 22 23 24 25 06 17 28 29 2A 2B 2C 09 0A 1B
30 31 1A 33 34 35 36 08 38 39 3A 3B 04 14 3E FF
41 42 43 44 45 46 47 48 49 4A 51 52 53 54 55 56
57 58 59 62 63 64 65 66 67 68 69 6A 70 71 72 73
74 75 76 77 78 80 8A 8B 8C 8D 8E 8F 90 9A 9B 9C
9D 9E 9F A0 AA AB AC AE AF B0 B1 B2 B3 B4 B5 B6
B7 B8 B9 BA BB BC BE BF CA CB CC CD CE CF DA DB
DC DD DE DF E1 EA EB EC ED EE EF FA FB FC FD FE
'''.split())
def i8toebcdic(bs):
return bs.translate(i2e)
e2i=bytes(int(i,16) for i in '''
00 01 02 03 9C 09 86 7F 97 8D 8E 0B 0C 0D 0E 0F
10 11 12 13 9D 0A 08 87 18 19 92 8F 1C 1D 1E 1F
80 81 82 83 84 85 17 1B 88 89 8A 8B 8C 05 06 07
90 91 16 93 94 95 96 04 98 99 9A 9B 14 15 9E 1A
20 A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 2E 3C 28 2B 7C
26 AA AB AC AD AE AF B0 B1 B2 21 24 2A 29 3B 5E
2D 2F B3 B4 B5 B6 B7 B8 B9 BA BB 2C 25 5F 3E 3F
BC BD BE BF C0 C1 C2 C3 C4 60 3A 23 40 27 3D 22
C5 61 62 63 64 65 66 67 68 69 C6 C7 C8 C9 CA CB
CC 6A 6B 6C 6D 6E 6F 70 71 72 CD CE CF D0 D1 D2
D3 7E 73 74 75 76 77 78 79 7A D4 D5 D6 5B D7 D8
D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 5D E6 E7
7B 41 42 43 44 45 46 47 48 49 E8 E9 EA EB EC ED
7D 4A 4B 4C 4D 4E 4F 50 51 52 EE EF F0 F1 F2 F3
5C F4 53 54 55 56 57 58 59 5A F5 F6 F7 F8 F9 FA
30 31 32 33 34 35 36 37 38 39 FB FC FD FE FF 9F
'''.split())
def ebcdic2i8(bs):
return bs.translate(e2i)
def i8tostr(bs):
res=[]
half=0
i=0
while i<len(bs):
chl=bytelen(bs[i])
if chl==1:
#if it is not basic ascii, do smth, else just append it:
assert bs[i]<128
res.append((bs[i]))
else:
c=0
for b in bs[i:i+chl]:
c<<=5
c|=byteval(b)
res.append((c))
#check if res[-1] is utf16 surrogate (0xD800...0xDFFF):
#(or convert via utf-16 instead, this should join surrogates automatically....)
if half:
#res[-2:] must be surrogate pair, then join them
assert 0xDC00<=res[-1]<=0xDFFF # and 0xD800<=res[-2]<=0xDBFF
#print(f'test: {res[-2:]=}')
res[-2]=((res[-2]&1023)<<10) | res[-1]&1023 | 0x10000; res.pop()
#print(f'test: {res[-1]=}')
half=0
else:
#if res[-1] is surrogate then
if 0xD800<=res[-1]<=0xDBFF:
half=1
i+=chl
return ''.join(map(chr,res))
def encode(s):
return i8toebcdic(str2i8(s))
def decode(bs):
return i8tostr(ebcdic2i8(bs))
Якщо я правильно зрозумів з документації, кодування з самого початку задумувалось для того, щоб ним ніхто не користувався. Вмираючий EBCDIC, збагачений новим сучасним функціоналом, який йому все одно не знадобиться. Якщо увесь сенс EBCDIC — у збереженні сумісності зі старими фоматами даних, то, з точки зору сумісності з кириличними EBCDIC-кодуваннями, UTF-EBCDIC цим ідеалам не відповідає. Так, несумісність між різними EBCDIC-кодуваннями — справа звична, як і несумісність між кириличними кодуваннями, але кириличні EBCDIC-кодування являють собою одну згуртовану родину, що вийшла з ДКОІ, й досить сумісні між собою. UTF-EBCDIC походить з іншої гілки кодувань (базовий набір символів кодується так само, як у cp1047, тому текст програми, створений в українському cp1123, матиме в UTF-EBCDIC проблеми з такими символами, як [, ], !, | тощо). Кирилиця, звичайно ж, не зберігає ні сумісність, ні часткову читаність, та ще й кодується трибайтними кодами (в utf-8 кириличні коди двобайтні). Байтова ненажерливість обумовлена тим, що UTF-EBCDIC використовує лише 96 значень байтів у своїх багатобайтних кодах (в UTF-8 їх 128), тому замість 64 байтів продовження — лише 32, кожен з яких кодує п'ять бітів символьного коду замість шести.
Алгоритм utf-ebcdic загалом подібний до utf-8: юнікодівський код кожного символа передається одним чи кількома байтами ASCII-сумісного кодування, довжина коду символа задається початковим байтом. Далі це ASCII-сумісне кодування (т.зв. utf-8-mod чи i8) транслюється в EBCDIC-сумісне (власне UTF-EBCDIC). При читанні даних відбуваються зворотні перетворення. Схема перетворень між i8 та utf-ebcdic відрізняється від перетворень між KOI8 та DKOI — якщо перекодувати KOI8 в EBCDIC цим способом, то коди кириличних літер буде зміщено порівняно з ДКОІ, деякі символи базового ASCII опиняться в інших місцях таблиці.
Якби щось подібне робив я, то б спробував використати ті 96 доступних кодів дещо інакше, щоб охопити якомога більшу область 2-байтними кодами. Зробімо 64 байти продовження, як в UTF-8 — тоді лишається 32 байти початку. Це стільки ж, як байтів початку 2-байтних послідовностей в UTF-8, але нам треба з них викроїти ще байти початку для довших послідовностей. На щастя, коротші послідовності можна замінювати довшими. Щоб охопити увесь юнікод, достатньо й п'яти байтів початку 4-байтних послідовностей — лишається 27. Викроювати з них коди для 3-байтних послідовностей не будемо (в utf-8 їх 16, але це більше половини того, що залишилось, тому 3-байтні послідовності доцільніше замінити наддовгими 4-байтними). Таким чином, лишається 27 байтів початку 2-байтних кодів — цього достатньо, щоб охопити юнікодівські коди до 0x06BF (тобто, 1728), кириличні коди теж входять у цю область, тому кодуватимуться двома байтами, як в UTF-8.
Або ж можна піти в оптимізації ще далі, відвівши один байт початку на 4-байтні коди і один байт початку на 5-байтні (що в стандартному UTF-8 не використовуються) — таким чином, решта 30 байтів початку можуть кодувати 2-байтні послідовності. Така заміна збільшить довжину більшості кодів після 0xFFFF, але ті 3-байтні коди, що вище пропонувалось замінити 4-байтними, так і залишаться 4-байтними, а частина з них заміниться 2-байтними. Причому, байтів початку для 4- та 5-байтних послідовностей усього два, а серед байтів початку 2-байтних кодів є якраз два невикористовувані, відведені для наддовгих кодів ASCII, які все одно передаються однобайтними кодами — можна розмістити ці 4- та 5- байтні початки на місці наддовгих двобайтних. Тоді двобайтні коди зможуть охопити область до 0x07FF (тобто, 2047).
Ще можна зробити таке кодування (назвімо його UTF-DKOI) більш ДКОІ-сумісним: узяти перекодування ASCII<=>EBCDIC на основі KOI8<=>DKOI. Щоб це дало якусь користь кирилиці, юнікодівські коди кириличних букв слід перевпорядкувати в KOI-порядку. Таке складне перетворення UTF-32 <=> KOI-32 <=> my-UTF-8-mod <=> UTF-DKOI дозволить отримати текст, який, прочитаний за правилами DKOI-подібних кодувань, зберігатиме часткову читаність кирилиці (більшість кириличних літер матимуть другий байт, ідентичний коду літери в однобайтному DKOI, тому «Доброго дня!» розкодується приблизно як «§Д§о§б§р§о§г§о §д§н§я!»).
Для тих, кому EBCDIC-кодування сподобалися настільки, що виникло бажання не лише зберігати в них текстові дані, а й створювати програми. Це можливо, але, як завжди, є нюанс.
Якщо ваша мова — Java, кодування файлів з початковим кодом можна задати в параметрах компілятора. Java з коробки пропонує достатньо широкий асортимент кодувань цього типу, у т.ч., кириличне cp1025 та його українську модифікацію cp1123.
C:\Users\py\Desktop\try\ebcdic>chcp 21025
Active code page: 21025
C:\Users\py\Desktop\try\ebcdic>echo public class try1123{public static void main(String argv[]){System.out.println("Привіт, EBCDIC-1123!");}}>try1123.java
C:\Users\py\Desktop\try\ebcdic>javac -encoding cp1123 try1123.java
C:\Users\py\Desktop\try\ebcdic>java try1123
М0YSш2��єђѓёјѓ ��␈��
C:\Users\py\Desktop\try\ebcdic>chcp 1251
Active code page: 1251
C:\Users\py\Desktop\try\ebcdic>java try1123
Привіт, EBCDIC-1123!(Кодування початкового коду та кодування вводу-виводу — різні речі, тому java тут виводить текст у кодуванні за замовчуванням — cp1251).
Складніше, якщо ваша мова програмування — Python. Асортимент EBCDIC-кодувань, що постачаються з пітоном, досить бідний — зокрема, кириличних серед них нема взагалі (хоча є грецьке cp875, частково сумісне з кириличними — пунктуація в ньому та в кирилиці кодується однаково, що для EBCDIC-кодувань уже досягнення). Але це дрібниця — можна довстановити пакет ebcdic, що постачає кодування, доступні в джаві, і скопіювати кодування з нього в Lib/encodings. Складність в іншому: кодування файлу .py треба вказувати в самому файлі спеціальним коментарем — для ascii-несумісних кодувань це проблема, бо компілятор очікує, що спецкоментар буде в ascii.
Можна створити файл у мішаному кодуванні — частина в ascii, частина в ebcdic. І в частині випадків це працює:
C:\Users\py\Desktop\try\ebcdic>chcp 866
Active code page: 866
C:\Users\py\Desktop\try\ebcdic>echo # encoding=cp500>try500.py
C:\Users\py\Desktop\try\ebcdic>chcp 500
Active code page: 500
C:\Users\py\Desktop\try\ebcdic>echo.>>try500.py
C:\Users\py\Desktop\try\ebcdic>echo print('Hello, EBCDIC-500!')>>try500.py
C:\Users\py\Desktop\try\ebcdic>py -3 try500.py
Hello, EBCDIC-500!
Але якщо спробувати цей же комбінований файл запустити як модуль чи імпортувати, то python з кодуванням не впорається:
C:\Users\py\Desktop\try\ebcdic>py -3 -m try500
Traceback (most recent call last):
File "C:\Users\py\AppData\Local\Programs\Python\Python38-32\lib\runpy.py", line 185, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "C:\Users\py\AppData\Local\Programs\Python\Python38-32\lib\runpy.py", line 155, in _get_module_details
code = loader.get_code(mod_name)
File "<frozen importlib._bootstrap_external>", line 916, in get_code
File "<frozen importlib._bootstrap_external>", line 846, in source_to_code
File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
File "C:\Users\py\Desktop\try\ebcdic\try500.py", line 1
��Á>Ä?ÀÑ>Å
Äø�����
^
SyntaxError: invalid character in identifierЯкщо пітонівська програма запускається як скрипт, і в першому чи другому рядку вказується її кодування, то читання в цьому кодуванні починається після цього спеціального коментаря, тому цієї помилки не виникає. Але якщо це модуль, то читання в новому кодуванні починається від початку файлу — в ньому ж повторно перечитується цей керуючий коментар, записаний в EBCDIC-несумісному кодуванні, тому виникає помилка. Проблему можна обійти, створивши спеціалізований кодек для початкового коду в мішаному кодуванні. Від стандартного cp500 він відрізнятиметься лише тим, що байти, які кодують '#' та '\n' в ASCII, кодуватимуть ці ж символи і в ньому (дублюючи EBCDIC-коди для них, що використовуватимуться в решті коду). Тоді ascii-коментарі лишатимуться коментарями, тому таке кодування можна використовувати і в модулях.
Задався питанням, як же насправді виглядало українське DOS-кодування (воно ж RUSCII, воно ж cp1125), яке було стандартизовано. Вірніше, коди літер у ньому відомі з багатьох джерел (загалом збігаються з cp866, але якщо в cp866 коди 0xF0...0xF9 заповнено символами Ё ё Є є Ї ї Ў ў ° ∙ , то в cp1125 там розміщено літери Ё ё Ґ ґ Є є І і Ї ї ), а ось щодо решти кодів (0xFA...0xFF) існують різні версії.
Читання стандарту нічого не дає — в мережі можна знайти не скан паперового оригіналу, а лише текстовий файл (http://porokhnyak.org/cyr/RST2018.zip) у приблизно тому ж кодуванні, яке він сам описує, чи спорідненому з ним, з якого навіть складно зрозуміти, як кодуються українські літери, нечіткість визначень яких компенсується «розумною» стилістикою. Нелітерні символи 0xFA...0xFF у ньому подаються без словесного опису (інакше кажучи, їхній вигляд залежить від того, в якому кодуванні цей файл відкрито). Також у тексті держстандарту згадується «альтернативне кодування», модифікацією якого є українське ДОС-кодування, але на той час це кодування вже існувало в кількох модифікаціях, і незовсім зрозуміло, йдеться про оригінальний варіант альтернативного кодування чи якусь із його модифікацій, яку теж могли «по-науковому» назвати альтернативним кодуванням. Власне, звідси й неоднозначності.
Джерелом інформації також можуть бути шрифти з українізаційних пакетів для ДОС, що використовувались у той час. Так, існує архів c1125sf.zip (http://porokhnyak.org/DL/c1125sf.zip) (підписаний як «Set of screen fonts in RUSCII (Ukrainian standard RST 2018-91) aka CP1125. Resolution: 8x8, 8x14, 8x16 dots. Porokh» і з датою файлів 28.07.1999), де порядок нелітерних символів збігається з прийнятим у сучасному cp866 (· √ № ¤ ■ NBSP). Шрифтова особливість: велика українська І там має крапку, як İ (імовірно, наслідок буквального розуміння побутової назви української «І з крапкою», щоб не плутати з російською «І без крапки» — И). Файли датовано 1999 роком, але ті українські шрифти, які я бачив у школі на комп'ютері році так у 1995-97, теж мали крапку над кириличною І, тому, ймовірно, цей варіант кодування використовувався ще в середині 90-х, або й раніше. Але в цей час вже існував сучасний варіант cp866, і ми не знаємо, чи не зазнали ці шрифти його впливу.
Подібний набір символів мають українські шрифти, поширювані з пакетом keyrus — без крапки над І, але з великою сигмою (чи знаком суми) та параграфом на місці, відповідно, знаку валюти та нерозривного пробілу (тобто, діапазон символів 0xFA...0xFF має вигляд · √ № Σ ■ §) — файли датовано 1992 роком, що хронологічно близько до часу створення стандарту, але в пізніших реалізаціях cp1125 такий набір символів вже не з'являється.
У сучасних реалізаціях iconv та python порядок символів у cp1125 ідентичний тому, що ми бачимо в c1125sf
.zip (0xFA...0xFF має вигляд · √ № ¤ ■ NBSP), кирилична велика І крапки не має.
Проте, з буквального прочитання стандарту випливає дещо інший варіант кодування. Якщо за основу cp1125 взято оригінальне альтернативне кодування, то в діапазоні 0xFA...0xFF мають бути успадковані з нього символи ÷ ± № ¤ ■ NBSP. Цієї версії дотримуються IBM, FreeDOS, англійська Вікіпедія.
Таким чином, є щонайменше три варіанти cp1125, що можуть претендувати на історичну першість:
cp1125-IBM
248-Ї 249-ї 250-÷ 251-± 252-№ 253-¤ 254-■ 255-NBSP
cp1125-iconv
248-Ї 249-ї 250-· 251-√ 252-№ 253-¤ 254-■ 255-NBSP
cp1125-keyrus
248-Ї 249-ї 250-· 251-√ 252-№ 253-Σ 254-■ 255-§