substr — это PHP, Perl, куча других языков. Но именно в PHP всё работает несколько иначе (смотрю исходник в данный момент). И длина, конечно же, не ищется поиском \0, она хранится — в PHP-строке могут встречаться эти символы.
Так что, если говорить о Си, то это будет тормозить чуть, для PHP/Perl/Ruby/Python и прочих языков, где \0 — обычный символ тормоза будут серьёзнее.
Вы, кажется, невнимательно читали, что я писал. Разве я говорил, что он будет больше, я говорил, что он будет сложнее. Причём, налегаю я не на strlen, который медленее несущественно, а на substr
1) обратная совместимость на латинских буквам нам всем не впилась :)
2) да, позабыл, что там два байта всего. что ж... UCS-4? :) тут я крепко проигрываю.
а по поводу производительности — есть масса мест, где можно оптимизировать, то, что вы перечислили — верно, но это не значит, что низкая производительность utf-8 не важный фактор.
Вот! Перед измерением длины недурно ещё и нормализацию сделать :)
1) А зачем нам совместимость с ASCII? Что это даёт в нормальных условиях (а не когда надо быстро сделать совместимость)
2) зачем нам весь range? сейчас там занято около 100 000.
3) о каких потерях вы говорите? у нас тема — веб. какие там потери?
на встречный вопрос такой вот ответ: UCS-2 позволяет создавать производительные Unicode-приложения. UTF-8 — нет. UTF-8 — это своеобразная компрессия, по сути.
strlen не будет работать так же быстро. Потому что в strlen мы не ищем признак конца, а считаем сколько символовов, а они переменной длины. Т.е. строку нужно будет парсить.
Посчёт количества единиц в первых битах — это далеко не "несколько тактов", вы, видимо, в Ассемблере никогда не программировали. Сложность алгоритма получения символа по номеру, конечно же, сильно возрастёт. Вы, видимо, совершенно не представляете как это всё работает. В UCS-2 взять символ по номеру — это взять два байта из позиции N*2, где N — позиция, а 2 — размерность символа.
Идём дальше, вы неверно себе представляете процесс поиска N-нного символа в 10Гб тексте. В случае UCS-2 его не нужно зачитывать полностью, fopen, fseek(.., N*2) и читаем два байта. В случае с UTF-8 его придётся читать целиком до нужной позиции.
Вы тут всё говорите про "несущественную разницу", давайте же поговорим и про неё. БОльшая часть объёма страницы — графика, так что я утверждаю, что разница между объёмом страницы в UCS-2 и UTF-8 несущественна при существующих скоростях и gzip.
Задам вам конкретный вопрос: какие проблемы решает UTF-8, что их не может решить UCS-2?
Я бы так сказал: "не надо заливать в мерседес 72й бензин, а в веб - UTF-8". Вот теперь ваша аналогия полностью к месту. UCS-2 — хорошая кодировка, а UTF-8 — нет.
Скорость? Если бы всех заботил этот показатель, на всех сайтах мы бы видели gzip. Кроме того, бОльшую часть объёма среднего сайта составляет не текст, а картинки.
По поводу потерь... Что-то я не понимаю о чём вы. Какие потери байтов? Где? Назначение у UTF-8 одно - быстро добавить Unicode к программам, которые его не понимают. И ключевое слово здесь — быстро.
Странный вы человек. Вы знаете как устроена кодировка? Думаю, знаете. Разницу в алгоритме получения символа по номеру в UCS-2 и UTF-8 представляете? Какие ещё вам тесты нужны?
Каким бы не был внутренний способ кодирования, это никак не влияет на тот факт, что UTF-8 ужасная кодировка. Кстати, спросите у программистов на PHP как там строки хранятся.
Метаинформация - это не только длина строки, это ещё и положение символа для substr и прочего.
UTF-8 ужасен. Я вам привёл аргумент почему. Опровергающих аргументов я не вижу. На всё вы пишите или "и что с того" или "это не аргумент, потому что, когда мы работаем с USC-2...".
Выше уже писали, что UTF-8 был придуман ленивыми англоязычными программистами, чтобы не переделывать существующие приложения. Отсюда я бы убрал слово "ленивыми", а так — всё верно. Это и есть плюс UTF-8.
Минусы существенны — кодировка имеет нефиксированную длину символа, поэтому все strlen, получение символа по номеру и прочее имеют низкую производительность, так как приходится проходить всю строку или нужно хранить метаинформацию, которую нужно расчитывать в момент записи. Т.е. куда не кинь — всюду расход ресурсов.
Так что, если говорить о Си, то это будет тормозить чуть, для PHP/Perl/Ruby/Python и прочих языков, где \0 — обычный символ тормоза будут серьёзнее.
А так — думаю, нам каждому по звезде :)
1) обратная совместимость на латинских буквам нам всем не впилась :)
2) да, позабыл, что там два байта всего. что ж... UCS-4? :) тут я крепко проигрываю.
а по поводу производительности — есть масса мест, где можно оптимизировать, то, что вы перечислили — верно, но это не значит, что низкая производительность utf-8 не важный фактор.
1) А зачем нам совместимость с ASCII? Что это даёт в нормальных условиях (а не когда надо быстро сделать совместимость)
2) зачем нам весь range? сейчас там занято около 100 000.
3) о каких потерях вы говорите? у нас тема — веб. какие там потери?
на встречный вопрос такой вот ответ: UCS-2 позволяет создавать производительные Unicode-приложения. UTF-8 — нет. UTF-8 — это своеобразная компрессия, по сути.
Посчёт количества единиц в первых битах — это далеко не "несколько тактов", вы, видимо, в Ассемблере никогда не программировали. Сложность алгоритма получения символа по номеру, конечно же, сильно возрастёт. Вы, видимо, совершенно не представляете как это всё работает. В UCS-2 взять символ по номеру — это взять два байта из позиции N*2, где N — позиция, а 2 — размерность символа.
Идём дальше, вы неверно себе представляете процесс поиска N-нного символа в 10Гб тексте. В случае UCS-2 его не нужно зачитывать полностью, fopen, fseek(.., N*2) и читаем два байта. В случае с UTF-8 его придётся читать целиком до нужной позиции.
Вы тут всё говорите про "несущественную разницу", давайте же поговорим и про неё. БОльшая часть объёма страницы — графика, так что я утверждаю, что разница между объёмом страницы в UCS-2 и UTF-8 несущественна при существующих скоростях и gzip.
Задам вам конкретный вопрос: какие проблемы решает UTF-8, что их не может решить UCS-2?
По поводу потерь... Что-то я не понимаю о чём вы. Какие потери байтов? Где? Назначение у UTF-8 одно - быстро добавить Unicode к программам, которые его не понимают. И ключевое слово здесь — быстро.
Метаинформация - это не только длина строки, это ещё и положение символа для substr и прочего.
UTF-8 ужасен. Я вам привёл аргумент почему. Опровергающих аргументов я не вижу. На всё вы пишите или "и что с того" или "это не аргумент, потому что, когда мы работаем с USC-2...".
Удачных выходных.
по поводу сравнения UTF-8/USC спрошу ещё раз: это как-то противоречит моему утверждению, что UTF-8 ужасная кодировка?
Минусы существенны — кодировка имеет нефиксированную длину символа, поэтому все strlen, получение символа по номеру и прочее имеют низкую производительность, так как приходится проходить всю строку или нужно хранить метаинформацию, которую нужно расчитывать в момент записи. Т.е. куда не кинь — всюду расход ресурсов.