Проблемы с кодировкой

[GoogleCodeExporter]

Проблемы с кодировкой. JVCL'овский DBGrid 
отобразил кучу вопросиков вместо 
кириллических символов, хотя данные 
получены от TZTable, который наследник TWideDataSet, 
т.е. поддерживающий Юникод датасет. Да и 
таблицы все в базе созданы с 
использованием utf8 collation general case insensitive. В чём 
же дело?

Original issue reported on code.google.com by xcentric.starcraftfan@gmail.com on 31 Dec 2010 at 8:07

[GoogleCodeExporter]

В качестве временного решения было 
установлено свойство соединения "codepage=cp1251".
Это ужасно, но придётся оставить так ддо 
тех пор, пока не будет обнаружено иное, 
более адекватное решение. Нужно как-то 
заставить всё работать с UTF-8.

Original comment by xcentric.starcraftfan@gmail.com on 2 Jan 2011 at 7:27

• Changed state: Fixed

[GoogleCodeExporter]

Что ж, обнаружен потенциальный источник 
проблемы.
Ошибка в моём коде ДНК. Ибо RTFM.
Кодировка для всех создаваемых схем (БД) 
задаётся UTF-8 (прописано в SQL-скриптах), 
соответственно все таблицы её наследуют 
(должны, по крайней мере).

А Delphi, начиная с версии 2009, использует для 
строк по умолчанию свой тип UnicodeString, 
который ни разу не UTF-8, он недоUTF-16 !!! Как 
следствие - все VCL компоненты также 
используют этот тип. Следовало догадаться, 
т.к. Windows активно использует UTF-16LE.

Но в результатах show char set в консоли mysql не 
обнаружено utf16, там есть только ucs2, который 
тоже недоUTF-16.

Решение напрашивается само: задавать 
создаваемым схемам кодировку ucs2 и коллэйшн 
ucs2_unicode_ci.
Надеюсь, таблицы это унаследуют и всё 
заработает без вопросиков и каракулей.
Однако, это лишь надежда, поскольку UnicodeString 
!= UTF-16 != UCS-2 :(

________________________________________________________________________________
_____
ПРИЛОЖЕНИЕ 1

Тип строки по умолчанию в Delphi - новый тип 
UnicodeString. По умолчанию, тип UnicodeString имеет 
сходство с кодировкой UTF-16, той же самой, что 
используется в ОС Windows. В этом заключается 
отличие от предыдущей версии, в которой 
типом по умолчанию был тип AnsiString. Раньше в 
библиотеке Delphi RTL для обработки данных в 
формате Юникод использовался тип WideString, но 
этим типом, в отличие от типа AnsiString, не 
подсчитывалось количество ссылок, и 
поэтому он не являлся для разработчиков на 
Delphi строковым типом по умолчанию. 

Для Delphi 2009 был разработан новый тип UnicodeString, 
который объединяет возможности типов 
AnsiString и WideString. Строка UnicodeString может 
содержать как символы Unicode, так и символы 
ANSI. (Необходимо заметить, что будут 
сохранены типы AnsiString и WideString.) Типы Char и PChar 
будут преобразованы соответственно в типы 
WideChar и PWideChar.
________________________________________________________________________________
_____
ПРИЛОЖЕНИЕ 2

Q: What is the difference between UCS-2 and UTF-16?

A: UCS-2 corresponds to a Unicode implementation up to Unicode 1.1, before 
surrogate code points and UTF-16 were added to Version 2.0 of the standard. 
This term should now be avoided.

UCS-2 does not define a data format, because UTF-16 and UCS-2 are identical for 
purposes of data exchange. Both are 16-bit, and have exactly the same code unit 
representation.

Instead, "UCS-2" has sometimes been used in the past to indicate that an 
implementation does not support supplementary characters and doesn't interpret 
pairs of surrogate code points as characters. Such an implementation would not 
handle processing like character properties, codepoint boundaries, collation, 
etc. for supplementary characters.

Original comment by xcentric.starcraftfan@gmail.com on 4 Jan 2011 at 4:49

• Changed state: Accepted

[GoogleCodeExporter]

Установка создаваемым схемам кодировки ucs2 
и коллэйшна ucs2_unicode_ci не помогла.
Задание "codepage=ucs2" в TZConnection.Properties увенчалось 
эксепшеном.
Идей больше нет.

Original comment by xcentric.starcraftfan@gmail.com on 25 Jan 2011 at 11:33