Обдумываю концепцию новой кодировки

Сперва надо определиться с алфавитом, размером алфавита. Потом можно подумать над отображением (однозначным?) алфавита на числа (вещественные?), то есть кодированием.

Даёшь каждому символу по uuid, ну, или sha512 хеш от svg с изображением символа.

Алфавит весь давно задан в легаси кодировках Windows-CP125x

хотел создать свой ЯП

пришлось придумывать свою кодировку

ясно.

А не проще использовать в таких случаях однобайтные кодировки, раз критично отсутствие перехода за O(1) по произвольному индексу? И сделать костыль, чтобы текст конвертился в другую кодировку при смене языка в твоей программе например.

Я ещё потом ОС и по возможности процессор запроектирую, ну или уже в другой жизни.

man UTF-16/UTF-32.

А так я в прежние времена предлагал придумать KOI32 без модификаторов (каждый символ - 4 байта).

Ты не кодировку пытаешься выдумать, а формат строк. А дальше у тебя будет ASCII, UTF-16 или UTF-32, в зависимости от тега.

Только это всё равно не поможет. Юникод не от хорошей жизни выдумали.

А если винегрет из символов? Тогда нужно в UTF-8 или UTF-16 конвертить и работать с этой хренью затем…

Ну так собери общий алфавит и пронумеруй. И, да, не забудь добавить символ евро и беременного Арнольда Шварценеггера.

А если винегрет из символов?

Задать ограничение на ввод, чтобы нельзя было ввести винигрет. Например чтобы для ввода были доступны только символы из текущей кодировки. А если таки попал винигрет, то прописать обработку исключений, чтобы программа падала с ошибкой

не от хорошей жизни выдумали

Чтобы появилась возможность задавать цвет кожи беременного Арнольда на иконке?

у мамы великий проектировщик вырос! у тебя фамилия случаем не Толстой?

Ага. Только это побочный эффект от возможности склейки символов. Ты можешь склеить что угодно с чем угодно и добавить поддержку соответствующей комбинации в свой шрифт. Например, тебе ничего не мешает на комбинацию 🍆+ZWJ+🧔‍♂️+ZWJ+🍑 повесить картинку с пассивным геем.

Обдумывай. Мы не против. :⁠-⁠D

...процессор запроектирую...

Жениться вам нужно, барин.

Ну всё, пора закапывать UTF-8.

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

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

Что по сортировке?

1. Зачем нужен язык, который нельзя вписать в существующую архитектуру?
2. Иногда в языке появляется необходимость поставить, например, ударение. Как решать будем? По новому символу для каждого варианта или придумаем спец. символ и склейку?
3. Выравнивать код по размеру (например,4 байта), это что, js библиотеки ещё в два раза толще станут?

Сама по себе идея придумать кодировку как таковую не сказать, чтобы плохой была. Но исключительно в академическом смысле, к ЯП это дело точно привязывать не надо. И вряд ли получится сильно лучше, чем есть то, что сейчас. Ибо не просто так к такому варианту пришли.

По сортировке очевидно тоже что и везде - для сортировки нужно задать алфавит этой сортировки.

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

Hа кaкoм языке нaпиcанa этa фразa?

Совсем нет вариантов??

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

Юникод так и делает. И это вызывает кучу проблем, потому что теперь для рендера надо знать локаль, под которую рендерить.

где первый байт (в самой строке) определяет тип кодирования

А хватит одного байта?

$ iconv -l | wc -l
1180

Не очень понимаю о чём вы, но две буквы на клавише «С» (Це и Эс) по-прежнему имеют разные коды, а я хочу чтобы одинаковый.

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

Оно и сейчас так. Буква a, или b или там z имеет одинаковый код хоть в английском, хоть в немецком, хоть в польском, хоть в каком-нибудь вообще вьетнамском. Или в сербском.

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

Буквы, рисунок которых в кириллице похож на аналоги к греческом или латинице — не одинаковые. Равно как и ноль не одинаков с буквой О. А от языка это вообще не зависит.

Ты допускаешь ту же ошибку что и авторы утф8, смешиваешь кодировку и формат хранения строки.

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

Можешь почитать вот сюда: https://tonsky.me/blog/unicode/

А хватит одного байта?

Там же тип кодирования, а не перечисления всех языков. От 0 до 8 задаём однобайтовое кодирование алфавитов Windows-CP125x. Ещё потребуется пару бит задающие тип строки:

