Какой нативный тип данных для строк в линукс?

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

Они некорректно работают в любой юникодной кодировке, включая utf-32. Потому, что кодировка — деталь имплементации, интересная только при написании перекодировщиков. Хочешь получить конкретный символ — вперёд, итерируй по графемным кластерам, но они ни разу не мапятся 1:1 в utf-32, поэтому разницы между utf8, utf16 и utf32 здесь никакой нет.

если сконвертируешь её в utf32 и обратно она изменится

Ядро Linux ничего не знает про кодировку

ext4 с недавнего времени умеет в регистронезависимость, поэтому в некоторых контекстах оно кодировку (utf8) всё-таки знает.

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

в ядре есть NLS, правда только однобайтовый.
В винде неграммотный подход т.к utf-16 не вмещает юникод полностью, хотя на момент принятия этого решения оно выглядело вполне адекватно, особенно с учётом 16битных регистров, а 4хбайтовый utf32 выглядел дико широким

и не только. Раздел NLS в конфиге есть весьма давно. Там можно выбрать какие кодировки ядро будет поддерживать (а nls подразумевает в том числе умение в регистронезависимость).

utf-16 вмещает юникод полностью. Точно так же, как utf-8 и utf-32. Прикладной софт не должен заморачиваться этим, пока он считает, что строка — это opaque-набор байтов, он работает с юникодом правильно. А для вещей вроде «вытащить нужный символ», «обрезать строку на Nном символе» и подобном, всё равно нужны специальные средства, которые в курсе grapheme clusters. И нет никаких проблем собрать codepoint из utf8-байтов или utf16-суррогатных пар перед тем, как собирать grapheme cluster из юникодных codepoint’ов.

только при правильном декодировании, а не как это виндузятники любят считать 2 байта одним кодпоинтом

В винде неграммотный подход … , а 4хбайтовый utf32 выглядел дико широким

Чё за чушь?

только при правильном декодировании, а не как это виндузятники любят считать 2 байта одним кодпоинтом

Чё за чушь? x2

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

In 1991, the first version of the Unicode standard was published, with code points limited to 16 bits. In the following years many systems have added support for Unicode and switched to the UCS-2 encoding. It was especially attractive for new technologies, such as the Qt framework (1992), Windows NT 3.1 (1993) and Java (1995).

Если кого и винить, то комитет стандартизации, никакого utf-32 не было и в помине…

Ну так софт, не заморачивающийся декодированием, заодно не заморачивается графемными кластерами. Поэтому он будет багнутым с любой кодировкой. Если это не какой-нибудь swift, где по дефолту всё работает правильно.

Но, например, в Python есть нативный тип строк для Linux это: b""

Только py2 уже умер, а в py3 половина стандартной библиотеки свято верит, что имя файла представимо в юникоде (и есть немного костылей, чтобы запихнуть невалидный юникод в перевариваемый остальным питоном вид). Отсюда вывод: ~100% софта на python не умеет в линуксовые файловые системы.

если сконвертируешь её в utf32 и обратно она изменится

А нахрена я буду конвертировать её в utf32 и обратно?

В винде неграммотный подход т.к utf-16 не вмещает юникод полностью, хотя на момент принятия этого решения оно выглядело вполне адекватно, особенно с учётом 16битных регистров, а 4хбайтовый utf32 выглядел дико широким

NT 3.1 была первой юникодной системой, и она работала только на 32 битных процессорах, так что аргумент - инвалид.

