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

[debi12345]

Кстати, переключиться с UCS-2 на UTF32 можно будет одним дефайном вроде CHAR_LENGTH - и все строковые алгоритмы, использующие этот дефайн, будут продолжать работать как ни в чем не бывало.

[alexey38]

Ключевая фича UTF-8 — бинарная совместимость с (7-bit) ASCII.

Приходится в 100 раз повторять, что там, где у Вас гарантированно только символы из ASCII, то нет ни какого смысла вместо AnsiString писать UTF8String. Обеспечение такой совместимости - это классический "распил бабла", которым грешат во всех странах. Какая-нибудь американская конторка, работающая на пентагон, говорит заказчику, мол дай несколько миллионов баксов, нам нужно обеспечить совместимость кода с UTF. Это конечно очень выгодно, за 10 млн.баксов, в паре мест заменить AnsiString на UTF8String. Но "распил", он и в Африке "распил".

спецификация вообще не завязывается ни на какую кодировку, просто декларирует совместимость со всеми, где размер базового типа — 1 байт.

А какие могут быть кодировки в 7-bit ASCII ? С чем там можно завязываться и заморачиваться? Не для этих целей придумали UTF. Ваше утверждение равнозначно тому, что кто-то сегодня сделает калькулятор умеющий считать до 10, и в его рекламе кто-то умно скажет, что они декларирует совместимость со всеми, где размер базового типа — 1 десятичная цифра. Еще раз говорю, что это не более, чем "распил бабла".

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

Благодаря этому сторонняя либа может вообще не париться с кодировкой строк, а обрабатывать их как последовательности байт.

А чем тогда UTF32 не является последовательностью байт? Если некая либа работает с текстом, как с бинарным массивом, то она аналогично может и с UTF32 отработать.

Добавлено спустя 1 час 1 минуту 28 секунд:

Благодаря этому сторонняя либа может вообще не париться с кодировкой строк, а обрабатывать их как последовательности байт. Пример — Lua (да-да, парсер и прочие нетривиальные вещи в комплекте), где все строки "8-bit clean"

Если есть некая сторонняя либа, корректно работающая только с 7-битным ASCII, то для ее использования с русскими или иными символами нужно использовать алгоритмы перекодировки, такие как Punycode, MIME и дому подобные. Если внешняя либа работает с UTF8, то конвертируйте из UTF32 в UTF8. Не о том идет речь. Речь идет о том, для чего используется UTF8 как стандартный вариант типа для строковой переменной?
Стандартный тип UNICODE должен быть UTF32, а для связи со сторонними либами и програми нужно использовать конвертирование, там, где это требуется. Со временем и внешние либы стали бы UTF32. А сегодня юниксы/линухи зациклились на UTF8, а винда зациклилась на UTF16.

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

Я есть большой фанат UTF8, но как формата ХРАНЕНИЯ текстовых ФАЙЛОВ.

Практический вопрос. У вас есть система на линухе, есть некая прога, у нее есть конфигурационный файл, в котором все стандартные примеры и описания на английском. Вам нужно некий параметр заменить на русский. В начале файла не BOM. Как Вы на практике определяете в каком формате нужно написать русский текст? В UTF8 или в системной 8-битовой кодировке? Был бы ВОМ, то все было бы однозначно. А если нет ВОМ, то как быть? Не проблема, если этот параметр можно легко проверить путем запуска, например, запустил прогу, и он этот русский параметр где-то вывел или куда-то передал. А если этот параметр используется в особых случаях, то как быть? Доку искать (в которой ничего не сказано про русский или иноязычные параметры), смотреть исходники проги? Как Вы поступаете в своей практике?

Я сам по данной причине, т.е. из-за необязательности ВОМ являюсь противником UTF8, как формата ХРАНЕНИЯ текстовых ФАЙЛОВ, т.к. американские "распильщики халявного бабла" опошлили хранение файлов в UTF8. Они деньги освоили, утверждают, что UTF8 ими поддерживается, но на практике большинство таких прог работает с UTF8 только для английского текста. Получается классический сценарий распила бабла. Кто в это не верит, тот пусть почитает книжки американских авторов. Американские разработчики начиная с 60-х годов быстро поняли, что пентагоновские и црушные деньги можно пилить. У них 99% военных разработок не завершалось результатом. То есть деньги взяли, освоили их, но на выходе ничего не сделали, и никто за это не наказан. Перевод под Unicode - из той же серии, причем формально даже результат есть.

[debi12345]

Практический вопрос. У вас есть система на линухе, есть некая прога, у нее есть конфигурационный файл, в котором все стандартные примеры и описания на английском. Вам нужно некий параметр заменить на русский. В начале файла не BOM. Как Вы на практике определяете в каком формате нужно написать русский текст? В UTF8 или в системной 8-битовой кодировке?