• Строка может быть чисто однобайтовая по типу Windows-CP1251
• Может быть смешанной, когда кирилица кодируется одним байтом, а латиница и все остальные двумя или четырьмя байтами. Или наоборот латиница одним байтом, а все остальные большим количеством.
• Выровненная кода все символы кодируются 2 байтами (или 4-мя)

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

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

Спасибо тебе!

Спасибо тебе за то, что ты не проектируешь кодировки!

утф8, смешиваешь кодировку и формат хранения строки

Так, а что делать? Ваши предложения?

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

Идеи душевнобольных.

возможности склейки символов

Ну, как вариант можно добавить склейку как расширение данной кодировки. Но здесь я не вникал. Пару бит в заголовке можно зарезервировать на этот случай.

Не за что! Всегда рад помочь!

Зачем нужен язык, который нельзя вписать в существующую архитектуру?

Почему нельзя? UTF-8 в нём будет, но основной формат строк будет моим. К данному ЯП потом и ОС запилю для решения насущных задач.

По новому символу для каждого варианта или придумаем спец. символ и склейку?

Здесь я пока не знаю. Склонялся к первому варианту.

Выравнивать код по размеру (например,4 байта), это что, js библиотеки ещё в два раза толще станут?

Нет. Ваш код даже может стать меньше, потому что европейские алфавиты будут кодироваться одним байтом. В крайнем случае останется таким же как в UTF-8

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

Так закодировать каждую конкретную склейку двумя байтами, не? В чём минусы?

просто храни все символы как uint32_t, также предусмотри функции (де)кодирования в/из utf-8. Не надо ничего придумывать.

Я бы тогда новый ЯП не проектировал, а оставался пограмить на джаве

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

Можно сделать двумерные UTF-8 строки - первый ряд всегда заполнен и хранит первый байт UTF-8 последовательности, следующие ряды хранят следующие байты.

Например, «123 Строка» будет хранится как

31 32 33 20 d0 d1 d1 d0 d0 d0 
            a1 82 80 be ba b0

Для ASCII строк достаточно хранить только первый ряд, а память для остальных рядов выделять только при наличии символов вне ASCII.

Поучаем доступ к символу за O(1), и экономию памяти по сравнению с UTF-32 при работе с 1-2 байтовыми символами, но на больших строках теряем в локальности памяти при последовательном переборе.

рани все символы как uint32_t

А вот разыменование конретного символа можно в 32 бита запихивать. Точнее 24 бита, 8 бит заголовочными будут.

Кажется, что необходимость передать куда-то буфер со строкой требуется гораздо чаще, чем доступ за O(1).

не нравится отсутствие перехода за O(1) по произвольному индексу

А вот где он тебе может понадобиться? Алгоритмам поиска подстроки нужен только forward iterator (фактически O(1)) и иногда backward iterator (амортизированное O(1)). Какую практическую задачу решает произвольный доступ?

Выбираешь сколько байтов на символ у тебя будет. Можно подумать о возможных оптимизациях и сделать чтобы наиболее распространенные языки укладывались в 2 байта например.

Дальше решаешь, что все действия с твоей строкой можно делать так словно в ней всегда нужное число байтов на символ.

Дальше пишешь библиотеку для работы с ней, которая например может поддерживать сжатие. Условно к каждой строке ты лепишь структурку с номером символа числом байт на символ после него. Тогда получение ЭНого символа это не бездумный перебор, а часто взятие нужной позиции в массиве.

Или кто-то окажется ещё умнее и придумает более адекватный способ сжатия.

Не страдай херней. С новой кодировкой тебе новый редактор понадобится. А там может оказаться что проще влепить 32 бита на char, часть битов на классификацию charов отдать - скобка там, точка буква цифра, часть бит на стиль подсветки и пару на подчеркивание ошибок. Я так например делаю из-за всратости всяких qcodeedit.

И это очень скажем так жопораздирающее занятие. Кодировка для тебя будет мелочью в сравнении с всем тем что придётся делать вслед за ней

Так редактор будет продолжением ЯП, они будут одним целым. Так что не аргумент.

Как-то не задумывался. И правда, а где нужен доступ по произвольному индексу?

С другой стороны выровенные символы проще simd сканировать. Или допустим на не проиндексированных текстовых данных делать бинарный поиск в многопотоке. Разбить по середине и т.д. и на потоки раскидывать куски.