4-байтовый юникод выглядит дико широким даже сейчас, поскольку кушает в два раза больше памяти без какой-либо причины - я до сих пор не встречал ни одного текста в UCS-4, этот формат просто никто не использует. Да, глибсы и еще целый ряд софта, в том числе delphi/lazarus, имеют поддержку UCS-4, но используют его в качестве вспомогательного. По этой причине в глибсах весь ввод-вывод продублирован для UTF-8 и для UCS-4.
HTML5 отказалось от UTF-32.
Вика говорит, что Python использует UTF-32, но фактический код говорит, что питон использует одно-, двух-, или четырехбайтовую кодировку в зависимости от входной строки:
https://github.com/python/cpython/blob/master/Objects/unicodeobject.c#L4947
И UTF-8, как ни странно, является единственной универсальной кодировкой для строк питона, поскольку ASCII-строки совместимы с ней, а все юникодные строки по запросу создают постоянное UTF-8 представление себя:
https://github.com/python/cpython/blob/master/Include/cpython/unicodeobject.h...

И нет никаких проблем собрать codepoint из utf8-байтов или utf16-суррогатных пар перед тем, как собирать grapheme cluster из юникодных codepoint’ов

Да, зачастую UCS-4 является промежуточным представлением для обработки, а сама строка хранится в UTF-8/16. Все-таки регистры и кэши будут подешевле, чем доступ к оперативной памяти.

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

но проблема надумана.

Более того, засрали весь топ этой «грандиознейшей» «проблемой».

Только py2 уже умер, а в py3 половина стандартной библиотеки свято верит, что имя файла представимо в юникоде (и есть немного костылей, чтобы запихнуть невалидный юникод в перевариваемый остальным питоном вид). Отсюда вывод: ~100% софта на python не умеет в линуксовые файловые системы

Не вижу такого положения в коде.
https://github.com/python/cpython/blob/master/Modules/_io/_iomodule.c#L261
Здесь прокатывает и юникодная строка, и bytes, и, в итоге, любой bytes-like object, позволяя писать любой набор байтов в качестве имени файла. Ну и с верхних уровней имя файла передается неизменное. Если там где-то наверху кто-то решил, что имя файла может быть только юникодное - так тому и быть.

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

Проблема возникает, когда нужно выполнять запросы вроде «взять 124-й символ, потом взять 95-й символ», которые часто возникают при сложной обработке текста.

часто возникают при сложной обработке текста.

Насколько сложной? Сложнее TeX/LaTeX?

В винде неграммотный подход т.к utf-16 не вмещает юникод полностью, хотя на момент принятия этого решения оно выглядело вполне адекватно, особенно с учётом 16битных регистров, а 4хбайтовый utf32 выглядел дико широким

Насчет регистров уже сказали - даже первые версии NT были 32-битными.

Насчет «неграмотного подхода» - NT изначально гораздо более продуманная система. Переносимость (независимость от архитектуры) была одной из главных задач проекта. NT даже сначала разрабатывали на i860, чтобы избежать любой специфики i386, и лишь потом портировали на i386 и прочие архитектуры. Переносимы даже драйверы устройств на уровне исходного текста благодаря HAL (например, вместо того, чтобы сделать в ядре «in al, edx» драйверы вызывают соответствующую функцию HAL - READ_PORT_UCHAR).

Одной из других задач проекта была изначальная ориентация на Unicode.

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

Если уж где и «неграмотный подход», так это в Linux, в котором Unicode позже сбоку прикрутили.

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

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

Да, увы. Потому я до сих пор стараюсь использовать py2 и нативные строки которые там str, юникодовые же там unicode.

NT 3.1? Что?

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

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

а чем utf16 лучше utf-8 кроме скорости в некоторых распространённых случаях?

https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

Ну вот как мне выдрать нужную букву из слова? Пример кода приведи. С длинными символами я могу сделать просто word[n], и на выходе получить n-ю букву строки word.

А в эмодзи к примеру первый кодпойнт задаст эмодзю, второй укажет цвет кожи, третий гендер. Так что использовать utf32 и бить строку по кодпоинтам тоже нельзя - у кого-то потеряется гендер или цвет кожи и он подаст на вас в суд. Так что если это не текстовый редактур - utf-8 предпочтительнее.

И тут эта толерастия.

часто возникают при сложной обработке текста.

Насколько сложной? Сложнее TeX/LaTeX?