По мере того как UTF8 становится стандартом де-факто для "help system & config files" ЛИНУКСа, данные косяки уходят в прошлое.
Но для отрисовки символов и строковых манипуляций в LIBC используется внутренняя конверсия в тип WCHAR_T, который может быть либо UTF-16, либо UTF32 (либо зависит от дистрибутива). Однако эта кодирвка ДОЛЖНА (стандарт де-факто) быть с фиксированным количеством символов - а значит в случае UTF16 имеем UCS2. То есть и ЛИНУКС/UNiX (флагманы внедрения юникода) используют UTF8 только для хранения файлов на диске и веб-серверах.
XORG рисует строки либо однобайтных символов, либо двубайтных(UTF16LE) - зависит от выбраного шрифта (который пратически всегда либо ANSI но никак не UTF8 для однобайтных, либо UCS2 для 2-байтных) - предварительно конвертируя их во внутренне предствление UTF32 (нужно для расчеты размера и положнеия текста на экране,...).
Кстати, UTF16 имеет намного меньшую (по нынешним временам - нулевую) вероятность нарваться на суррогат (композитный исмвол), чем UTF8 - поэтому далеко на так тормознута, а реально вообще не тормозит (время тратится только на мгновенную проверку "это композит?") , а также можно считать UTF16LE = UCS2.
А наше сообщество кажется не разобралось что к чему и ломанулось внедрять UTF8 в виджеты и строковые манипуляции - тут же нарвавшись на чудовищные тормоза. Но сил вложено много, времени еще больше - теперь так просто не откатишь и не перепишешь (люди и так работают за "спасибо"), придется писать "оптимизации" и прочие костыли.

Прикольная статья:
http://www.barabanov.ru/arts/cyrillic/Linux-Cyrillic-web.pdf

ПС: Кстати, UTF16 & UTF32 имеют нюансик с порядком байтов, поэтому в общем случае этой кодировке нужен маркер BOM
http://www.unicode.org/faq/utf_bom.html
Рано или поздно, из-за введения бинарных маркеров - придем к тому, что свамо понятие текстовый файл уйдет в прошлое.

Добавлено спустя 2 минуты 26 секунд:
Мартин пишет, что UTF32 - тоже не панацея:

I don't know if it is useful if I repeat again because it seems nowbody reads
or believes it. Anyway, once again.
utf16 surrogate pair code points have no common code units with UCS2 -> there
is no problem to have surrogate pairs in a UCS2 string as long the pair is
not split in the middle. If one searches for a character constant in a string
in utf-16 by character index one knows that it is a single 16 bit code unit
if the searched character is in BMP (Basic Multilingual Plane). Searching for
a substring with surrogate pairs works without further measures. What is more
difficult is to determine the count of glyphs in a string. That is difficult
in UCS4 too because there could be decomposed characters in the string.

[alexey38]

По мере того как UTF8 становится стандартом де-факто для "help system & config files" ЛИНУКСа, данные косяки уходят в прошлое.

В неком светлом будущем конечно да. Но есть настоящее. Есть некая прога, возможно, не самая распространенная, но конкретно Вам нужная. Как Вы поступаете сегодня по этому вопросу? Как определяете перешла ли эта прога на UTF8 или еще не перешла?

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

Мартин пишет, что UTF32 - тоже не панацея:

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

[Сквозняк]

По мере того как UTF8 становится стандартом де-факто для "help system & config files" ЛИНУКСа, данные косяки уходят в прошлое.

И решают их особо одарённые англоговорящие ментейнеры чрезвычайно просто: собирают пакет вообще без файлов локализации. Вот так обновишься и потом вместо новья насильно запихиваешь в систему старые пакеты с установочного диска. А ещё говорят что оптические диски не нужны - флешка их заменяет.

[debi12345]

И решают их особо одарённые англоговорящие ментейнеры чрезвычайно просто: собирают пакет вообще без файлов локализации

Но пакеты (дляя включения в дтсрибутивы) им продоставляют наши сомэйнтэйнкеры. И это вина наших, что они ленятся вызвать "cat koi8text.txt | ICONV -f koi8-r -t utf8 > utf8text.txt" для получения UTF8-версии хэлпа.

[Сквозняк]

Да какая разница: есть дистрибутив который формально поддерживает кучу языков и есть пакет с исходниками, дополнительными файлами, патчами и спеком для сборки всего этого - причём тут koi8 и UTF8? В системе локаль на UTF8, внутренняя кодировка программы может быть любой, текстовые редакторы поддерживают практически всё кроме UTF32 - что ещё надо для накладывания патча и выпуска новой версии программы Навеяно пакетом редактора авидемукс, на федоровском диске он был со всеми локализациями интерфейса а новая версия в репозитории совсем без них, так что это вина буржуев которым плевать на все языки кроме английского и кодировка тут вторична.

[debi12345]

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

Я имею опыт дебиансовского мэйнтенанса - в реальный дистрибутив. Выглядит примерно так:
1) есть исходный текст программы
2) есть исходники хэлпа к ней (в каком нибудь гипер- или рич-формате)
Далее:
- мэйнтэйнер пишет описатель пакета и сборочный скрипт, прилагаемый к 1) и 2) - который делает все что угодно, в т.ч. любую локализацию. То, что этот скрипт сдеоает,то и попадет в дистрибутив. Если у пакета несколько мэйнтэйнеров (например поддерживающих разные локализации) и один из них филонит/шлангует/потерял интерес/.. и это приводит к падению сборочного скрипта - то сборочный скрипт правится главным мэйнтэйнером так, чтобы исключить это "падение". В вашем случае 200% так и произошло.
Собираются пакеты сборщиками дистрбутивов одним пинком - загружая тарбол исходников, накладывая на него патчи, реализующие описатель и сборочный скрпт - и запуская скрипт. Все автоматизирвано и поэтому нет пртстора проявлять "буржуиснскую вредность"

[hovadur]

А именно, на моем компе задача для UTF8 считается 48 сек, а с UTF16, UTF32 - 2 мс. Разница в 24 тыс. раз, т.е. на 4 порядка

Зачем ты применяешь UTF8Copy в этом коде?

Код: Выделить всё

      for j:=1 to UTF8Length(utf8) do
      begin
        c8:=UTF8Copy(utf8, j, 1);
        if c8=#32 then
          Inc(TestCount);
      end;


Ведь UTF-8 совместим с ASCII. А тогда можно делать так:

Код: Выделить всё

      for j:=1 to Length(utf8) do
      begin
        c8:=utf8[j];
        if c8=#32 then
          Inc(TestCount);
      end;


для UTF8 данное изменение считается 87мс, а с UTF16, UTF32 - 3 мс. Разница в 33 раза.
Да, я согласен, что UTF8 спасовало перед UTF16, что UTF16 лучше UTF8, что Embarcadero сделало правильный выбор.
Тогда у меня вопрос: почему тогда в linux все на UTF8? Неужели разработчики в linux не проводили таких тестов?

[debi12345]

Тогда у меня вопрос: почему тогда в linux все на UTF8? Неужели разработчики в linux не проводили таких тестов?

В "лине" GUI и манипуляции в памяти (GLIBC) - на фиксированных символах (UCS2 & UTF32). UTF8 по факту только в файлах на диске, далее конвертится в...
Вопрос в другом- зачем НАШЕ сообщество, вопреки общемировым тенденциям и многочисленным тестированиям и т.п. - пытается внедрить UTF8 тотально ? Ведь проигрыш-то чудовищный.

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

Ведь UTF-8 совместим с ASCII. А тогда можно делать так:

??? Убрана та часть, которая и выделяет UTF8 из других кодировок

[alexey38]

Ведь UTF-8 совместим с ASCII. А тогда можно делать так:

Вариант "c8:=utf8[j];" будет работать, если Вы заранее уверены и знаете, что все символы в строке utf8 были из 7-битной кодировки ASCII. Но как Вы об этом узнаете заранее? В 2, 3, 4 байтных символах строки UTF-8 чему там будут равны эти байты, вдруг они тоже будут равны #32, или коду иного символа. Такая реализация может привести к ошибке алгоритма.

Добавлено спустя 3 минуты 10 секунд:
Да и подсчитывать можно не только пробелы, но, к примеру, символы русского алфавита.

[SSerge]

В 2, 3, 4 байтных символах строки UTF-8 чему там будут равны эти байты, вдруг они тоже будут равны #32

Вообще то достаточно прочитать стандарт на UTF-8, чтобы убедиться, что эти байты НИКОГДА не будут равны #32.

[hovadur]

Да и подсчитывать можно не только пробелы, но, к примеру, символы русского алфавита.

Тогда неверен c16:=utf16[j]. Ведь в utf16[j] может встретиться и четарехбайтовый символ.

В 2, 3, 4 байтных символах строки UTF-8 чему там будут равны эти байты

Мы сравниваем с пробелом, значит можно c8:=utf8[j];, если мы бы сравнивали не с пробелом, а к примеру, с символом китайского алфавита, то да, нужно UTF8Copy.

[alexey38]

Вообще то достаточно прочитать стандарт на UTF-8, чтобы убедиться, что эти байты НИКОГДА не будут равны #32.

Цель теста была не в частном случае, когда найти символ пробела можно несколько быстрее. Цель тесты бала в общем случае, замените символ пробела на символ любой русской буквы.
В технике программирования бывают лаконичные и эффективные алгоритмы общего случая, работающие всегда. А есть алгоритмы под частный случай, не работающие в общем случае, такие алгоритмы принято называть "костылями". Если UTF-8 позволяет писать приемлемый по быстродействию код только за счет использования костылей, то это лучшее доказательство ущербности UTF-8.

[hovadur]

код только за счет использования костылей, то это лучшее доказательство ущербности UTF-8.

я повторяю, что тогда надо было вместо с16=utf16[j], что нибудь вроде c16=UTF16Copy(utf16, j, 1)