Как перекодировать 866 в Юникод?

man iconv

программно… на любом языке, кроме использования модулей.

нейрослоп не? :)

; Инициализация таблицы перекодировки CP-866 -> Unicode
Global Dim CP866Map.u(255)
For i = 0 To 127 : CP866Map(i) = i : Next ; Первые 128 символов совпадают с ASCII

; Заполнение кириллицы и псевдографики (диапазон 128-255)
Restore CP866_Table
For i = 128 To 255
  Read.u CP866Map(i)
Next

Procedure.s CP866ToUnicode_CrossPlatform(*Buffer.Ascii, Length.i)
  Protected Result.s = ""
  Protected *Current.Ascii = *Buffer
  
  For i = 1 To Length
    Result + Chr(CP866Map(*Current\a))
    *Current + 1
  ForNext
  
  ProcedureReturn Result
EndProcedure

DataSection
  CP866_Table:
  ; 128 - 159 (А-Я)
  Data.u $0410, $0411, $0412, $0413, $0414, $0415, $0416, $0417, $0418, $0419, $041A, $041B, $041C, $041D, $041E, $041F
  Data.u $0420, $0421, $0422, $0423, $0424, $0425, $0426, $0427, $0428, $0429, $042A, $042B, $042C, $042D, $042E, $042F
  ; 160 - 175 (а-п)
  Data.u $0430, $0431, $0432, $0433, $0434, $0435, $0436, $0437, $0438, $0439, $043A, $043B, $043C, $043D, $043E, $043F
  ; 176 - 239 (Псевдографика и р-я, Ё, ё)
  Data.u $2591, $2592, $2593, $2502, $2524, $2561, $2562, $2556, $2555, $2563, $2551, $2557, $255D, $255C, $255B, $2510
  Data.u $2514, $2534, $252C, $251C, $2500, $253C, $255E, $255F, $255A, $2554, $2569, $2566, $2560, $2550, $256C, $2567
  Data.u $2568, $2564, $2565, $2559, $2558, $2552, $2553, $256B, $256A, $2518, $250C, $2588, $2584, $258C, $2590, $2580
  Data.u $0440, $0441, $0442, $0443, $0444, $0445, $0446, $0447, $0448, $0449, $044A, $044B, $044C, $044D, $044E, $044F
  ; 240 - 255 (Ё, ё, и др.)
  Data.u $0401, $0451, $0404, $0454, $0407, $0457, $040E, $045E, $00B0, $2219, $00B7, $221A, $2116, $00A4, $25A0, $00A0
EndSection

выглядит похоже :))))))))

  | .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
