Локали в кодировках, отличных от UTF-8, объявлены устаревшими в Debian

wchar_t здесь таки да, четырёхбайтовыйv

Бывает ещё двухбайтовый (UTF-16).

utf-8 совершенно не пригоден для таких задач как итерация по символьная например.

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

Большинство кодировок ASCII-совместимы.

Очевидно, что речь об остальных.

КОИ-7 и ELOT 927 не предполагают сами по себе способа переключения на латиницу. ДКОИ основана на EBCDIC.

В 7-битном варианте кодировки ГОСТ-10859 вовсе нет полного набора латиницы, вместо неё использовались омоглифы из кириллицы, и ни с чем америкосовским она не совместима.

итерация по символьная

Будто UTF-32 спасает от NFD/NFC/NFKD/NFKC, ну да.

Это не спички. CPU давно застряли в развитии и прогрессируют в мощности черепашьими темпами, отчего становятся всё перегруженнее. На всём, что до сих пор вычисляется на CPU, необходимо экономить. А после отброса в развитии лет на 20 назад, связанного с выявлением класса уязвимостей в процессорных кэшах и последовавшего ухудшения производительности из-за борьбы с ним — и подавно.

Вот когда хрюникодные сопроцесоры завезут, желательно со вшитыми шрифтами — тогда и приходите, давно пора.

Скорее всего этот зоопарк никто не хочет поддерживать. Никому не нужно, вот и хочется упростить.

Смутно помню, что локали в glibc были какие-то странные, с глобальным состоянием и ещё каким-то тупняком.

Локалями должно прикладное приложение жонглировать, если ему это нужно. Это к вопросу о wine.
Кому не нужно, тех насильно заставляем поддерживать utf-8, что есть хорошо и правильно.

Вот когда со строками в программе работают чуть больше чем вывести строку на экран - работают с UTF-32, т.к. utf-8 совершенно не пригоден для таких задач как итерация по символьная например.

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

Так из glibc'а поддержку неюникодных кодировок никто не выкидывает, и их поддержка там вообще реализована как поддержка подмножеств юникода.

Тема конкретно про Debian и диалоги его тулз, которые теперь при настройке $LANG и $LC_ALL будут предлагать только UTF-8. Не более того.

Не нужна вам посимвольная итерация в 98% случаев.

С чего бы это вдруг? Строковые операции нужны везде где есть user input в том или ином виде.
Я нынче новости о любом новом супер-пупер языке начинаю читать с выяснения, как там дела с utf-8 слайсами по глифам и регулярками.

снимают фото в 64M

В 400.

Строковые операции нужны везде где есть user input в том или ином виде.

В 98% случаев достаточно операций с ноль-терминированными цепочками байт. Как там эти байты делятся на символы знать не обязательно. В качестве самих символов и их поиска тоже использовать исключительно строки.

В 98% случаев достаточно операций с ноль-терминированными цепочками байт. Как там эти байты делятся на символы знать не обязательно. В качестве самих символов и их поиска тоже использовать исключительно строки.

Стандартные библиотеки языков последние лет 10-15 почему-то не согласны с таким подходом.
Вроде очевидно же, почему.

Стандартные библиотеки языков последние лет 10-15 почему-то не согласны с таким подходом.

Что-то не заметно. Нуль-терминированные строки и strcpy/strcat/sprintf/std::string всё ещё на месте.

Вроде очевидно же, почему.

Мне не очевидно. Рассказывайте.

Не нужна вам посимвольная итерация в 98% случаев.

Да шо ты говоришь!

А вот давай, скажи, как элементарно в хрюникоде без говнолиб измерить длину строки? Чтобы знать, например, сколько места на дисплее с моноширинным шрифтом нужно под нее выделить?

В КОИ8-Р я пишу просто:

int strlen(char *str){
  if(!str) return 0;
  int i = 0;
  for(; *str; ++str);
  return i;
}

Жду такой же простой пример для хрюникода (повторю еще раз: без говнолиб!)…

А вот давай, скажи, как элементарно в хрюникоде без говнолиб измерить длину строки?

ЗАЧЕМ?

Чтобы знать, например, сколько места на дисплее с моноширинным шрифтом нужно под нее выделить?

Консольная псевдографика не нужна вместе с КОИ8-Р. Времена DOS прошли, сейчас у всех графические мониторы и видеокарты.

Времена DOS прошли, сейчас у всех графические мониторы и видеокарты.

Когда будешь идти по улице, обрати внимание на светодиодные индикаторы. И подумай, нужен ли им хрюникод!

И да, элементарно в терминале у тебя что - не моноширинный шрифт? Ну ты, батенька, и извращенец!!!

А как же у тебя mc кажет-то?

Когда будешь идти по улице, обрати внимание на светодиодные индикаторы.

Обратил. Там есть шрифты с переменной шириной символов и даже сглаживание есть. Прогресс уже и сюда дошёл.

И да, элементарно в терминале у тебя что - не моноширинный шрифт?

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

А как же у тебя mc кажет-то?

Никак. Не нужный артефакт времён DOS.

Помните: пользователи mc и прочих двухпанельных менеджеров – виндузятники, потому что это из DOS пришло. В UNIX’ах такого не было.

Ну, если тебе двухпанельники не нужны, то ССЗБ. Время прилично экономится при помощи того же mc!

И да, вот ты и просрался: в консоли у тебя все-таки моноширинный шрифт! И чтобы символы не вылезали за пределы видимости, нужно делать переносы. И для этого необходимо знать ширину строки. Вот и напиши мне, как ты будешь строчку выводить, чтобы в 40 символов уложиться, без ncurses?

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

