Ответ на »сообщение 203« (Banderas)
___________________________
1. Каждому символу Unicode соответствует одна и только одна последовательность байтов в UTF8
2. Ни одна последовательность байтов в UTF8, соответствующая некоему символу, не может входить в последовательность байтов, соответствующих другому символу.

Кроме того, могу сказать, что простейшие компоненты, такие как TLabel, TEdit, TInputBox и другие уже реально работают в utf8vcl, хотя библиотека еще в стадии альфа.

Ответ на »сообщение 202« (Ильяс)
___________________________

А где эти отзывы?

По слухам D2007 весьма стабильна, но у меня нет времени это проверить (хотя D2007FT у меня есть).
Действительно - а кто юзал (что скажете)?

Ответ на »сообщение 200« (Aleg Azarousky)
___________________________

Не гладко то что некотрые символы представляются разными способами. Pos их не найдет. Да и вообще все это не имеет смысла, так как все утилитные (прикладные) функции интерпретируют строки как ANSI.

я так и не понял, кто-нибудь уже юзал Delphi 2007 или нет?
Ведь на сайте компании CodeGear продукт уже вовсю продается и отзывы там уже кое-какие есть.
И что вы скажете про покупку данного продукта, стоит ли покупать сейчас или подождать до лета,
до выхода обновлений??

Ответ на »сообщение 187« (Бел Амор)
___________________________

По моему сделано хуже, чем предыдущий лого... Предыдущий мне больше нравился

Ответ на »сообщение 199« (Banderas)
___________________________

Это если они обе в utf-8 (а как быть со строковыми константами или строковыми литералами - они ведь в ansi
Если в настройках Project | Options | Compiler | Codepage поставить 65001 - все строковые константы будут сохраняться в utf8 формате.

Опять же о литералах. Да и с комбинированными символами не все гладко :)
Что именно не гладко?

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

Ответ на »сообщение 198« (Aleg Azarousky)
___________________________

Ответ на »сообщение 197« (Banderas)
___________________________
Не так много как кажется.



1. UTF-8 хорош тем, что все латинские буквы, цифры, пробел, знак завершения строки (#13), табуляция (#10), и вообще все символы #0..#127 в нем полностью соответсвуют представлению в обычных Ansi строках. Поэтому везде в коде, где предполагается наличие в строках только #0..#127 (ASCII) - его не нужно патчить! (Software designed for traditional extended ASCII character sets can generally be used with UTF-8 with few or no changes)

с этим я согласен



2. Конкатенация двух utf8-строк также дает правильную utf8-строку.


Это если они обе в utf-8 (а как быть со строковыми константами или строковыми литералами - они ведь в ansi


3. Поиск utf8-подстроки в utf8-строке никогда не даст ложных срабатываний. И для этого их не надо преобразовывать в wide. http://en.wikipedia.org/wiki/Utf-8 (Rationale behind UTF-8's design): ...byte-wise sub-string matching can be applied to search for words or phrases within a text.

Опять же о литералах. Да и с комбинированными символами не все гладко :)


4. Сортировка utf8-строк по алфавиту можно выполнять без промежуточного преобразования utf8-wide, точно также как и при сортировке ansi1 < ansi2. А значит патч здесь не нужен.

Неправда полностью - такая сортировка будет бредом.


Наибольшие проблемы вызовут только места, где идет обращение к конкретному символу строки по индексу s[i] - это нужно патчить. Ну и определение длины строки тоже.

согласен

Ответ на »сообщение 197« (Banderas)
___________________________
Не так много как кажется.

1. UTF-8 хорош тем, что все латинские буквы, цифры, пробел, знак завершения строки (#13), табуляция (#10), и вообще все символы #0..#127 в нем полностью соответсвуют представлению в обычных Ansi строках. Поэтому везде в коде, где предполагается наличие в строках только #0..#127 (ASCII) - его не нужно патчить! (Software designed for traditional extended ASCII character sets can generally be used with UTF-8 with few or no changes)

2. Конкатенация двух utf8-строк также дает правильную utf8-строку.

3. Поиск utf8-подстроки в utf8-строке никогда не даст ложных срабатываний. И для этого их не надо преобразовывать в wide. http://en.wikipedia.org/wiki/Utf-8 (Rationale behind UTF-8's design): ...byte-wise sub-string matching can be applied to search for words or phrases within a text.

4. Сортировка utf8-строк по алфавиту можно выполнять без промежуточного преобразования utf8-wide, точно также как и при сортировке ansi1 < ansi2. А значит патч здесь не нужен.

Наибольшие проблемы вызовут только места, где идет обращение к конкретному символу строки по индексу s[i] - это нужно патчить. Ну и определение длины строки тоже.

Ответ на »сообщение 196« (Aleg Azarousky)
___________________________

Ответ на »сообщение 195« (Banderas)
___________________________
Да, я тоже понимаю минусы utf8vcl. Все зависит от мастерства его разработчиков. Если они сделают все необходимые патчи правильно, для прикладного программиста все будет абсолютно прозрачно - везде в VCL в качестве Ansi strings используем UTF-8 strings, обо всем остальном думает utf8vcl.

Слишком много патчей нужно сделать чтобы было абсолютно прозрачно - системные Pos, конкатенацию, обработку строковых литералов, обращение к i-му элементу строки, Length, функции из SysUtils, работа с датасетами. Кроме того, слишком часто, к сожалению, строку рассматривают как Pointer (PChar) - двигая указатели по ней - вырезая, вставляя символы как байты. utf8 явно не подойдет для прозрачной замены. Подойдет только WideString + автоматическая замена вызовов всех функций (и операторов) на юникодные эквиваленты (включая PWideChar), а это приемлемым способом может сделать только CodeGear. А TNT чем лучше - тем что ты сам управляешь переводом проекта на юникод.

Ответ на »сообщение 195« (Banderas)
___________________________
Да, я тоже понимаю минусы utf8vcl. Все зависит от мастерства его разработчиков. Если они сделают все необходимые патчи правильно, для прикладного программиста все будет абсолютно прозрачно - везде в VCL в качестве Ansi strings используем UTF-8 strings, обо всем остальном думает utf8vcl.