Забавный но досадный глюк

[alexey38]

Просадки скорости по сравнению даже с UTF-32 (при итерировании, а не случайном доступе) не наблюдается — сложность декодирования компенсируется компактностью данных.
У UTF-16 нет объективных преимуществ перед UTF-8. Если забивать на суррогатные пары, то a) о поддержке юникода речи идти не может, b) называй вещи своими именами, это кодировка UCS-2.

У UTF-8 нет объективных преимуществ перед UTF-16 или UTF-32. Для алгоритма общего случая просадка скорости работы с UTF-8 достигает порядков, по сравнению со скоростью работы UTF-32. Хотя для UTF-8 можно найти частный случай задачи, в которой он отработает быстрее.

Добавлено спустя 8 минут 7 секунд:

называй вещи своими именами, это кодировка UCS-2.

Q: What is the difference between UCS-2 and UTF-16?
A: UCS-2 is obsolete terminology which refers to a Unicode implementation up to Unicode 1.1, before surrogate code points and UTF-16 were added to Version 2.0 of the standard. This term should now be avoided.
UCS-2 does not define a distinct data format, because UTF-16 and UCS-2 are identical for purposes of data exchange. Both are 16-bit, and have exactly the same code unit representation.
Sometimes in the past an implementation has been labeled "UCS-2" to indicate that it does not support supplementary characters and doesn't interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters. [AF]

[debi12345]

Для алгоритма общего случая просадка скорости работы с UTF-8 достигает порядков, по сравнению со скоростью работы UTF-32.

Есть такое. Но с другой (иррациональной) стороны, "однажды в будущем не ударить в грязь лицом перед инопоенетными гостями" - немалый аргумент за "стоически и с песней терпеть тормозА здесь и сейчас".

[runewalsh]

Для алгоритма общего случая просадка скорости работы с UTF-8 достигает порядков

Понятно, что тесты всем писать лень, но просто по логике: откуда взяться порядкам? Битовые операции, необходимые для раскодирования что UTF-8, что UTF-16, занимают в пару сотен раз меньше времени, чем обращения к некэшированной памяти. По последнему параметру UTF-8 как минимум не уступает UTF-16, а чаще — превосходит.
(UPD: Перечитал, хорошо, ты имел в виду UTF-32. Его единственное преимущество — случайный доступ, я об этом тоже писал. Но тема не о текстовых редакторах).

What is the difference between UCS-2 and UTF-16?

UCS-2 — строго двухбайтовая кодировка. Она в принципе не покрывает все используемые символы Юникода. Точка.

[alexey38]

alexey38 какие твои аргументы будут в пользу UTF-16?

Если Вы прочитаете тему с самого начала, то я уже по несколько раз перечислял недостатки UTF-8, которые являются достоинством UTF-32, а иногда и UTF-16. Заново это перечислять в 10 раз будет неприлично.

Если UTF-16 представлять как UCS2, т.е. избегать всяких там суррогатных пар, специфических языков и т.п., то алгоритм работы строковых функций UCS2 будет аналогичен алгоритму работы с 8-битными строками ANSI, включая все скоростные преимущества таких строк.
Для программистов работающих в России UCS2 эффективнее, чем UTF-8. Для программистов работающих с суррогатными парами и специфическими языками, неэффективным будет и UTF-8 и UTF-16, эффективным будет только UTF-32.
Для программистов работающих только с 7-битным ASCII, неэффеективным будет и UTF-8 и UTF-16 и UTF-32. Им следует использовать классические функции 8-битных строк ANSI.
Итого: есть преимущества у ANSI, у UCS2 и UTF-32. У UTF-8 преимуществ нет.

Как формат хранения UTF-8 без BOM или метатэга не имеет преимуществ, а имеет баги. Но его использование там, где он уже применяется допустимо исходя из совместимости с существующим. Но это не преимущество, точно также как дискета не является преимуществом перед флешкой.
Для компактности хранения или передачи, и обеспечения контроля целостности или конфиденциальности используют архиваторы (в т.ч. с шифрованием), использование UTF-8, как способ сжатия UTF-32 недостаточно эффективен, проще подключить к программе библиотеку работы с 7z.

Добавлено спустя 3 минуты 22 секунды:

Перечитал, хорошо, ты имел в виду UTF-32. Его единственное преимущество — случайный доступ, я об этом тоже писал.

Не случайный, а индексированный доступ. Его используют большинство известных текстовых алгоритмов. Покажите мне библиотеку, где был бы реализован последовательный доступ к строкам UTF-8, чтобы в параметрах функций, вместо номера символа указывалось бы смещение в байтах?

[debi12345]

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

Как насчет регистро-независимого сравнения строк ? Тут побайтовым сранвнением не обойдешься - придется предварительно декодировать (приводить к одному регистру) оба аргумента, а для UTF8 это тежелая операция.

[hovadur]

Итого: есть преимущества у ANSI, у UCS2 и UTF-32. У UTF-8 преимуществ нет.

Не должно быть программистов, работающих с разными кодировками, должна быть одна на всех, так чтобы не было повторения KOI8, CP1251 и т.д.
А для этой кодировки идеально подходит UTF-8.