--+------------------------------------------------
0.| ^@ ^A ^B ^C ^D ^E ^F ^G ^H ^I ^J ^K ^L ^M ^N ^O
1.| ^P ^Q ^R ^S ^T ^U ^V ^W ^X ^Y ^Z ^[ ^\ ^] ^^ ^_
2.|     !  "  #  $  %  &  '  (  )  *  +  ,  -  .  /
3.|  0  1  2  3  4  5  6  7  8  9  :  ;  <  =  >  ?
4.|  @  A  B  C  D  E  F  G  H  I  J  K  L  M  N  O
5.|  P  Q  R  S  T  U  V  W  X  Y  Z  [  \  ]  ^  _
6.|  `  a  b  c  d  e  f  g  h  i  j  k  l  m  n  o
7.|  p  q  r  s  t  u  v  w  x  y  z  {  |  }  ~ ^?
8.|  А  Б  В  Г  Д  Е  Ж  З  И  Й  К  Л  М  Н  О  П
9.|  Р  С  Т  У  Ф  Х  Ц  Ч  Ш  Щ  Ъ  Ы  Ь  Э  Ю  Я
A.|  а  б  в  г  д  е  ж  з  и  й  к  л  м  н  о  п
B.|  ░  ▒  ▓  │  ┤  ╡  ╢  ╖  ╕  ╣  ║  ╗  ╝  ╜  ╛  ┐
C.|  └  ┴  ┬  ├  ─  ┼  ╞  ╟  ╚  ╔  ╩  ╦  ╠  ═  ╬  ╧
D.|  ╨  ╤  ╥  ╙  ╘  ╒  ╓  ╫  ╪  ┘  ┌  █  ▄  ▌  ▐  ▀
E.|  р  с  т  у  ф  х  ц  ч  ш  щ  ъ  ы  ь  э  ю  я
F.|  Ё  ё  Є  є  Ї  ї  Ў  ў  °  ∙  ·  √  №  ¤  ■   

Берёшь таблицу. Нужны коды?

cat cp866.txt | iconv -f cp866 | tail -8 | cut -d ' ' -f 2- | tr -d ' \n' | iconv -t utf32le | od -An -tu4 -w9000 | tr -s ' '
 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 9617 9618 9619 9474 9508 9569 9570 9558 9557 9571 9553 9559 9565 9564 9563 9488 9492 9524 9516 9500 9472 9532 9566 9567 9562 9556 9577 9574 9568 9552 9580 9575 9576 9572 9573 9561 9560 9554 9555 9579 9578 9496 9484 9608 9604 9612 9616 9600 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1025 1105 1028 1108 1031 1111 1038 1118 176 8729 183 8730 8470 164 9632 160

Похоже, с твоей совпадает, значит дело не в таблице.

Не вникал в твой код, но из общих соображений или таблица неправильная или неправильно работаешь с ней. Учти, что в 866-й кодировке символы расположены не последовательно, есть разрыв на псевдографику в середине.

Ищи где у тебя ошибка! Таблица верная, вот код, который всё перекодирует идентично iconv -f cp866. Кстати писал сам, не нейрослоп:

#include <stdio.h>

const unsigned cp866_to_utf[128] = {
	1040, 1041, 1042, 1043, 1044, 1045, 1046, 1047,
	1048, 1049, 1050, 1051, 1052, 1053, 1054, 1055,
	1056, 1057, 1058, 1059, 1060, 1061, 1062, 1063,
	1064, 1065, 1066, 1067, 1068, 1069, 1070, 1071,
	1072, 1073, 1074, 1075, 1076, 1077, 1078, 1079,
	1080, 1081, 1082, 1083, 1084, 1085, 1086, 1087,
	9617, 9618, 9619, 9474, 9508, 9569, 9570, 9558,
	9557, 9571, 9553, 9559, 9565, 9564, 9563, 9488,
	9492, 9524, 9516, 9500, 9472, 9532, 9566, 9567,
	9562, 9556, 9577, 9574, 9568, 9552, 9580, 9575,
	9576, 9572, 9573, 9561, 9560, 9554, 9555, 9579,
	9578, 9496, 9484, 9608, 9604, 9612, 9616, 9600,
	1088, 1089, 1090, 1091, 1092, 1093, 1094, 1095,
	1096, 1097, 1098, 1099, 1100, 1101, 1102, 1103,
	1025, 1105, 1028, 1108, 1031, 1111, 1038, 1118,
	176,  8729, 183,  8730, 8470, 164,  9632, 160
};

int main() {
	int c;
	unsigned ucode;
	while ((c=getchar()) != EOF) {
		if (c < 128) {
			putchar(c);
		} else {
			ucode = cp866_to_utf[c-128];
			if (ucode < 2048) {
				putchar((ucode >> 6)   | 0xC0);
				putchar((ucode & 0x3F) | 0x80);
			} else if (ucode < 65536) {
				putchar((ucode >> 12)          | 0xE0);
				putchar(((ucode & 0xFC0) >> 6) | 0x80);
				putchar((ucode & 0x3F)         | 0x80);
			} else {
				fputs("Add logic to encode 4-byte chars first!\n", stderr);
			}
		}
	}
	return 0;
}

@anonymous_incognito, а что там вникать? Я сверил с таблицей из iconv, в стартовом посте всё верно, только запятых не хватает между строчками, пришлось их добавлять.

Посмотри лучше мой код. По-моему всё чётко и читаемо? Ну и главное, работает как надо.

Procedure.s CP866ToUnicode_CrossPlatform(*Buffer.Ascii, Length.i)

Что это за хтонический кошмар?

Ищи где у тебя ошибка

Ну может причина, что я не стал заморачиваться с побайтовым чтением буфера и использовал строковые функции, то есть однобайтовая кодировка преобразовалась в двубайтовую, а уж потом я применил таблицу для преобразования, подразумевая, что двубайтовая не испортит символы.

А зачем тебе проприетарный PureBasic? Мало того что сам язык Basic по актуальности сравним с Cobol или Algol 60, так ещё и под линукс есть FreeBasic и QB64, как минимум и вроде ещё несколько разных.

Я честно говоря не вижу смысла писать на Basic кроме как под древние компы вроде ZX Spectrum или современные игрушки на микроконтроллерах вроде PicoCalc. Исторически так сложилось, что под экстремально слабые (<1M RAM) компы часто берут бейсик.

Но тогда наверное будет интереснее поработать с бейсиком у которого номера строк?

Не лезь оно тебя сожрет Наверное сто раз обсуждалось в темах ОПа его увлечение PB. Там потом вылезет хомяк на народе и хейт выкладывания исходников (но мб ОП немного исправился с последним).

Наверное за этим стоит некая глубокая философия, но она пока не разгадана.

FreeBasic и QB64

Я в новостях выкладывал, описал все плюсы. Цена за неделю оправдывается, а работать с этим годами. И чего там 8 тыс. с пожизненной лицензией, это копейки.

Я тут знакомому предложил С/С++ поучить вместе, отказался, а в одну харю не интересно.

но мб ОП немного исправился с последним

И что за исправления?

Как там юыло у Норвежского Лесного:
«Когда я был в первом классе, ко мне подошел старшеклассник и предложил писать с ним программу на Бейсике. Я стал отказываться, но он меня заставил. С тех пор я пишу программы только на Бейсике. Иногда, когда родители уходят, мы собираемся группой по 6-8 ребят и пишем программы на Бейсике вместе.
Год назад я познакомился с девушкой, и она предложила мне писать программу на Паскале. У меня ничего не вышло: меня стошнило и потом долго болела голова.
Зовут меня Валерий Павлович, в сентябре мне исполнится 47 лет. Моя жизнь сломана.»

Идея выложить исходники все же была внедрена пингвиньей колонией.

На следующий день Валерий Павлович прочитал в газете что девушку звали Эдсгер Дейкстера :-)

Идея выложить исходники все же была внедрена пингвиньей колонией.

Проснись, я ВСЕГДА выкладывал свои проги с исходниками, без них никогда, они у меня в таком формате изначально.

Я честно говоря не вижу смысла писать на Basic кроме как под древние компы

Под современные и даже с поддержкой Wayland. В том числе 3D игры.

Верим.

Но лжешь…

Верим

Три в одном чтоль?

Ты уверен что то что ты перекодирываешь это 866? Если древний текст из доса, там разные кодировки существовали, хотя в итоге и 866 всех победила.

Сейчас только винда использует 866 как я понимаю. Но и для своего блокнота я пытался сделать, как Geany умеет открывать любые, в том числе 1251, в то время как линукс не поддерживает.

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

в то время как линукс не поддерживает

Чего это вдруг такой вывод? Даже в прости-Господи-браузере есть выбор кодировок, не говоря уже о огромном количестве софта, в том числе непрограммистского. А уж там, где почему-то нет такого функционала, всегда можно воспользоваться перекодировщиком, коих точно больше одного. enca, уже упомянутый iconv, recode. Я знаю о чём говорю – иногда приходится читать CP866 и win1251 (которым, кстати и пользовались старые оффтопики, как минимум, начиная с ХР). В современных уже UTF-8 вроде как. А 866 – это из времён DOS и ранних виндов.

Я на работе.

А 866 – это из времён DOS и ранних виндов

И поздних. 11-я все также выводит в 866. При чем в консоль на англоязычной невозможно вывести 866. Гугл пишет, что можно в юникоде, но я пока не пробовал, да и делаю не для себя.

Посмотри лучше мой код. По-моему всё чётко и читаемо? Ну и главное, работает как надо.

Нормальный код, работает как надо. Мелкие, непринципиальные комментарии:

1) Я бы всё-таки использовал uint32_t вместо unsigned.

2) Хорошим тоном будет проверка stdin не только на EOF, но и на ошибку ввода.

	/* Проверка на ошибку чтения, а не просто конец файла */
	if (ferror(stdin)) {
		fputs("Error reading input data\n", stderr);
		return 1;
	}

3) Проверка на 65536 выглядит лишней. getchar() читает строго по одному байту, независимо от локали. Хотя хз, определена функция с возвратом int, и теоретически вроде могут быть извращения с fwide(stdin,1), устанавливающие «широкий» поток, но тогда там, наверное, вообще всё поломается, не проверял.

4) Если совсем душнить, то можно вспомнить про буферизацию, наверное, для очень больших файлов в сотни мегабайт и более стоит назначить буфер для stdout для скорости.

win1251 (которым, кстати и пользовались старые оффтопики, как минимум, начиная с ХР). В современных уже UTF-8 вроде как. А 866 – это из времён DOS и ранних виндов.

Нет. Проги, использующие 8-битные кодировки, при русской локали используют 1251. Наличие или отсутствие поддержки utf-8 зависит исключительно от проги. Нативный юникод для винды - utf-16, и если прога хочет работать с utf-8 она должна utf-8 строки конвертировать в utf-16 и назад при обращении к winapi. А если прога хочет работать с cp1251 - она может её просто использовать безо всяких явных конвертаций (но винда наверно будет внутри себя конвертировать). Поддержка utf-16 и конвертирований utf-8 появилась очень давно, функция MultiByteToWideChar() - конвертер в utf-16 - точно была в win95, и судя по инету была даже в win32s под win 3.x. Константа CP_UTF8 для неё присутствует в SDK от MS VC 5.0 (1997) - не знаю насколько она поддерживалась в Win95 (в хедер могла попасть из WinNT), но всё равно появилось это всё ещё в 90-х.

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

а уж потом я применил таблицу для преобразования, подразумевая, что двубайтовая не испортит символы.

Я не очень понимаю PureBasic, но не заметил, чтобы ты учёл, что для части символов из диапазона 128..255 кодировка в utf-8 двухбайтовая, а для части - трёхбайтовая.

В гуи же прогах в винде 866 вроде никогда не использовалась.

Вспомнил, что в OS/2 была 866 и в консоли и в GUI.

что для части символов из диапазона 128..255 кодировка в utf-8 двухбайтовая, а для части - трёхбайтовая.

Там UCS-2 или аналог utf-16 без той части где ширина символов больше 2-х байт. Это для строковых переменных, а буфер в памяти, конечно, можно любой.

Тогда у тебя, скорее всего проблема в том, что в 866 между строчными «п» и «р» находится блок псевдографических символов (байты 176–223). Из-за этого таблица смещена. В общем, просто смотри что на выходе получается ожидаемый код из таблицы.

Я бы всё-таки использовал uint32_t вместо unsigned.

Там в пределах 10 тысяч даже в short бы влезло

Хорошим тоном будет проверка stdin не только на EOF, но и на ошибку ввода.

Какая ошибка ввода на stdin? broken pipe? Ну так он завершится как и от EOF, это то что нужно? Но наверное надо будет почитать что за ferror потом.

3. Проверка на 65536 выглядит лишней.

Это напоминалка для программиста дописать код для астрального плана, если таковой появится в таблице перекодировки. Сейчас нет, поэтому я не стал писать лишние четыре строчки. А так по идее этот код никогда не будет исполняться. Оптимизатор должен бы выкинуть но почему-то даже с -O3 строчка сообщения остаётся в бинарнике.

Если совсем душнить, то можно вспомнить про буферизацию

Она делается на уровне libc, насколько я понимаю. getchar по системному вызову на каждый байт явно не гоняет. 100 мегабайт рандома iconv -f cp866 обрабатывает 2 секунды, а моя программа 2.6 секунд. Да, где-то оптимизацию можно сделать, но выигрыша в разы не будет.

Под современные и даже с поддержкой Wayland. В том числе 3D игры.

Да я в курсе, что теоретически возможно и морской бой на sed написать с ГПСЧ и стратегией и 3D-игры на бейсике. Но come on, это же бейсик, да ещё и проприетарный. Да, он Тьюринг-полный как и brainfuck и много всего другого, а значит на нём можно написать что угодно как и на любом другом языке. Но зачем это делать?

Ну ладно, предположим ты не хочешь изучать другие языки, но ведь и в этом случае есть QB64 и FreeBASIC и наверное ещё 100500 других. Зачем проприетарщину-то брать? Ведь это значит что кроме тебя и 3.5 анонимусов с форума PB в твои 3D-игры играть заведомо никто не будет.

QB64 и FreeBASIC

PureBasic кроссплатформенный. Тот же FreeBASIC потребует изучение GTK2, GTK3, QT5, в то время как PureBasic в винде соберёт с помощью WinAPI, в Linux с помощью GTK2, GTK3, QT5 взависимости от выбранной системы, в MacOS на Cocoa. И это будет один и тот же код. Кроме того и для Android с небольшими модификацими.

Ведь это значит что кроме тебя и 3.5 анонимусов с форума PB в твои 3D-игры играть заведомо никто не будет.

Да я и сам в них не играю, но идея написать и видеть как потом это всё работает приятно. А вот программами вполне пользуюсь. То что кто-то не пользуется меня это не напрягает, я пишу в первую очередь для себя, а другие часто подталкивают меня на идеи чего-то добавить, а потом понимаешь что и тебе это оказалось нужным. Загугли мой ник и проги.

кроме тебя и 3.5 анонимусов

Некторые у меня по 3.5 тысячи закачек. А что-то новое выкладываю взависимости от специфичности и узконаправленности от 35 закачек только счёт начинается. Гуглится даже на иностранных сайтах

Ладно, а чем Pascal не устраивает? Вот я статью выкладывал Написание простой SDL-программы на Pascal

Берёшь и пишешь на SDL кроссплатформенно, не нужно изучать никаких Gtk/Qt/WindowsAPI. Ещё есть ptcGraph совместимый с классическим Graph, но я не заглублялся, так как я в школе на паскале на этом Graph ничего не писал, или уже давно забыл.

Паскаль - почти как бейсик, но синтаксис более упорядоченный и строгий.

в то время как PureBasic в винде соберёт с помощью WinAPI, в Linux с помощью GTK2, GTK3, QT5 взависимости от выбранной системы, в MacOS на Cocoa.

Ну то есть там просто вшит кроссплатформенный тулкит, прибитый гвоздями к PB. Ну так в FPC есть тулкит LCL, который ставится с лазарусом. Но вообще, разве универсальный тулкит не лучше чем частный?

Самое плохое — то что PureBasic проприетарный. И дело вовсе не в цене. Этим все плюсы нивелируются…

Ну и даже не был бы проприетарным, судя по твоим ссылкам код страшный и нечитаемый. Вот на C гораздо короче и понятнее. Я ещё попробовал кстати нейронку попросить, она почти то же самое написала, только вынесла в отдельную функцию и сразу написала код для 4-байтников.

Неужели в бейсике нельзя написать аналогично? У тебя для cp1251 очень страшный код. Нужно просто объявить статический массив четырёхбайтных целых, лучше беззнаковых, но на самом деле пофиг и в крайнем случае можно и двухбайтных, если ты не собираешься потом расширять на другие кодировки. Затем просто читаешь по одному символу и используешь его как индекс в массиве (у меня со смещением 128 байт) и затем полученное число выводишь.

Кстати ещё один вариант — хранить сразу байты UTF-8. Тогда делаешь массив указателей на чары, где каждый указатель указывает на 2-3 байтную строчку которую и надо выводить.

Procedure.s CP866ToUnicode_CrossPlatform(*Buffer.Ascii, Length.i)

а что тебе тут непонятно?

процедура вернет стринг? или указатель? или еще какое в типах данных?

:))) ну как-то так это объявляется, даже не сильно всрато

Вообще ничего не понятно. Что такое procedure.s? Почему не procedure.t или procedure.u? Остальная фигня тоже непонятна. После точки тип возвращаемого значения? А где sub/gosub? В бейсике же был gosub чтобы звать процедуру? В бейсике цикл FOR завершается NEXT i или какая там переменная. Тут какой-то ForNext — это что вообще?

ну так это к авторам пурбэйсика, с меня то ты что хочешь? :)))

и так-то это только сама процедура ;) ее никто еще не вызывал

Я уже не раз отвечал, на этот вопрос и мне этот список языков программирования уже предлагали.

Ты бы хоть абзацы расставил. Читать почти невозможно. Специально отвечаю не через ответ, чтобы не заблокировать тебе редактирование.

Насчёт команды — тебе повезло. Сейчас есть нейронки которые как раз выполняют такую задачу - быстро отвечать на вопросы новичка, ответы на которые раньше требовали пары минут гугления или грепа по мануалам. Конечно желательно всё равно перепроверять по мануалам, но в целом должно работать.

Мне больше понравилась гугловская, сейчас она по коду отвечает вполне прилично и я так и не наткнулся на ограничения токенов в отличии от duck.ai и qwen.ai. Ещё z.ai раньше была ОК, но теперь без регистрации регулярно вайпает историю чата.

Но этот твой PureBasic похоже даже не Basic, какие-то ForNext вместо Next, какие-то Procedure вместо Sub и так далее. Dim разве что остались.

ну так это к авторам пурбэйсика, с меня то ты что хочешь? :)))

Ничего, я вообще комментировал код самого автора.

Вот нейронка если попросить написать на Basic без уточнения диалекта пишет намного понятнее и читаемее. Хотя там избыточный код, но в целом то же самое что у меня на C выше. Хотя бы типы данных AS INTEGER а не какой-то .i

Но этот твой PureBasic похоже даже не Basic, какие-то ForNext вместо Next, какие-то Procedure вместо Sub и так далее. Dim разве что остались.

От бейсика там одно название, и некоторые даже просят поменять имя.

Перепиши это на рапире, вот тогда у тебя не будут круглеть глаза от синтаксиса простых языков :) Десяток страниц на описание языка, это то что делало вариации бэйсика такими популярными

Хотя бы типы данных AS INTEGER а не какой-то .i

Я вообще не привычен к «AS INTEGER», это же как раз тот случай, когда код тяжело читать от избыточности текста.

ну тут ты не прав, вкатываться в чужой код гораздо лучше когда нет сокращений и все детально описано.

для бэйсика тоже справедливо. а вот экономить на именах переменных и делать стр быр пыр в именах функций приходилось когда это впихивали на компы с малым объемом озу

Особенно хочется разбить голову об стол, когда сокращения и всякий сахар тащат в исохдники компилируемых языков

Что такое procedure.s? Почему не procedure.t или procedure.u?

Потому что типа .t нет, вот какие есть

Вот нейронка что написала. Надо конечно переделывать, но даже так гораздо понятнее выглядит.

' cp866_to_utf8.bas
' Compatible with GW-BASIC, QBasic, QB64, and FreeBASIC

DIM cp866_to_utf(0 TO 127) AS INTEGER
DATA 1040,1041,1042,1043,1044,1045,1046,1047,1048,1049,1050,1051,1052,1053,1044,1055
DATA 1056,1057,1058,1059,1060,1061,1062,1063,1064,1065,1066,1067,1068,1069,1070,1071
DATA 1072,1073,1074,1075,1076,1077,1078,1079,1080,1081,1082,1083,1084,1085,1086,1087
DATA 9617,9618,9619,9474,9508,9569,9570,9558,9557,9571,9553,9559,9565,9564,9563,9488
DATA 9492,9524,9516,9500,9472,9532,9566,9567,9562,9556,9577,9574,9568,9552,9580,9575
DATA 9576,9572,9573,9561,9560,9554,9555,9579,9578,9496,9484,9608,9604,9612,9616,9600
DATA 1088,1089,1090,1091,1092,1093,1094,1095,1096,1097,1098,1099,1100,1101,1102,1103
DATA 1025,1105,1028,1108,1031,1111,1038,1118, 176,8729, 183,8730,8470, 164,9632, 160

FOR i = 0 TO 127
    READ cp866_to_utf(i)
NEXT i

' File I/O is used because legacy BASIC consoles line-buffer and mangle raw bytes
OPEN "input.bin" FOR BINARY AS #1
OPEN "output.bin" FOR BINARY AS #2

DO WHILE NOT EOF(1)
    GET #1, , c
    IF c < 0 THEN c = c + 256  ' Fix signed byte interpretation
    
    IF c < 128 THEN
        PUT #2, , CHR$(c)
    ELSE
        u = cp866_to_utf(c - 128)
        IF u < 2048 THEN
            ' 2-byte UTF-8: (u >> 6) | 0xC0, (u & 0x3F) | 0x80
            PUT #2, , CHR$((u \ 64) OR 192)
            PUT #2, , CHR$((u AND 63) OR 128)
        ELSE
            ' 3-byte UTF-8: (u >> 12) | 0xE0, ((u & 0xFC0) >> 6) | 0x80, (u & 0x3F) | 0x80
            PUT #2, , CHR$((u \ 4096) OR 224)
            PUT #2, , CHR$(((u AND 4032) \ 64) OR 128)
            PUT #2, , CHR$((u AND 63) OR 128)
        END IF
    END IF
LOOP

CLOSE #1, #2
PRINT "Conversion complete. Check output.bin"

Жесть какая :) ну если ты считаешь этот код лучше, ну что я могу тут поделать)))))

Особенно хочется разбить голову об стол, когда сокращения и всякий сахар тащат в исохдники компилируемых языков

Меня напрягает когда незначащую переменную «i» цикла обзывают Tidimtidimindex и получается Array[Tidimtidimindex]