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

с экономией двух байт.

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

Если Арбуз написать например в CP866 то именно так и будет - сами коды символов указывают на то что они русские. А вот если в юникоде - то будет в частности не конкретное «russian capital letter A», а достаточно безликое cyrillic, которое может быть любым славянским где кириллицу употребляют.

Если бы сходство было 95% я бы согласился на совмещение, а если 5%, то какой смысл совмещать две буквы из разных языков? Автор шрифта вполне может для кириллических языков сделать отличие в написании, а в редакторе текста сделать подсветку. Если вы смешаете две буквы «а» и «с», то потом из-за экономии двух байт вам потом выльется в масштабную проблему. Наверно с «ё» так и получилось, её по каким то причинам вынесли за пределы алфавита и если можно было бы сортировать по алфавиту просто используя возрастающий код букв, то слова с буквой «ё» просто выпадут из этого списка.

Вот пример русского и болгарского

Болгарская кириллица - отдельный сет в юникоде? (комментарий)

Если они там будут экспериментировать, нам что, каждый год переписывать UTF-8? Так то он и так обновляется раз в год, но мы теперь будем для каждого языка/страны создавать начертания местного дизайнера? Если что русский язык входит в число языков международного общения. Некоторые страны заявляют что хотят перейти на латиницу. Мы для них выделим раздел, а они с него спрыгнут. Я может тоже недоволен, хочу чтобы кириллица была внутри первых 127 байт, давай исполняй.
Есть предположение, что 32 буквы выглядят символично, можно закодировать букву 32-х битным числом, а лишняя буква сломала бы эту возможность и потребовала следующий байт, второй в 32-хбитной шине.

каждый год переписывать UTF-8?

Уверен что это придется делать еще очень-очень много раз и много лет. Потому что стандартизация языков - еще далеко не завершенный процесс.

Уверен там не трогают начало, погуглил, добавляются эмодзи в конец. Как я понимаю устоявшуюся часть никогда не поменяют, так как это приведёт к слому программ.

Чел объясни. Накуа? Чтоб с ходу впороться в ад разработки?

Что достигается этой кодировкой если дальше надо делать редактор.

Я ведь свой редактор делаю не потому что я придурок или не осилил QCodeEditor. А потому что оказалось что по коду должен лазать парсер. Причем быстро и интегрируемо

Чел объясни. Накуа? Чтоб с ходу впороться в ад разработки?

1. Так я с тобой согласен, а не с автором и придуманными кодировками. Это мы помечтали как бы мог выглядеть UTF-8 в других обстоятельствах.
2. Автор толком не объяснил что делает, как из этого решить правильно это или нет. Лично у меня уже написан мной инструмент для вставки сниппетов, и не требует сервера. Этот функционал можно ведь написать по разному, один человек сделал это в виде «поиск», выпадает окно, в нём ищутся введённые слова по базе слов, но я сделал при вводе слова в IDE полностью или частью вызываю хоткей левая часть от курсора захватывается как элемент поиска и выводит 6 столбцов (задаётся автором, хоть 3, хоть 8) и в каждом столбе происходит работа фильтра; в начале базы (текстовый список) указаны правила в нескольких строках, как искать, как подсветить, как вставить, заголовки столбцов. И у меня даже к своему варианту есть претензии, например добавить флаг подсветить искомое внутри найденных слов, а также отсутствует автоматический фильтр при вводе.

Он упоротый. Можно было долго не писать просто он упоротый. Печаль беда

Автор толком не объяснил что делает

Автор всё объяснил. Могу ещё раз даже объяснить, что в БД выгоднее хранить 1 байт на кирилицу, а не два для русскоязычного контента. На ваших песочницах оно может и не заметно почему. А на огромных базах данных это серьёзный выигрыш.

Да с хера ли выгодно. Ты что нракомн который гигабайты кода лопатит?

В реальности выгодно не тормозить.

А если у тебя проблема с кириллицей в БД то либо у тебя комментов на русском больше чем кода либо ты писатель на православном языке программирования с ятями и иконами

Да он упоротый. Я его лет 10 назад здесь видел и он нес совершенно изумительную херню

Кроме визуального представления юникода может быть ещё и звуковое (голос). Понятно, что там сложность для его рендеринга ещё большая, но программы для него - т.е. для озвучивания - могут использовать принадлежность к скрипту для того что бы отличать, как произносить слова на разных языках. Понятно, что языки на латинице так не распознаешь, но это проблемы тех, кто принял латиницу для этих языков.

К примеру, RHVoice обрабатывает ударения в кириллическом тексте

Тут конечно отдельный вопрос: стоило ли делать из юникода язык разметки (пресловутые bidi, оттенки кожи и т.п.)…

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

Залезь в исходники PostgreSQL, посмотри на реализацию поиска по кодировкам с диакритическими знаками.

В реальности выгодно не тормозить.

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

А если у тебя проблема с кириллицей в БД то либо у тебя комментов на русском больше чем кода

БД, содержащая много текстовых полей на русском - вовсе не редкость. И раздувать ее вдвое из-за этого - не слишком хорошее техническое решение.

Кстати, правительство не так давно озаботилось единообразием перевода имен и фамилий иностранцев в кириллическое написание для использования в внутрироссийских документах: https://www.interfax.ru/russia/990562 Причем это носит официальный характер, есть соответствующее постановление. Так что для внутрироссийского документооборота какие-то сильно экзотические алфавиты не нужны.

Кроме визуального представления юникода может быть ещё и звуковое (голос).

Это всё же не имеет прямого отношения к символам алфавитов, которыми оперирует юникод. Ибо например в словосочетании «Pacific ocean» все три буквы «с» читаются по-разному. И это я еще французский не знаю с его кучей «лишних» букв в словах - марка Peugeot как пример.

