Будущее за UTF-8?

digger> Он - не фиксированной длины.
Как-то ты читаешь интересно. Элементы фиксированной длины. Не массив. И ещё раз — есть три длины:
1. Сколько занимает в памяти байтов.
2. Сколько элементов (символов) в тексте.
3. Количество знакомест в терминах глифов на экране.

В случае ASCII 1 и 2 совпадают, а 1, 2 не совпадают с 3.
В случае UTF-8 и использовании его не только, как схемы кодирования, а и, как формы (что неверно в принципе, поэтому в UNIX-е хорошим тоном считается переводить UTF-8 схему в wchar_t (можно сказать, что в UTF-32, но без BOM, работать с текстом, а потом переводить обратно) приводит к тому, что 1, 2, 3 полностью разные, и очень трудно из 1 получить 2 и обратно.
В случае использования wchar_t, 1 получается, как sizeof( wchar_t ) * ( длина в символах ). Это учитывает и те глифы, которые не занимают отдельного знакоместа на экране. А вот 3, как было раньше, так и остаётся необходимостью полного просмотра текста и отниманием/добавлением к длине 2.

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

digger> 2) не имеет физического смысла,кроме количества символов,посланных некоему абстрактному древнему принтеру,поскольку не участвует ни в каких вычислениях и не отображается на экране.

Имеет. Тот же символ новой строки отрабатывается почти всеми. Даже форматирование заголовка в табличках ворда и экселя имеет свой, так называемый мягкий перевод строки.

>>Достаточно сложно искать в строках с UTF-8 кодированием.
digger> Oсобенно задом наперед.Или есть хороший алгоритм парсинга предыдущей буквы?

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

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

>UTF-8 это транспортный протокол
Так ведь речь о том,что все протоколы - фактически переменной длины на логическую букву,в том числе UTF-32.Или мы чего-то не кодируем,или переменная длина и последовательный парсинг,а не индексирование каждой буквы.

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

Ты как-то упускаешь из виду, что управляющие символы — тоже символы. И они входят в длину строки.

digger> Так ведь речь о том,что все протоколы - фактически переменной длины на логическую букву,в том числе UTF-32.Или мы чего-то не кодируем,или переменная длина и последовательный парсинг,а не индексирование каждой буквы.
Здес ты просто не прав. Буква и отображение буквы суть две несвязанные вещи. Чтобы было понятней подумай о пропорциональных фонтах и фонтах фиксированной ширины. Это немножко совсем экстрим, но станет понятней, почему нельзя смешивать длину в символах и длину того, что показывается на экране.

Имеется в виду не изображение,а логическая буква как единица замены, матча итп. Это должно рабитать как будто это одна буква,иначе неудобно.Вопрос.Как работает charAt() на букве,состоящей из 2-х символов и что он возвращает,если значение не влазит в wchar_t ,например буква 'й' ,корейские,огласовки и им подобные? "буй".charAt(2) чему равно? А "буй".charAt(3)?

digger> Имеется в виду не изображение,а логическая буква как единица замены, матча итп. Это должно рабитать как будто это одна буква,иначе неудобно.Вопрос.Как работает charAt() на букве,состоящей из 2-х символов и что он возвращает,если значение не влазит в wchar_t ,например буква 'й' ,корейские,огласовки и им подобные? "буй".charAt(2) чему равно? А "буй".charAt(3)?

А пробел — это буква? А точка? Или мы всё же говорим о символе? И почему это должно работать, как одна буква? Кстати, в смысле абстрактного символа, оно так и работает. Это отображение этого символа на устройстве работает по другому. Но точно так же работает по другому отображение любого управляющего символа. А, если учесть ещё и фонты, то отображение каждого символа работает так. В тех же пропроциональных фонтах размер знакоместа разный по разным направлениям (почему векторную графику и используют). Поэтому вычисление длины показа строки на экране зависит от многих параметров — размер фонта, пропорциональность фонта. И ничто не мешает для специальных символов типа диакритики указывать вертикальный размер нормальным числом, а горизонтальный размер нулём или отрицательным — он будет сверху/снизу, но место займёт столько, сколько последующий символ.

И charAt будет возвращать просто абстрактный символ, которые там есть. Тем более, что с точки зрения приложений, которые хранят, передают, выполняют поиск — разницы нет. Разница появляется в тех приложениях, что отображают. Но там так и положено. Код, которые форматирует строку для представления на устройстве, должен быть отдельно.

И на "букве" состоящей из двух символов wchar_t работает совершенно нормально, т.к. это два символа. А вот любой китайский символ конца их алфавита из классических уже в 16 разрядов не влазит — тупо число больше, чем 64 К.

Mishka> А пробел — это буква? А точка? Или мы всё же говорим о символе? И почему это должно работать, как одна буква?

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

Вон, никогда бы не подумал, что «й» начнут активно писать как «и» с краткой:

Balancer> Не, тут реально концептуальная проблема есть. У одних случаях нужна буква. В других — символ. И в случае utf8 это часто разные понятия.

Дык, для чего и разделяют code point — обычное число, которым кодируется символ; форма — представление этого числа в машине; схема — кодирование числа машиннонезависимым способом. А уж сами символы делились на классы очень давно — isalpha всякие. В юникоде пошли немного дальше и количество классов расширили. И эта "краткая" — просто символ другого класса.

И тут возникает старая проблема представления единственности. Как в математике 0.(9)=1.0. Договорились использовать второе обозначение, но при этом все понимают и первое. Поэтому код должен понимать оба варианта: Й и И с краткой. И разницы тут со схемой той же UTF-8 нет особо. Вот встретил ты 0x10zzzzzz и знаешь, что это продолжение записи предыдущего определения. А уж конкретные комбинации спецсимволов и "букв" и их смысловое наполнение — дело договорённостей, т.к. кто может и акцент над И поставить и говорить, что это Й. А может в русском алфавите поставить акцент над Я и что из этого получится — не понятно, т.к. в самом юникоде запретов на такое нет.

Я к тому, что символ, буква и отображение символа и/или комбинации символов — это всё разные вещи. И трактовать их и надо именно таким способом.

Balancer> Вон, никогда бы не подумал, что «й» начнут активно писать как «и» с краткой:
Balancer> «Й» вам не «и» краткое! О важности нормализации Unicode / Хабрахабр

Ну, кому-то очень захотелось. А так Й вполне определена в той части юникода, который выдан под киррилицу.

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

digger> В арабском и иврите,например,есть разнообразные ударения и огласовки,которые комбинируются с буквами,в корейском буква - лигатура из гласной и согласной.Делать для каждой комбинации отдельный символ Юникода непродуктивно,потому буква всегда будет состоять из нескольких символов.Хотя бы получить букву,стоящую на определенной позиции,вставить/убрать/заменить ее желательно одной функцией без танцев с бубнами,в этом проблема.

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

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