Ответ

Обратите внимание: данное сообщение не будет отображаться, пока модератор не одобрит его.
Ограничения: максимум вложений в сообщении — 3 (3 осталось), максимальный размер всех файлов — 300 КБ, максимальный размер одного файла — 100 КБ
Снимите пометку с вложений, которые необходимо удалить
Перетащите файлы сюда или используйте кнопку для добавления файлов
Вложения и другие параметры
Проверка:
Оставьте это поле пустым:
Наберите символы, которые изображены на картинке
Прослушать / Запросить другое изображение

Наберите символы, которые изображены на картинке:

√36:
ALT+S — отправить
ALT+P — предварительный просмотр

Сообщения в этой теме

Автор Python
 - ноября 28, 2023, 12:16
Задався питанням, як же насправді виглядало українське DOS-кодування (воно ж RUSCII, воно ж cp1125), яке було стандартизовано. Вірніше, коди літер у ньому відомі з багатьох джерел (загалом збігаються з cp866, але якщо в cp866 коди 0xF0...0xF9 заповнено символами Ё ё Є є  Ї ї Ў ў ° ∙ , то в cp1125 там розміщено літери Ё ё Ґ ґ Є є І і Ї ї ), а ось щодо решти кодів (0xFA...0xFF) існують різні версії.

Читання стандарту нічого не дає — в мережі можна знайти не скан паперового оригіналу, а лише текстовий файл у приблизно тому ж кодуванні, яке він сам описує, чи спорідненому з ним, з якого навіть складно зрозуміти, як кодуються українські літери, нечіткість визначень яких компенсується «розумною» стилістикою. Нелітерні символи 0xFA...0xFF у ньому подаються без словесного опису (інакше кажучи, їхній вигляд залежить від того, в якому кодуванні цей файл відкрито). Також у тексті держстандарту згадується «альтернативне кодування», модифікацією якого є українське ДОС-кодування, але на той час це кодування вже існувало в кількох модифікаціях, і незовсім зрозуміло, йдеться про оригінальний варіант альтернативного кодування чи якусь із його модифікацій, яку теж могли «по-науковому» назвати альтернативним кодуванням. Власне, звідси й неоднозначності.

Джерелом інформації також можуть бути шрифти з українізаційних пакетів для ДОС, що використовувались у той час. Так, існує архів 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-§
Автор Python
 - сентября 22, 2023, 18:51
Для тих, кому 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-коментарі лишатимуться коментарями, тому таке кодування можна використовувати і в модулях.
Автор Python
 - сентября 22, 2023, 14:41
Зробив реалізацію UTF-EBCDIC — просто щоб подивитись, як воно працює. (Поки що лише модуль з функціями encode() й decode(), оформити це як повноцінний кодек руки поки не дійшли).

Якщо я правильно зрозумів з документації, кодування з самого початку задумувалось для того, щоб ним ніхто не користувався. Вмираючий 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, тому «Доброго дня!» розкодується приблизно як «§Д§о§б§р§о§г§о §д§н§я!»).
Автор Python
 - сентября 17, 2023, 06:02
В українському алфавіті є 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.
Автор mnashe
 - июля 12, 2023, 20:03
Цитата: Upliner от июля 10, 2023, 19:14Эти вещи, не на ассемблере, а на сях (можно даже на C#) собираются делать, так что без разницы.
Кстати, как раз-таки думал на ассемблере, просто потому что он у меня уже есть, а си какие-нибудь надо ещё где-то брать и устанавливать...

Цитата: Eitanbor от июля 10, 2023, 13:17Если в ОС, то, допустим, использовать регистры разных величин (rax вместо eax)
Так вроде 32-битные программы полностью поддерживаются в 64-битной ОС, разве нет?
Мне вроде нет резона писать именно 64-битную. Хотя, с другой стороны, в 32-битной ОС всё это вообще ни к чему, там 16-битная программа и без всяких виртуалок запускается.
Автор mnashe
 - июля 12, 2023, 19:59
Цитата: Eitanbor от июля 10, 2023, 13:17Эти функции находятся в ОС или в Вашей программе?
Le premier
Автор Upliner
 - июля 10, 2023, 19:14
Цитата: Eitanbor от июля 10, 2023, 13:17Если в ОС, то, допустим, использовать регистры разных величин (rax вместо eax)
Эти вещи, не на ассемблере, а на сях (можно даже на C#) собираются делать, так что без разницы.
Автор Python
 - июля 10, 2023, 15:09
Цитата: Andrey Lukyanov от июля  9, 2023, 22:34
Цитата: Python от июля  9, 2023, 11:48DOSBox цікавить мене, в першу чергу, як емулятор текстової консолі (з підтримкою можливостей, відсутніх у стандартному вікні командного рядка windows). Але при цьому було б непогано, щоб основна частина програми виконувалась у самій windows (чи іншій операційній системі, що працює на верхньому рівні), а DOSBox використовувався для її вводу-виводу як термінал.
Можливо, краще створити якусь програму емулятора терміналу безпосередньо, без жодного DOS.
Теж варіант, але не думаю, що написати свій емулятор з нуля буде простіше.

Також, у перспективі, програма-термінал могла б запускатись не в емуляторі, а, наприклад, в реальному режимі з доступом до апаратного текстового відеоадаптера, розділяючи процесорний час з прикладною програмою, запущеною в урізаній ОС без графіки (windows чи linux). Або ж термінал міг би бути фізично відокремленим від прикладної частини, запущеної на окремій машині.
Автор Eitanbor
 - июля 10, 2023, 13:17
Цитата: mnashe от июля 10, 2023, 12:44
Цитата: Eitanbor от июля 10, 2023, 00:24Ещё надо, чтобы все это работало на 64-битных системах
А какая разница? С чего бы функции отслеживания изменений в каталоге работать по-разному в 32 и 64? :what:

Эти функции находятся в ОС или в Вашей программе?
Если в ОС, то, допустим, использовать регистры разных величин (rax вместо eax)
Автор mnashe
 - июля 10, 2023, 12:44
Цитата: Eitanbor от июля 10, 2023, 00:24Ещё надо, чтобы все это работало на 64-битных системах
А какая разница? С чего бы функции отслеживания изменений в каталоге работать по-разному в 32 и 64? :what: