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

[alexey38]

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

О недостатках UTF-16 здесь уже было много сказано. Повторять нет смысла, кого интересует, те могут перечитать тему. Если речь идет о русскоязычных задачах, с осознанным ограничением в неиспользовании иероглифов, то в этой узкой сфере UTF-16 будет эффективен. UTF-8 эффективен только для англоязычных задач, но для таких задач будет еще более эффективным классический AnsiString. Таким образом в практических задачах UTF8String не расширяет возможности AnsiString, в виду чрезмерной медлительности. А UTF-16 (UnicodeString) - расширяют возможности AnsiString, но не являются исчерпывающим строковым типом. Строковый тип данных для UTF-32 максимально универсален, но сегодня слабо реализован на уровне строковой библиотеки.

Моя цель данной дискуссии была как раз в том, чтобы сформировать коллективное мнение, что строки UTF-32 нужны и такой тип данных нужно развивать в FPC, Lasarus. К сожалению дискуссия получилась довольно странной, как разговор на тему, кто из людей круче. Но вопрос был не о людях, а о строковых типах данных и направлении развития строковой библиотеки.

[hovadur]

Моя цель данной дискуссии была как раз в том, чтобы сформировать коллективное мнение, что строки UTF-32 нужны

Это понятно, спасибо тебе, но все же надо было бы применять что-нибудь вроде UTF16Copy, чтобы тесты были хотя бы равнозначными.

Добавлено спустя 13 минут 14 секунд:
Кстати спасибо SeZuka. Только твои тесты показали что к чему.

[debi12345]

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

Это крайне маловероятно, и даже с прилетом инопланетян средняя (по всем алфавитам) верятность использования 4-байтных суррогатов в 256 раз меньше вероятности использования UTF8-символов длиннее одного байта. А значит и торомозить будет в среднем в 256 раз меньше, а для земных алфавитов - на порядки меньше.

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

А UTF-16 (UnicodeString) - расширяют возможности AnsiString, но не являются исчерпывающим строковым типом

??? С ЮЦС-2 попутали ?

UTF16Copy

Это точно. Дело за этой функцией

[alexey38]

Это понятно, спасибо тебе, но все же надо было бы применять что-нибудь вроде UTF16Copy, чтобы тесты были хотя бы равнозначными.

В обсуждении изначально говорилось про русскоязычные задачи. Есть вполне правомерное понятие, как область применения. Для чего нужны искусственные тесты? Нужно проводить нормальные тесты для своей области применения. Тест для русскоязычных задач вполне правомерен. И не нужно для области русскоязычных задач специально замедлять. Точно также как в области англоязычных задач не нужно вообще использовать уникод.

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

??? С ЮЦС-2 попутали ?

http://www.unicode.org/faq/basic_q.html#14

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

Кстати спасибо SeZuka. Только твои тесты показали что к чему.

Это пример для подражания тем, кто любит голословно утверждать. Я до SeZuka не писал сюда тесты, т.к. для меня эта область уже была изучена. Мне лично эти тесты ничего нового не показали, именно это я и знал на момент начала дискуссии.

[hovadur]

Мне лично эти тесты ничего нового не показали, именно это я и знал на момент начала дискуссии.

Но почему не знал, что для сравнения с пробелом достаточно c8=utf8[j].

В обсуждении изначально говорилось про русскоязычные задачи.

Опять же, если мы будем применять какие-то ограничения, то опять придем к ошибкам, как в случае с cp1251, koi8r и т.д.

[alexey38]

Но почему не знал, что для сравнения с пробелом достаточно c8=utf8[j].

Знал, также знал, что для сравнения с пробелом можно и нужно было бы использовать кодировку Ansi, не заморачиваясь с уникодом в принципе. Умейте абстрагироваться от частности. Вы можете вообще убрать оператор сравнения, он приведен в тесте для того, чтобы оптимизатор не выкинул весь код по причине ничего неделания, что может легко случится для кода UTF-32. Тест сравнивает быстродействие получения символов в общем случае, заранее не зная какие будут символы. Доработайте тест, и сделайте ввод символа из TEdit, который нужно подсчитать.

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

Опять же, если мы будем применять какие-то ограничения, то опять придем к ошибкам, как в случае с cp1251, koi8r и т.д.

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

