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

[mnashe]

Можно использовать программу-конвертер

Нет.

а также писать на Kotlin

Що це таке?

[mnashe]

А, ну так это ж всё равно с нуля, какая разница, на чём.

[Eitanbor]

а также писать на Kotlin

Що це таке?

Це мова програмування. Можна писати на JVM, на Native, на JS, здається, на ще щось

[mnashe]

Проблема же вообще не в языке, язык можно взять любой. Проблема в несовместимой аппаратной платформе. При этом программа написана без малейшей оглядки на совместимость, она полностью привязана к x86 платформе. Без   DOS-прерываний там обойтись ещё можно (они не так много используются, только для работы с файлами, что легко переделать), а вот все команды, работающие с памятью, надо менять. То есть 100% программы.

[Eitanbor]

а вот все команды, работающие с памятью, надо менять. То есть 100% программы.

На C також потрібно переписувати сам код? Він же потім компілюється

[mnashe]

На C також потрібно переписувати сам код? Він же потім компілюється

На C в принципе можно писать так, чтобы минимизировать необходимые изменения при переходе на другую платформу (хотя не всегда это получается; или получается лишь ценой серьёзного снижения скорости или функциональности). В C сопряжение с операционной системой и аппаратурой берёт на себя среда.
А на ассемблере это априори невозможно.

[Eitanbor]

На C також потрібно переписувати сам код? Він же потім компілюється

На C в принципе можно писать так, чтобы минимизировать необходимые изменения при переходе на другую платформу (хотя не всегда это получается; или получается лишь ценой серьёзного снижения скорости или функциональности). В C сопряжение с операционной системой и аппаратурой берёт на себя среда.
А на ассемблере это априори невозможно.

Интересно, на Kotlin'е можно откомпилировать код на MS-DOS?

[Python]

Як програміст, мушу зазначити, що 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]

тобто, всі літери з 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 та ДКОІ.)

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

[Python]

Проблема же вообще не в языке, язык можно взять любой. Проблема в несовместимой аппаратной платформе. При этом программа написана без малейшей оглядки на совместимость, она полностью привязана к x86 платформе. Без   DOS-прерываний там обойтись ещё можно (они не так много используются, только для работы с файлами, что легко переделать), а вот все команды, работающие с памятью, надо менять. То есть 100% программы.

Якщо переносити таку програму на іншу платформу, то, мабуть, потрібна віртуальна модель фізичної машини, для якої програму було створено. Напр., там може бути масив, що імітує текстову відеопам'ять, куди програма може записувати відображуваний текст і звідки періодично він зчитується, щоб перемалюватися на реальному екрані. Щось назразок симулятора, але з акцентом не на реалістичну імітацію старої машини, а на продуктивність, практичну зручність і можливість подальшого розширення функціоналу.

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

Втім, не бачу причин, чому такий симулятор не міг би існувати. Існують же платформи назразок Java, цілковито побудовані навколо виконання коду в віртуальній машині. Принципова різниця — віртуальна машина має базуватися на реальній. Але, власне, симулятори це й роблять.

[Python]

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

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

Р.Ѕ. Хотів був вставити для демонстрації знак біткоїна, але несподівано виявив, що тут він відображається як знак рубля. ₿ — ви теж бачите рубль замість того, що треба, чи це мій локальний глюк?

P.P.S. Схоже, що глюк локальний. Якщо в вас така ж проблема, пошукайте шрифт, який підставляється й робить таке неподобство (в моєму випадку — PT Serif, де невикористане місце в області знаків валют забили рублями).

[Eitanbor]

Р.Ѕ. Хотів був вставити для демонстрації знак біткоїна, але несподівано виявив, що тут він відображається як знак рубля. ₿ — ви теж бачите рубль замість того, що треба, чи це мій локальний глюк?

Я бачу символ Біткойну

PT Serif, де невикористане місце в області знаків валют забили рублями

Занадто багато поваги до ₒккупантсько-нацистсько-фашистсько-ᵢмперсько-ₚашистської валюти

[mnashe]

Якщо переносити таку програму на іншу платформу, то, мабуть, потрібна віртуальна модель фізичної машини, для якої програму було створено. Напр., там може бути масив, що імітує текстову відеопам'ять, куди програма може записувати відображуваний текст і звідки періодично він зчитується, щоб перемалюватися на реальному екрані. Щось назразок симулятора, але з акцентом не на реалістичну імітацію старої машини, а на продуктивність, практичну зручність і можливість подальшого розширення функціоналу.

Я довольно много думал в этом направлении. Ещё 15–20 лет назад, и позже время от времени. Видится вполне реалистичным.
После такого переноса можно переписать на программный код новой платформы ядро программы — нынешнюю виртуальную машину, чтобы оно работало быстрее. Остальное не так критично.
Впрочем, она и в самых обычных эмуляторах работает быстро. И на андроиде, и на Windows.

чи вона ще й виконує якісь дії зі своїм машинним кодом як з даними (сама змінює його, або й просто виконує арифметичні дії з адресами інструкцій)

Есть два таких места, и они изолированы, так что их несложно ликвидировать.

1. В конце инициализации программа проверяет наличие арифметического сопроцессора, если он есть, то ставит указатель начала области данных сразу после библиотеки функций действительных чисел, использующих сопроцессор, а если его нет, то копирует на её место находяющуюся за ней библиотеку, использующую эмуляцию, а затем ставит указатель на конец этой библиотеки (куда попадёт этот конец после переписывания).