[debi12345]

Она в принципе не покрывает все используемые символы Юникода

Например какие из ИСПОЛЬЗУЕМЫХ ? Где и кем ?

[alexey38]

UCS-2 — строго двухбайтовая кодировка. Она в принципе не покрывает все используемые символы Юникода. Точка.

Но нам в качестве основного преимущества UTF-8 некоторые указывали на бинарную совместимость UTF-8 и 7-битного ASCII. А UCS-2 в отличие от 7-битного ASCII покрывает большинство языков, поэтому UCS-2 лучше, чем UTF-8.

[debi12345]

Не должно быть программистов, работающих с разными кодировками, должна быть одна на всех, так чтобы не было повторения KOI8, CP1251 и т.д.
А для этой кодировки идеально подходит UTF-8.

Однозначно ! Для исходников и прочего неупакованного текста она идеальна. Но не для отрисовки и манипуляций в памяти.

[alexey38]

А для этой кодировки идеально подходит UTF-8.

Это самый худший вариант, тем более он с багом, в виде необязательной ВОМ, приводящее к хаосу из повторения бед с KOI8, CP1251. Вы так и не смогли привести ни одного аргументы в пользу UTF-8.
Идеальная кодировка UTF-32, точно также как идеальный тип целочисленной переменной - integer (32).

Добавлено спустя 2 минуты 52 секунды:

Однозначно ! Для исходников и прочего неупакованного текста она идеальна.

Без ВОМ - она (UTF-8) глюкава, т.к. Вы не можете сходу определить формат текстового файла. А большинство файлов UTF-8 идет без ВОМ, значить имеем однозначный глюк. Глючный вариант является самым худшим из возможных. Программа которая иногда работает, а иногда не работает бесполезна.

[debi12345]

Вы не можете сходу определить формат текстового файла.

В сегодняшних реалтиях, можно сразу предположить, что имеем дело с UTF8 и отмотать назад (выполнить никий пробинг), если в тексте встечаем не-текстовый и не CR/LF/TAB байт.

[runewalsh]

Если UTF-16 представлять как UCS2

...то инопланетяне тебя не поймут. Слышал о future compatibility?

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

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

P.S. Сейчас проверил — действительно, реальные тексты и даже не самые тривиальные кандзи влазят в 15 бит. Но существования остальных символов это не отменяет. Чёрт, жаль, что такие же люди, как ты, считающие, что стандарт к ним не относится, пишут драйверы OpenGL. Тем более странно слышать в контексте предложенной потенциально глючной реализации Юникода подобное:

Программа которая иногда работает, а иногда не работает бесполезна.

[alexey38]

В сегодняшних реалтиях, можно сразу предположить, что имеем дело с UTF8 и отмотать назад (выполнить никий пробинг), если в тексте встечаем не-текстовый и не CR/LF/TAB байт.

Чтобы определить текстовый ли символ нужно знать язык. Например, слово "Авто" и примера разобранного несколько страниц назад имеет вид "Авто". Как определить что это такое? Бинарный вид "D0 90 D0 B2 D1 82 D0 BE"? Это символы или не символы? Может на каком-то африканском языке это ясный им текст?
Навороченный эврестический алгоритм слишком сложен, да и не надежен он при редких встречах не латинских символов. Упрощенный - слишком глючен. UTF16 или UTF32 без ВОМ не бывает, поэтому они лучше UTF8. Браузеры на сайтах без метатега про кодировку регулярно ошибаются с определением кодировки, а это ведь браузеры, достаточно отлаженные продукты.

Добавлено спустя 2 минуты 2 секунды:

P.S. Сейчас проверил — действительно, реальные тексты и даже не самые тривиальные кандзи влазят в 15 бит. Но существования остальных символов это не отменяет. Чёрт, жаль, что такие же люди, как ты, считающие, что стандарт к ним не относится, пишут драйверы OpenGL. Тем более странно слышать в контексте предложенной потенциально глючной реализации Юникода подобное:

Идеален UTF32, хуже UTF16, совсем плох UTF8.

Добавлено спустя 21 секунду:

Обычно итерирования достаточно.

Для каких задач?

[runewalsh]

Как определить что это такое? Бинарный вид "D0 90 D0 B2 D1 82 D0 BE"?

У них выставлен старший бит и это валидная UTF-8.
Из вики: The probability of a random string of bytes which is not pure ASCII being valid UTF-8 is 3.9% for a two-byte sequence,[31] and decreases exponentially for longer sequences.

Для каких задач?

Любая последовательная обработка. Вывод или там конвертирование. Если тебе нужно индексировать БОЛЬШИЕ строки, имеет смысл загружать их по частям, а не тратить 3/4 памяти на нули. Не мешай переменные на стеке размером с регистр и кодировки строк, это совершенно разные вещи.

[Сквозняк]

У них выставлен старший бит и это валидная UTF-8.

А может быть координаты вершин 3Д фигуры, вставка бинарной информации в текст или IBM866, а ещё может быть смесь 8 битной кодировки и UTF-8 которая нормально редактируется в редакторе с текущей 8 битной кодировкой.