Основная проблема с cp1251, koi8r была в том, что получая текст в виде файла или из БД мы сходу не знаем в какой кодировке мы получили текст. Мы вынуждены угадывать. Аналогичная проблема и в файлах в кодировке UTF-8 без ВОМ. Вот в спецификации файла XML в заголовке указана кодировка: "<?xml version="1.0" encoding="utf-8"?>" и все ясно. Можно написать <?xml version="1.0" encoding="cp-1251"?> и будет не менее ясно.

Если нужен универсальный тип под все языки, то есть UTF-32. Но для него нужно доработать библиотеки.

[hovadur]

Знал, также знал, что для сравнения с пробелом можно и нужно было бы использовать кодировку Ansi

С тобой очень сложно разговаривать, так как ты не можешь согласиться, что ты не прав.

Аналогичная проблема и в файлах в кодировке UTF-8 без ВОМ.

Если везде использовать UTF8 без BOM, как и происходит в linux, то можно не парится с BOM.

[debi12345]

универсальный тип под все языки, то есть UTF-32

Для него (тоже) нужен B(ytes)O(rder)M(arker) - чтобы различить BE и LE версии

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

Если везде использовать UTF8 без BOM, как и происходит в linux, то можно не парится с BOM.

100% правильно! Но при этом выкинуть эту кодировку из ГУЙ и строковых манипуляций, где она по недоразумению присутстувует %)

[hovadur]

Но при этом выкинуть эту кодировку из ГУЙ и строковых манипуляций, где она по недоразумению присутстувует %)

Согласен, так как производительность тоже важна.

[alexey38]

С тобой очень сложно разговаривать, так как ты не можешь согласиться, что ты не прав.

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

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

Если везде использовать UTF8 без BOM, как и происходит в linux, то можно не парится с BOM.

Вы делаете утверждение. Я, возражая Вам, указывал на сложности с идентификации кодировки такого файла. На этот вопрос, Вы не смогли дать ответ, как однозначно и быстро определить кодировку как в самой программе, так и пользователю, при необходимости редактирования файла. Если Вы не можете ответить на простейший вопрос, то для чего Вы продолжаете голословно утверждать, что "можно не парится"? Это религиозная вера или это инженерный подход? Кто-то не парился, когда были только 8-битные кодировки, кто-то парился с этим. В целом проблема была. И сегодня с внедрением файлов UTF8 без BOM проблема ни как не решена. Парится или не парится, это уже частности и личное субъективное восприятие. Интересует конкретика.

[hovadur]

Но по сути вопроса я оказался прав

Признайся, что ошибся с UTF8Copy и достаточно c8=utf8[j]. Скажи четко: да, я ошибся; или нет, я прав. Не нужно философии на полстраницы.

то к чему все эти частности?

Все эти частности для того, чтобы знать что не 24тыс раз UTF8 медленее, а в 33 раза.

Интересует конкретика.

Конкретика в том, что в linux любой файл - это уже UTF8 без BOM, поэтому никто не парится по поводу кодировок в linux. Такое правило: если программа работает в linux, то любой файл будет UTF8 без BOM; если программа работает в windows, то любая кодировка может быть и тут, да, BOM нужен.

[debi12345]

Признайся, что ошибся с UTF8Copy и достаточно c8=utf8[j].

Алекс тут прав - ему просто нужно было задействовать "интерналы" ЮТФ8 - то есть чтобы она вела себя как штатная ЮТФ8.
Посимвольный индексный доступ совместим с ЮТФ8 - но только как частный случай то бишь хак

[alexey38]

Конкретика в том, что в linux любой файл - это уже UTF8 без BOM, поэтому никто не парится по поводу кодировок в linux. Такое правило: если программа работает в linux, то любой файл будет UTF8 без BOM; если программа работает в windows, то любая кодировка может быть и тут, да, BOM нужен.

Давайте конкретно, если я нахожу на планете земля хотя бы один компьютер с linux, на котором на диске есть хоть один текстовый файл не в кодировке UTF8 (а в kio8, cp1251 и т.п.), то Вы мне выплачиваете 1 млн. баксов. А если я не найду (хотя уже нашел), то я Вам выплачиваю. Идет такой вариант?