2. Программа состоит из трёх файлов: основной com-файл и два оверлея. В одном собственно редактор, в другом файл-менеджер, калькулятор и ввод строки. Все вызовы подпрограмм между основным модулем и первым или вторым оверлеями сделаны как ближние вызовы, и есть специальный модуль-переключатель, который перебрасывает эти ближние вызовы в область, находящуюся в другом сегменте.
При переходе на новую платформу нужно всё это убрать и полностью разделить программную память и память данных. В программной памяти тогда можно не заморачиваться компактностью команд и всю адресацию сделать, например, 20-битной (хватит и 17 бит на основной модуль + оба оверлея, не придётся ничего свопить). Тогда память данных (куча) получит невероятные 750 кБ (от нуля до 0B8000, где начинается экранная память). А если ещё и процедуры, работающие с видеопамятью, переписать (их не так много), то куча + стек вместе получат целый мегабайт.

Есть, правда, несколько скриптов, которые напрямую запускают фрагменты машинного кода. Они, естественно, работать перестанут. Но их совсем мало.

[Eitanbor]

@mnashe, можна спитати, що ця програма робить?

[Python]

Очевидна ідея, яка напрошується — використати македонську Ѓѓ як сурогат української Ґґ, також це дозволить використати існуючі бібліотеки для перетворень між великими й малими літерами та інших маніпуляцій з текстом. Таким чином, гіпотетична 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-�

[Python]

Занадто багато поваги до ₒккупантсько-нацистсько-фашистсько-ᵢмперсько-ₚашистської валюти

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

[mnashe]

@mnashe, можна спитати, що ця програма робить?

Текстовый редактор + файл-менеджер (по типу Norton Commander, но гораздо более навороченный) с мощным скриптовым языком.

[Andrey Lukyanov]

emacs не пробовали юзать?

[Eitanbor]

@mnashe, можна спитати, що ця програма робить?

Текстовый редактор + файл-менеджер (по типу Norton Commander, но гораздо более навороченный) с мощным скриптовым языком.

Можна, будь ласка, посилання на скачування?

[mnashe]

emacs не пробовали юзать?

wandrien теж згадував emacs. А я навіть не знаю що це

Можна, будь ласка, посилання на скачування?

Я вижу, что ссылка на attachment в старой теме не работает — то ли attachment ушёл в другой каталог, то ли пропал (была какая-то проблема при переносе форума).
Так что надо его куда-нибудь залить (в архиве меньше мегабайта)...

[Python]

wandrien теж згадував emacs. А я навіть не знаю що це

Текстовий редактор з можливістю розширювати функціонал, для написання плагінів використовується діалект LISP'у. Колись трохи пробував ознайомитися з ним — справляє враження чогось монструозного й архаїчного, але, здається, все, що тільки можна, в емаксі є. Хоча зараз використовую jEdit — редактор, чимось до нього подібний, зі схожими ідеями в своїй основі, але більш сучасний, і для плагінів та скриптів у ньому використовується простіший для розуміння  beanshell (інтерпретована мова на основі Java).

[Python]

Ще на тему урізаної кирилиці в кодуваннях. Надибав ось таке дивне еплівське кодування (здається, з 80-х чи 90-х):

Кодування 10-бітне (тобто, 1024-символьне), що вже рідкість. В ньому є надмірності, назразок дублювання літер кількома почерками, багато псевдографіки; з нелатинських алфавітів є грецький та кирилиця — причому, букви, що мають двійників в іншому алфавіті, не повторюються. Так, грецька велика альфа та кирилична А передаються латинською A, кирилична велика Г — грецькою великою гаммою, і т.д. (Незовсім зрозуміло, як передавати малу кириличну г — схоже, про неї забули, або ж розробники вирішили, що латинська r чи грецька γ достатньо на неї схожа).

[Python]

Я тут розмірковую над задачею, яким має бути кодування, сумісне з 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]

дещо хаотичний вторинний блок кирилиці в 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 при цьому втрачається (українські літери в ньому мають інші коди).

[Python]

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

Розділімо кодуючі байти на 2 категорії: байти початку/продовження (П) та байти кінця (К). Послідовність кодуючих байтів складається з одного чи кількох байтів П й рівно одного байту К. Є 32 різні байти П та 20 різних байтів К. Відповідно, кожному з них присвоюється числове значення — від 0 до 31 для П, від 0 до 19 для К. Грубо кажучи, це 32-кові цифри, якими записується код юнікодівського символа. Молодший розряд іде першим (тобто, порядок запису «цифр» протилежний звичному) — це спрощує обчислення, оскільки байт кінця має лише 20 значень, і обробка його як 20-кової цифри вимагала б під час кодування робити ділення та множення замість більш економних двійкових зсувів.

Число, отримане з послідовності кодуючих байтів, не є безпосередньо кодом юнікодівського числа. Щоб отримати юнікодівський код, до отриманого числа додається основа, яка залежить від кількості байтів у коді: для 2-байтних кодів — 128, для 3-байтних — 128+640, для 4-байтних — 128+640+20480 і т.д. Це треба для того, щоб коди різної довжини з однаковим числовим значенням не дублювали один одного, тому для кожної довжини кодуючої послідовності береться окремий діапазон юнікодівських кодів.

Отриманий юнікодівський код теж є незовсім юнікодівським — це т.зв. трансльований юнікод. У більшості випадків він не відрізняється від коду символа в юнікоді, але в частині випадків коди символів переставлено між собою. Для чого це потрібно: запропонована схема кодування дозволяє кодувати двома байтами лише 640 можливих юнікодівських символів, і було б доцільно розмістити в цьому діапазоні ті з них, які справді часто використовуватимуться, а щось більш екзотичне, назразок історичних латиниць, перенести в більш віддалені області. Саме для такої оптимізації робиться трансляція кодів, після якої отриманий код вже можна використовувати як юнікодівський.