Терминал это сам делает. И даже автоматически обновляет переносы при изменении ширины окна. Зачем городить велосипед?

чтобы в 40 символов уложиться

Что за странное ограничение?

хоть аппаратно ускорено, а обработка текста до сих пор нет

4.2

Что за странное ограничение?

Например, таблицу отобразитиь кошерненько. Не будь узколобым! Быстро определить количество символов в строке — достаточно востребованная операция! И в нормальных кодировках эта длина равна количеству байт в строке (ну или N*количество байт, как в UTF32). А в кодировках, придуманных мудаками, эта длина определяется из контекста, как в UTF8!

Например, таблицу отобразитиь кошерненько.

Отображать таблицу в консоли – это забивать гвозди микроскопом. Консоль для этого не предназначена.

Быстро определить количество символов в строке — достаточно востребованная операция!

Нет. При стандартном использовании это совершенно не нужная операция. Она нужна разве что в недрах тулкитов.

Консоль для этого не предназначена.

Ни хрена-то ты не понимаешь в этой жизни!

При стандартном использовании это совершенно не нужная операция

Вот же «зумеры» вредные пошли: учишь их, учишь, а они так тупыми и помрут!..

Оставьте уже этот DOS при себе. Понимаю: тяжёлое детство, деревянные игрушки. К комфорту не приучены.

Без консоли линукс превращается в плохую винду. Вся мощь линуксов раскрывается именно через консоль.

Если ты боишься консоли, то тебе явно в мастдайку нужно.

А если ты еще и сидишь не на линуксе, а на бубунте или другом systemd/linux, то и подавно!

Не нужный артефакт времён DOS.

Файловые менеджеры для слабаков, да. Они не нужны тем, кто юзают cp, mv, rm,... и т.д.

Я не против консоли. Я против псевдографики в стиле DOS.

Ты, похоже, ни разу не смотрел выхлоп hexdump и т.п.?

Отображаемая длина строки нужна далеко не только для форматирования выхлопа в консоли (внезапно посмотри на выхлоп того-же dnf) но и для гуев, особенно сложных.
А вообще не юникодные локали до сих пор во всю используются в эмбеддедах ибо в текстовых протоколах Юникод никому вообще не всрался и реализовывать его на мк ну совсем никому не нужно. И да, там иногда нужна кириллица :-)

но и для гуев, особенно сложных.

Для GUI нужна длина в пикселях, а не символах. Для этого есть готовая функция вроде float StringWidth(const char* string). Количество символов в строке не нужно.

А вообще не юникодные локали до сих пор во всю используются в эмбеддедах

Этот embedded постепенно вымирает потому что даже на дешёвых микроконтроллерах ARM продаваемых на развес можно запустить полноценный Линукс. Микроконтроллеры с килобайтами памяти для мазохистов, для показа интерфейсов уж точно.

Там длина строки в символах не нужна.

На дворе 2021. Все пользователи хотят utf-8, все разработчики не хотят сношаться с деталями реализации.
Заталкивание zero-day реализации в стандартную библиотеку делает всех счастливыми.

все разработчики не хотят сношаться с деталями реализации.

А и не надо. Передавайте строки char[] не заморачиваясь как они устроены. Зачем вам посимвольный доступ?

Пора на UTF-32 это представление переводить, а то там смайлики не лезут порой как надо

Не влезут смайлы в UTF-32. Там один смайл может состоять из нескольких символов-модификаторов пола, цвета кожи, комбинаций и т.д..

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

Тебе определенно нужно либо учиться, либо лечиться! Но с таким пустым мозгом жить дальше не стоит!!!

Шёл 2021 год…

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

X512, алгоритмы бывают разные.
Хорошие и ресурсов мало потребляют и эффективны.
Почему вэб стал таким неповоротливым?

Страница с пятью строчками зачастую у многих горе разработчиков весит 3MB ...

Это обширнейшая тема.
И она в большей части затрагивает не программирование, а психологию людей …

Эшо …

Что касаемо существующих кодировок, то скорее всего их отвратительная архитектура тянется из далекого прошлого.

UNICODE ИМХО пытается навязать стандарты использования не только кодировок …

Кому не нужно, тех насильно заставляем поддерживать utf-8, что есть хорошо и правильно.

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

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

Кому не нужно, тех насильно заставляем поддерживать utf-8, что есть хорошо и правильно.

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

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

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

Да, если экосистема языка мешается, вместо того, чтобы помогать.

к тому же такой код медленнее работает

Да. Но это небольшая часть рантайма, никто не заметит.

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

Если взять тот же python, то там манипуляции со строками медленные вовсе не из-за utf-8.
Тем не менее полмира на этом пишет: статус utf-8 как first class citizen важнее производительности почти для всех.

Тем не менее полмира на этом пишет: статус utf-8 как first class citizen важнее производительности почти для. всех.

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

То есть кодировок надо две, для окошек utf, а для внутренностей программ и вывода в консоль однобайтную кодировку, всё равно там всё будет на английском.

Тем не менее полмира на этом пишет: статус utf-8 как first class citizen важнее производительности почти для. всех.

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

То есть кодировок надо две, для окошек utf, а для внутренностей программ и вывода в консоль однобайтную кодировку, всё равно там всё будет на английском.

Влезут. По крайней мере графемы из которых состоят смайлы влезут, а вот в utf-16 не всё физически влезает, а только половина. Сейчас из-за него просто ограничили остальные версии юникода, вроде UTF-8 забивая его только на половину. Но это не будет длиться вечно, рано или поздно весь юникод заполнят под завязку.