Фидошники в эхе PUSHKIN.LOCAL активно обсуждают юникод

Ибо стандартная виндовая консоль оного уникода не умеет.

4.2. Любая win2k+ виндовая консоль умеет в utf-16. То, что она умеет ешё м backwards compatibility с чем-то в духе cp866 не значит, что она неюникодна.

А уж если у юзера в шрифте всего 256 символов

Как в шрифтах под линуксовую ядерную фреймбуферную консоль? Но она юникодна! Потому, что

то от юникода у него не будет совсем никаких профитов

4.2. Профит — в том, что японокитайцам не потребуется переписывать софт буквально с нуля. А они могут контрибьютить в опенсорс.

С UTF-32 проще внутренности программ которые с ней работают. Ткни в произвольный байт массива и без больших вычислений известно, в каком месте символа он находится

Не символа, а codepoint'а. Только юзеры под символами понимают «глифы» (и когда backspace удаляет лишь половину от глифа, юзеры сильно удивляются, зачем они поставили этот багнутый софт). Поэтому все преимущества utf-32 летят в трубу: тебе всё равно нужно проводить вычисления.

Нормальные люди разные. Одни юзают графические среды и векторные шрифты с юникодом, а другие - ядерную консоль с растровыми шрифтами в 256 символов.

Но она юникодна!

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

Профит — в том, что японокитайцам не потребуется переписывать софт буквально с нуля. А они могут контрибьютить в опенсорс.

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

другие - ядерную консоль с растровыми шрифтами в 256 символов.

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

Нет. У разных людей разные задачи. И если для решения задач ядерной консоли более чем достаточно, то юзать её удобнее чем сидеть в графических средах.

Ну так в линуксовой изкоробочной консоли нет квадратиков и есть юникод, в чём проблема?

Нет. У разных людей разные задачи. И если для решения задач ядерной консоли более чем достаточно, то юзать её удобнее чем сидеть в графических средах.

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

Нет. Ядерная консоль на десктопе нужна для тех же задач, что и другие эмуляторы терминала. И это не только юзание CLI и TUI софта, а и запуск графического софта, включая видеопроигрыватели, просмотрщики, игры и эмуляторы. И есть юзеры, которые, не заморачиваясь с ядерной консолью, юзают на десктопе TWM/FVWM + xterm. Но, это может быть гораздо менее удобно. Не говоря уже о том, что xterm не умеет работать так красиво, как работает ядерная консоль.

Не символа, а codepoint'а.

В русском языке такого слова нет. Как говоила медичка из анекдота: выражайтесь по медицински - это не п___е а половая щель!

(и когда backspace удаляет лишь половину от глифа, юзеры сильно удивляются, зачем они поставили этот багнутый софт)

Это если в текстовом редакторе побайтно редактировать, а если посимвольно, то такого не будет. За исключением случаев, когда имеем текст, которого нет на клавиатуре.

побайтно редактировать

Не обязательно. Достаточно не учитывать модификаторы. Или учитывать, но криво.

Это если в текстовом редакторе побайтно редактировать, а если посимвольно, то такого не будет.

https://en.wikipedia.org/wiki/Combining_character Получите и распишитесь. Это даже без корейского, который целиком может писаться комбинирующими символами и без эмодзи, которые в последнее время любят комбинировать из модификаций (вроде «белый» + «женщина», не говоря о вообще всех эмодзи-флагах стран).

Все эти вещи продолжают быть комбинирующими даже в UTF-32. Многие остаются разбитыми на N «символов» (codepoint'ов) даже после нормализации ибо нормализованного варианта не существует.

В русском языке такого слова нет.

Оно есть в спеке юникода, этого достаточно.

Оно есть в спеке юникода, этого достаточно.

Напишите нормальный спек для четырёхбайтной кодировки. Почему подстраиваясь под гуано, нужно кричать какое оно нормальное и прогрессивное?

Юникод уже достаточно нормален. Но он сложен поскольку естественные языки — кошмар.

К счастью, в некоторых языках вроде swift'а уже начали запрещать нубские ошибки вроде «Ткни в произвольный байт массива»: запрещено брать «символ» из строки по произвольному integer-смещению и длина строки по умолчанию измеряется в глифах, а не в байтах/utf32-codepoint'ах. И да, это делается с очень специальным типом строк.

Юникод уже достаточно нормален. Но он сложен поскольку естественные языки — кошмар.

Ничего он не нормален, буквы нормальные прописать не могут, хотя утф-8 жрёт на их запись до 4 байтов и всё равно их не хватает, потому что просирает биты в каждом(!) байте на совместимость с буржуйской кодировкой. А при фиксированной четырёхбайтной кодировке, просирать ничего не надо, нужно лишь определить что в байтох старше первого буржуйских букв быть не может.

К счастью, в некоторых языках вроде swift'а уже начали запрещать нубские ошибки вроде «Ткни в произвольный байт массива»: запрещено брать «символ» из строки по произвольному integer-смещению и длина строки по умолчанию измеряется в глифах, а не в байтах/utf32-codepoint'ах. И да, это делается с очень специальным типом строк.

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

UTF-32 - не четырёхбайтная кодировка. Да, один codepoint там 4 байта. Но, на одно знакоместо codepoint'ы склеиваются модификаторами. Не говоря уже о том, что «длинные юникодные последовательности» не так уж и зависят от того, какова N в UTF-N, и занимают очень много байт и в UTF-8 для того, что выводится на одно знакоместо.

Значит нужен новый юникод, не совместимый с имеющимися, но не просирающий так бездарно биты. Глянул в педивикию, это же дурдом. В многобайтных символах первый байт занимается под «таблицу размещения файлов» весь, а от всех остальных откусывается по 2 бита. То есть в четырёхбайтном символе, на запись символов используется 6х3=18 битов при 32 затраченных! Сплошные откаты, попилы и «эффективные менеджеры». Ничего удивительного, что при таких попилах 4 байт уже мало - давайте 8-12 не меняя кодировки!

Если делать 4-5 байтную кодировку по уму, то надо делать фиксированную длину байтов и под «таблицу размещения файлов» выделить по 1 биту в каждом байте. Пусть старший бит везде будет 0, а в последнем бите 1, тогда, если станем читать обрезанный массив, то побьются только крайние символы, а остальные с лёгкостью декодируются. Тогда в четырёхбайтной кодировке символы можно писать в 7х4=28 битах, а в 5 байтной в 7х5=35 битах что есть много. На большинство глифов в такой кодировке можно плевать - буков много чтобы сразу одним символом писать как надо, а те несколько дополнительных закорючек, что кому-то так нужны можно писать посимвольно несколькими способами. Так как теперь, это понадобится для подготовки печати на бумагу, и с обозначением занимаемого байта маленьким узким хренделябриком. По количеству хренделябриков можно сосчитать сколько невидимых символов тут присутствует.