Для чего Вы утверждаете, что под люнихом не существует текстовых файлов в 8-битной кодировке, которые не так просто отличить от файлов в кодировке UTF8 по причине отсутствия ВОМ. Каким признаком Вы будете отличать кодировку файла, кроме как эвристическим анализом?

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

Признайся, что ошибся с UTF8Copy и достаточно c8=utf8[j]. Скажи четко: да, я ошибся; или нет, я прав. Не нужно философии на полстраницы.

Я признаюсь в том, что я неправомерно в тесте сделал сравнение с пробелом (код 32), вместо этого я должен был сделать сравнение с уникодовским литералом буквы "Я".
В тоже время я настаиваю на том, что Ваше утверждение о равнозначности замены UTF8Copy на c8=utf8[j] является ошибочным по существу, и его можно с оговорками считать справедливым только для символов с номером до 127 в соответствии с ASCII. Но для символов с номером до 127 в соответствии с ASCII было бы еще быстрее просто использовать строку AnsiString (RAWByteString) для подсчета числа пробелов. Так что Ваш алгоритм также несовершенен.

Вы написали

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

c8:=utf8[j];
if c8=#32 then
  Inc(TestCount);

Это явная ошибка, т.к. Вы не смогли получить символ в кодировке UTF8. Если бы Вы написали

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

if utf8[j]=#32 then
  Inc(TestCount);

То такой вариант можно было бы признать правомерным хотя бы для частного случая. А так Вы сделали явный баг.

[hovadur]

один текстовый файл не в кодировке UTF8 (а в kio8, cp1251 и т.п.)

чтобы программы linux (в том числе gedit) могли работать с ним, нужно его сконвертировать в UTF8. Проблема решается таким образом: любой файл прибывший издалека конвертим в UTF8, и его любая программа в linux откроет. Для конвертации файлов есть утилита iconv, мне она только один раз в полгода нужна.

А так Вы сделали явный баг.

Посмотрите на определение UTF8String:

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

  UTF8String          = type ansistring;


то что у тебя "c8:AnsiString" ничего не меняет. А значит можно делать так:

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

c8:=utf8[j];
if c8=#32 then
  Inc(TestCount);


Да сам посмотри: программа находит такое же кол-во пробелов, что в кодировке UTF8, что в UTF16.

[alexey38]

Да сам посмотри: программа находит такое же кол-во пробелов, что в кодировке UTF8, что в UTF16.

Совпадение результатов не является признаком отсутствия ошибки. Вы же до меня докопались по формальной причине, что пробел, как частный случай, имеет 8-битное значение литерала в UTF8. Так я Вам по формальному признаку говорю, что операция "c8:=utf8[j]" не является операцией получения литерала в кодировке UTF8. Если бы Вы хотели продемонстрировать эффективность работы в ANSIString, то Вы должны были в тесте исключить конвертацию строки "utf8 := AnsiToUtf8(ansi);", но это не сделали. Так что одни ошибки, не смотря на то компилятор не ругается, и результат совпал. Поэтому признайте свою ошибку, как я признал, что подсчет числа пробелов не является показательным тестом, вместо пробелов нужно было подсчитывать число букв "Я".

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

чтобы программы linux (в том числе gedit) могли работать с ним, нужно его сконвертировать в UTF8. Проблема решается таким образом: любой файл прибывший издалека конвертим в UTF8, и его любая программа в linux откроет. Для конвертации файлов есть утилита iconv, мне она только один раз в полгода нужна.

Вы так и не можете ответить каким образом Вы догадываетесь или программа должна догадаться, что файл, прибывший из далека или уже некоторое время лежащий на диске на компе в формате UTF8 или не в формате. Для использования утилиты iconv нужно указать параметры, как Вы догадываетесь какие параметры нужно указать? Вопрос, заданный уже в 10 раз, был про это и только про это. Так как ВОМ для UTF8 нужен только для того, чтобы идентифицировать, что файл уже в UTF8, и ни какие конверторы уже не нужно вызывать. Соответственно отсутствие ВОМ заставляет думать, без гарантии получения достоверного результата нужно ли конвертить или не нужно конвертить. Как решить эту проблему Вы так и не смогли ответить.