SII писал(а):
Либо так же, либо сложней, чем в UTF-16. Причина проста: у UTF-16 длина символа (2 или 4 байта) устанавливается путём анализа старшего байта, и всё. (если там определённые коды, то имеет место быть суррогатная пара, и соответственно, общая длина символа -- 4 байта; все остальные случаи -- длина символа 2 байта). А вот в UTF-8 требуется последовательно анализировать байт за байтом до тех пор, пока не будет определена длина символа. Соответственно, такой анализ сложней и медленней.
Вы говорили про определение НАЧАЛА символа. Начало символа в UTF-8 определяется тоже предельно просто. Символы с кодами 0-7Fh - это цельный символ. В остальных случаях, если встретившийся код больше или равен 0C0h - это первый байт символа, независимо от его длины. Всё.
SII писал(а):
Неправда, а точней, полуправда. Если хранить тексты, нормально кодирующиеся в 7-битном ASCII -- то действительно, только недостатки.
ASCII - он всегда 7-битный. В противном случае это не ASCII, а, например, KOI-8 или ещё какая-нибудь хрень.
SII писал(а):
Однако если это текст на китайском, то в UTF-16 он займёт меньше места, чем в UTF-8
Хилое преимущество. Тут некоторые вообще предлагают на 32-бита перейти по закону Мура, а что там 3 байта вместо двух, уже не так важно :)
SII писал(а):
Так что Ваше утверждение слишком категорично, скажем для разнообразия культурно :)
Оооо! Какой прогресс! Я жму вашу руку! Наконец вы начинаете общаться в правильном ключе, - уважительно!! :)
SII писал(а):
Опять-таки, слишком большая категоричность. Во-первых, допустимым текстом UTF-8 будет не любой допустимый ASCII, а любой, укладывающийся в "классический" 7-битный ASCII, а не в расширенный 8-битный.
См. выше. Я про другие кодировки и не говорил.
SII писал(а):
Теперь что касается 16-разрядной кодировки. Её обработка, безусловно, сложней, чем 32-разрядной (требуется анализ на суррогатные пары), но она по-любому быстрей, чем для UTF-8 (см. про определение длины символа в самом начале)
Тэкс, теперь вы уже про ДЛИНУ символа говорите? ОК, это тоже определяется предельно просто. Длину символа СРАЗУ задаёт первый байт последовательности.
SII писал(а):
в современном мире, где часто используются символы, выходящие за пределы 128 кодов стандартного ASCII, а соответственно, кодируемые как минимум двумя байтами в UTF-8: в таком случае последний не имеет преимущества над UTF-16 по объёму занимаемой памяти, но проигрывает по скорости обработки из-за более долгого анализа длины символа.
Даже в русском языке полно пробелов, цифр, знаков препинания и прочих символах. Так что текст получается плотней. Это раз.
Хотите вы или нет, но UTF-16 тоже требует анализа на возможную длину символа, даже если суррогатные пары и не встречаются. Значит не выигрывает, или выигрыш получается весьма незначительным. Это два.
И наконец. Подавляющее большинство работы с текстом не предполагает его сложного анализа. 90% т.н. "работы с текстом" это - хранение текста в базах данных, поиск на прямое совпадение, сортировка строк, вывод сообщений, в крайнем случае с простым форматированием, обмен сообщениями и пр. мутотень, - ВСЁ это не отличается от обработки обычного ASCII-текста. В то время, как работа с 16 и 32-битными кодировками вынуждает делать вторую копию большинства системных функций для передачи параметра WCHAR*. Даже поиск начала символа и определение длины строки в символах - уже встречаются весьма не часто.