В них всё плохо с юникодом, поскольку они появились до появления юникода и имели костыли для отображения нестандартных символов, а позже обрели и костыли для юникода. Поэтому возникло, например, https://ru.wikipedia.org/wiki/XeTeX

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

Делать бинарное дерево из символов строки для доступа к онной? Замечательная идея.

NT 3.1? Что?

Это первый релиз линейки NT, дожившей до наших дней.

В них всё плохо с юникодом

Значит недостаточно сложно? Ещё сложнее?

С какой целью оно может понадобиться вообще?

Да элементарно в структуру данных для ренедера (нарисовать символы дугой) засунуть символ или ссылку на этот символ. Регулярочки продвинутые обрабатывать - тоже нужно уметь смотреть в строку назад. Тот же firebird, к слову, в записях резервирует 4 байта под каждый символ utf-8, независимо от фактического размера, потому что размер записи в базе фиксированный. А если 4 байта все равно в структурах резервируются, то какая разница, будешь ли ты в них писать UTF-8 или UCS-4?

Если это формат с кодовыми словами в ascii вроде какого-нибудь текстового конфига - работай с utf-8 как с ascii-совместимой кодировкой

Наследие есть наследие. Нечего правила эпохи однобайтовых кодировок переносить в 2020 год.

а чем utf16 лучше utf-8 кроме скорости в некоторых распространённых случаях?

Тем, что для большинства применений дает связь «один символ - одна ячейка». И да, эта простота в том числе повышает скорость выполнения.

https://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

Смысл этой статьи: в третьем питоне очень плохо сделаны stdin/stdout. Это так. Под виндой консольный питон вообще неюзабелен. Я до сих пор не знаю, как и почему так получилось, но это получилось. Можем считать, что питон просто некому поддерживать - это весьма недалеко от реальной ситуации.

Значит недостаточно сложно? Ещё сложнее?

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

зачем

Пытаюсь понять, что значит твоё «сложно».

устаревшего мусора

Неуверен и насчёт устаревшего, и на счёт мусора, и на счёт сложности «устаревшего мусора».

Неуверен и насчёт устаревшего, и на счёт мусора, и на счёт сложности «устаревшего мусора»

Ну, так о чем разговор? В старых проектах, где юникод не осилили, он поддерживается слабо и через костыли, которые некоторые здесь называют каноничным UTF-8. В новом XeTex используется UTF-32, и там, внезапно, порядок с юникодом.

там, внезапно, порядок с юникодом.

А где непорядок?

почему utf-8 костыль, а utf-32 нет?
В обоих случаях для выделения графической единицы придётся парсить этот юникод. если кто-то работает с не-ascii символами в utf-8 как с ascii - то вероятно и с utf32 он накосячит где-нибудь

почему

Почему, почему… Потому что это его «корова» и он её «доит»: Какой нативный тип данных для строк в линукс? (комментарий)

В файлах UTF8, в программах лучше всего хранить utf-32, а это значит что wchar нельзя, он в винде 16 бит, а те кто юзаюь его либо не пишут кроссплатформенный софт, либо любят страдать. Так что внутри программы лучше всего работать с char32_t в случае C++, а что там в голых си, я ХЗ. По логике надо long оборачивать, но зная любовь сишников к мазахизму, предположу что они любят хранить utf-8 и работать с ним через жопу.

По логике надо long оборачивать, но зная любовь сишников к мазахизму, предположу что они любят хранить utf-8 и работать с ним через жопу.

https://en.cppreference.com/w/c/string/multibyte/char32_t

а что там в голых си, я ХЗ.

Очень сложно догадаться. Надо быть Вангой в 5-м поколении. Да?

А при чём тут ядро? На ядро вообще наплевать. Оно само по себе.

TeX/LaTeX

Это те, которые без babel-а не умеют в юникод? Да?

Да?

Да.

Вот это ты меня порадовал. Я давно на сишке ничего не писал. наверное, с 2008 года не трогал её особо.

какое в ж бинарное дерево?