Небольшой интересный ньюанс про UTF-8

Антоша, а тебе не стыдно, что такую вещь только сейчас узнал?

Все символы занимают по два байта в UTF-16.

Ребята, вы где такую траву берете? Глядишь, скоро появятся откровения, что жопу после туалета надо вытирать...

+1

Офигеть. Кто бы мог подумать.

Лучше вот это почитай, узнаешь ещё кучу интересного. :)

http://www.linux.org.ru/jump-message.jsp?msgid=1785620

unicode (вернее его представление), он разный бывает. UTF-8, UTF-16, UTF-32. в первых двух символы переменной длинны (UTF-8 1-6 байт, UTF-16 2 или 4 байта), в последнем символ всегда занимает 4 байта.

Насчет _только_ английских символов - не верно. в UTF-8 латинский (а точнее любой из US-ASCII) символ, даже если он единственный в строке из каких-нибудь других всегда будет занимать ровно 1 байт. А кириллические символы по 2 байта будут кушать. Обычная строка, с символами из первой половины таблицы ASCII, будет абсолютно валидной и иметь идентичное значение в UTF-8.

А в UTF-16 что латинские, что кириллические буквы будут кушать по два байта.

Товарищ, Вы тоже не совсем в курсе, хотя уже намного лучше. Вы не упомянули про отличие codepoint'ов от глифов, а без этого понять всего ужаса работы с юникодом нельзя. :) Кроме того, насколько я понимаю, в один прекрасный день UTF-32 и UCS-4 станут разными кодировками (не дай бог дожить).

:))))))

Teak:

> Вы не упомянули про отличие codepoint'ов от глифов, ...

Эта ...

А каким боком глифы относятся к юникоду? Единственное известное мне соотношение codepoint'ов и глифов -- немного ИМХО излишнее пояснение для читателей драфтов, что чиселки, о которых идет речь стандартах, никак не определяют глифы...

Или я не прав?

>Товарищ, Вы тоже не совсем в курсе, хотя уже намного лучше. Вы не упомянули про отличие codepoint'ов от глифов, а без этого понять всего ужаса работы с юникодом нельзя. :)

это имеет слабое отношение к оригинальному сообщению. с ужасом работы с юникодом сталкивался впритык. еще к примеру, можно упомянуть ужасы case folding'а.

>Или я не прав? вполне прав.

Ну, как же. Благодаря этой фиче простую русскую букву "ё" можно записать как просто "ё", а можно - как "е" с тремой (два codepoint'а, несколько байтов), причём мы должны считать эти два варианта одинаковыми. Если я правильно понимаю.

Ещё можно упомянуть о "некорректных символах", то есть о том, что некоторые последовательности байтов вообще не являются строками в UTF-8, и это тоже надо проверять. Или о том, что один и тот же codepoint можно представить разным количеством байт, хотя только самый короткий вариант считается правильным.

tnx, узнал кучу всего интересного! ;-)
А как обстоят дела у Qt с юникодом? (бардак или нормально)

А дважды два - четыре!

У Qt уж сто лет как все нормально с unicod'ом. Все внутреннее представление строк в UTF-8.

Selecter, ты вот, вроде, производишь впечатление грамотного человека, а пишешь "ньюанс". Скорректируй правописание слова, означающего "небольшое различие, мелкую разницу".

Откройте для себя unicode.org. Там все прекрасно описано.

>У Qt уж сто лет как все нормально с unicod'ом. Все внутреннее представление строк в UTF-8.

с юникодом много где "все нормально". но у у него есть определенные проблемы. опять же проблемы с вышеупомянутым case folding'ом, то бишь сведение букв к одному кейсу для case insensitive операций.

в одном из языков (не помню в каком, врать не буду, а искать сейчас лень) есть две буквы i и i-без-точки, что конфликтует с case folding'ом для английского языка (I->i). То есть case-folding не однозначен и зависит от локали. кроме того в каком-то из языков (опять же склероз, не помню каком) есть три вида регистра для некоторых букв - title case, upper case и lower case, например ZH, Zh, zh (это одна буква такая).

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

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

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

Ну, вот, опять банки в меня полетели. Я ЛОР читаю не полностью, могу что-то пропустить. Помню 2-3 темы, где кто-то утверждал, что он старается на серваках использовать 8-битные кодировки по соображениям производительности.

На серваках - это на сайтах в смысле? Абсолютно глупая затея. Скриптам сайта пофиг, какая там кодировка (если только они ничего не перекодируют), а разница в трафике сравнима с размером какой-нить favicon.ico. :) Трафик не текстом генерится.

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

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

>Так что о какой тут производительности речь, абсолютно непонятно.

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

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

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

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

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

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

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

> а когда запрос к базе выполняется с условием по строковому полю, тоже наверно нормализации не надо? и валидацию в топку?

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

> то что для тебя это все не видно и прозрачно, не означает то этого нет.

Я имею привычку думать, прежде чем говорить, не надо уж так на меня... :)

> другое дело что это может быть не критично из-за того что большую часть процессорного времени съедают другие действия.

А вот это прежде всего я и хотел донести до Антона.

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

>Я имею привычку думать, прежде чем говорить, не надо уж так на меня... :) договорились :)

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

впрочем я забыл что я на ЛОРе :)

Не, я как раз вполне конкретно говорю. Я работаю в мелкой хостинговой конторе, и говорю о том, что в моей области (то есть о подавляющем большинстве сайтов).

>Не, я как раз вполне конкретно говорю. Я работаю в мелкой хостинговой конторе, и говорю о том, что в моей области (то есть о подавляющем большинстве сайтов).

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

Teak(20.02.2007 7:25:16):

> Благодаря этой фиче простую русскую букву "ё" можно записать как просто "ё", а можно - как "е" с тремой (два codepoint'а, несколько байтов),...

:-)

Влияние последовательности codepoint'ов на глифы лучше всего воспринимать как лигатуры (собственно говоря, это они и есть!).

А с каких пор UTF-8 вернули 6 байт? Его же искусственно ограничили 4-мя.