Ответ на »сообщение 84« (DRON)
___________________________
Я пока никаких сообщений на этот счет от кодгировцев не читал. Упоминание касательное Unicode было только в опросе в конце прошлого года, где спрашивали какие кодировки в VCL лучше использовать.

В новостных группах обсуждения были. Как мне кажется, будут задействованы 2 кодировки: UTF-8 удобна для сохранения информации в файлах (DFM, XML). А для манипуляции Unicode-строками - либо UCS-2 либо UCS-4. Причем как мне кажется UCS-2 предпочтительнее, поскольку, хотя она и не охватывает весь набор символов, но UCS-4 расходует память исключительно нерационально. Опять же, UCS-2 охватывает символы, входящие в Basic Multilingual Plane, которых для подавляющего большинства применений более чем достаточно.

http://en.wikipedia.org/wiki/Universal_Character_Set

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

А счетчик ссылок для WideString-ов добавят - или это в принципе невозможно?
Нет невозможно, так как их формат жёстко прописан во всяких SysFreeString,SysAllocString: там только счётчик байтов по отрицательному смещению и больше ничего.
Видимо тут два варианта:
забыть про счётчик и перейти полностью на BSTR (то есть как WideString сейчас) или
добавить какой нибудь новый тип строки, типа OleString (совпадающий с BSTR) и конвертить в нужных местах туда-сюда, как это например делается между ShortString и AnsiString.
Ну ещё какие нибудь экзотические варианты можно придумать, типа "предложенного" Loki, но я не думаю что они на это пойдут.

Всё таки интересно, как же они сделают Юникод, неужели никто ничего не слышал, поделитесь секретом... ну пожалуйста :)

А счетчик ссылок для WideString-ов добавят - или это в принципе невозможно?

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

...вобщем к тому времени когда они всё это сделают, скорее всего появится нативная поддержка Юникода в Delphi.
Честно говоря, дай боже чтоб они .NET 2.0/3.0 в Highlander реализовали в срок. Учитывая огромный кусок работы с этим. Вероятность появления там Unicode VCL я оцениваю как 50/50. Поэтому UTF-8 VCL может оказаться вполне реальной альтернативой

Ответ на »сообщение 75« (Aleg Azarousky)
___________________________
На SourceForge вчера появился интересный проект - UTF-8 VCL.
Штука действительно интересная, я как-то пытался сделать нечто подобное (после того посмотрел utf8api.dll из FooBar2000), но там проблем не меньше чем с TNT компонентами и полной прозрачности использования всё равно видимо не добиться. Нужно ведь и функции сравнения/поиска строк заменять на свои, да и идеология "один байт - один символ" используется слишком часто, вобщем к тому времени когда они всё это сделают, скорее всего появится нативная поддержка Юникода в Delphi.

Кстати, кто нибудь в курсе, как именно будет реализована поддержка Юникода в новых версиях?
Варианты:
String превратится в WideString, а API по дефолту будет транслироваться в W-версии функций или
сделают все свойства компонентов как WideString, добавят несколько классов типа TWideStrings (который уже есть в 2006) и функций типа WidePosEx, вобщем получится аналог TNT компонентов.

Например, resourcestring'и, как это ни странно, хранятся в памяти как AnsiString,
Хранится оно как раз как Юникод (в ресурсах), а преобразуется конечно в ANSI, но ничто не мешает подменить соответствующую функцию (LoadResString) и преобразовывать не в текущую локаль, а в UTF-8. В TNT успешно решается и более сложная проблема: использование PResStringRec для работы с Юникодом, смотрите Custom_System_LoadResString и CodeMatchesPatternForUnicode.
и это может быть исправлено только в компиляторе.
Определённая поддержка в компиляторе уже есть: например в Turbo можно указать в настройке "Codepage" число 65001, тогда все константы (не resourcestring) будут храниться в UTF8.

Ответ на »сообщение 79« (Денис Зайцев)
___________________________

К сожалению, подобные решения могут быть только полумерой, пока в самом языке (компилятор+RTL) не появятся соответствующие механизмы.
Например, resourcestring'и, как это ни странно, хранятся в памяти как AnsiString, и это может быть исправлено только в компиляторе.
На самом деле все реально осуществимо с существующим VCL.

С точки зрения компилятора UTF-8 строка не отличается от обычной AnsiString. Т.е. он может работать с ней аналогично, а уже как интерпретировать полученный результат - всецело ложится на прикладную программу.

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

Учитывая, что родной Unicode VCL появится не раньше чем в III квартале 2007г., использование utf8vcl может быть хорошим решением.
К сожалению, подобные решения могут быть только полумерой, пока в самом языке (компилятор+RTL) не появятся соответствующие механизмы.
Например, resourcestring'и, как это ни странно, хранятся в памяти как AnsiString, и это может быть исправлено только в компиляторе.

А меня заинтриговала объявленная поддержка AJAX. Только не очень понимал, в каком виде это сделано, а вчера в обном блоге прочитал, что это - поддержка в IntraWeb. Увы, для меня это не актуально.

Ответ на »сообщение 76« (Cepгей Poщин)
___________________________

А вот интересно, редактор в новой Delphi всё так же криво работает с русским текстом, или его сподобились исправить?

Этот баг числится открытым - видимо, не исправили. Ждём Highlander'а.

А вот интересно, редактор в новой Delphi всё так же криво работает с русским текстом, или его сподобились исправить?