Лингвистический анекдот на тему написания и произношения: https://www.reddit.com/r/russian/comments/tblqg3/my_favorite_russian_linguistic_anecdote/?tl=ru

Залезь в исходники PostgreSQL, посмотри на реализацию поиска по кодировкам с диакритическими знаками.

Это задача для чатгпт, для Ъ мог бы и ссылку на ответ сбросить.

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

И теперь у нас есть греческая ω, латинская ꞷ и кириллическая ѡ. Смотри не перепутай.

в части двубайтовой кодировки символов, которые вполне раньше были

шестибитовыми, а то и вообще недвоичными

IBM же свой DOS так называет

Который VSE?

Microsoft первые Windows™ называла «operating environment»

в легаси кодировках Windows-CP125x

А что с легпси Windows-CP936?

Ни одной дельной мысли.
«Вода, вода. Кругом вода.».

Китайцы себе пусть алфавит придумают - будет им тогда однобайтовая кодировка. А так пусть проходят на два байта об асфальт.

чушь несусветная. Вот есть, например, турецкий язык с буквами Iı(ы) и İi(и). Чо как, латиницей писать «ы» заглавную и «и» строчную? А для остальных свои символы придумывать?

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

А какая разница, если у него в разных языках одинаковые символы будут иметь одинаковый код? Получается что код от языка как раз не зависит

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

Пфф.. Сделаем 11-битный байт! :)

А какая разница, если у него в разных языках одинаковые символы будут иметь одинаковый код?

Они уже имеют. Символ a одинаков хоть в английском, хоть в немецком, хоть в испанском, хоть во вьетнамском, хоть в сербском. В любой из кодировок.

Аналогично, например, с символом ш. Он тоже одинаков хоть в русском, хоть в украинском, хоть в казахском, хоть в монгольском, хоть в сербском.

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

Чем UTF-16 не устроил? Похоже, что вы пытаетесь его переизобрести.

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

Странные желания у вас. Это разные буквы, которые могут еще и по-разному выглядеть в одном шрифте. «Одинковых» букв в разных письменностях не может быть по определению.

И возникает вопрос - где кончаются собственно буквы и начинаются картинки?

Древние Египтяне такие: а что, есть разница?

https://habr.com/ru/articles/1085164/ ? очередной велосипед в виде CL-8

Любопытно, 3 недели назад первый коммит, у меня пост 3 недели назад. Матрица шутить изволит )

У меня проще и больше совместимости https://github.com/foror/survik

Для Ъ https://github.com/rostislavnagimov/cl-8

Поэтому идея сделать кодировку, где первый байт (в самой строке) определяет тип кодирования. Если это языки, которые в легаси кодировках могли в 1 байт, то в первом байте будет об этом указано.

А классический всегда 16-разрядный юникод UCS-2 (не путать с UTF16) тебе не подойдёт? Его сами юникодовцы объявили устаревшим, но лучше, возможно, такое «устаревшее», чем совсем с нуля что-то делать?..

UTF-8 гениален. Ничего лучше придумать просто невозможно.

Невозможно придумать ничего лучше, чем кодировка, в которой одни алфавиты равнее, чем другие? Серьёзно?

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

Чтобы linux.org.ru всегда был linux.org.ru и не приходилось путать его с linux.оrg.ru. Других идей у меня нет.

P.S. Вообще, обсуждение удручает замшелостью и ретроградством. Пережёвываете идеи из 60-х. Одно и то же. Вот вам новая и революционная мысль: нужен язык для черепашки. Код этого языка и определяет символ. Автоматически одинаковые символы кодируются одинаково, доступны к записи все существующие и несуществующие иероглифы и типы начертаний слева направо, справа налево, сверху вниз, по-спирали и по-всякому.

man UTF-16/UTF-32.

UCS-2/UTF-32 FTFY

UTF-16 - тоже с символами переменной длины.

ну нафиг винда xp достала:

когда ru язык копирует в буффер клиборда cp1251 строку

когда en копирует unicode

пол года на выяснение что раскладка влияет у меня ушло

Есть такая штука - Unicode compression. По моему ты ее переизобретаешь.

Автоматически одинаковые символы кодируются одинаково

Для одинаковости кодирования визуально одинаковых рисунков
надо стандартизировать направления и порядок рисования.
Китайцы, кстати, так и сделали (не знаю как, вы расскажите).

в БД выгоднее хранить 1 байт на кирилицу

Зачем байт, если есть сжимающие кодирования? Хаффман позволяет даже индексировать пожатое, потому что у него символы заканчиваются всегда на границах битов. С арифметическим так не получится. И в мире разрабатываются алгоритмы и поиска в тексте пожатом хафменом, и обработки такого текста в пожатом же виде.

надо стандартизировать направления и порядок рисования.

Сложно. Лучше нарисовать и сравнить, что получилось. Единственная трудность тут, определиться что значит «визуально одинаковый».

Хаффман

Так это для каждого текста свою кодировку придётся выдумывать. Что, в принципе, можно, но не в качестве общего решения.

Всё уже давно придумано за тебя. Хочешь O(1) в ОЗУ хранишь строки в UTF-16 или вообще UTF-32, а UTF-8 только при вводе выводе.

Тексты где есть символы за пределами ASCII (то есть это художественный текст, а не какой-то датасет в JSON) практически никогда не являются бутылочным горлышком производительности и памяти, поэтому можно конвертировать без проблем. Люди просто не пишут такие длинные тексты.

это для каждого текста свою кодировку придётся выдумывать.

Не обязательно. Возьми корпус текстов, построй кодировку по нему, затем используй.

Возьми корпус текстов

Каких текстов? Для каждой задачи релевантный корпус текстов будет разный. Таким образом задача сведена к предыдущей.