Здравствуйте,

IBExpert, Firebird 1.0:

никак не пойму, как работает unicode в Interbase. Сделал домен:



В доступных мне pdfах прочитал, что это длина в символах, байтов же может поле занимать в три раза больше (в зависимости от символа, используется до трех байт на символ). Это я понял так, что используется UTF-8, где для английских букв 1 байт, для русских 2, для китайских 3.

Сделал таблицу, где одно из полей этого домена. Ввожу туда данные (пользуюсь IDExpertом и IBConcolем). И, о чудо, мне удается ввесли ровно 72 буквы, как русские, так и английские! Если я ввожу букву, например, "а" с ударением, то потом оно показывает ее как просто "а". :(

Как можно объяснить такое поведение? Эти клиенты вводят мои буквы в поле в кодировке Win1251, чтоли, поэтому их влазит в 3 раза больше? И если я посмотрю на содержимое поля как на Unicode UTF-8, у меня получится каша?

Спасибо за ответ без букв rtfm! :) К обоим клиентам справка, мягко говоря, бедная, по Firebirdу тоьлко набор pdf, не похожий на те мануалы, к которым я привык.

Ф.

Какой сложный вопрос я задал, никто не знает ответ!

Кто-нибудь пользуется unicodом-то? или это не модно? :-)))

Продолжаю дискуссию с самим собой - как "человек дождя" :)

Почитал здесь рассуждения г-на Вальдерамы (кстати, это не колумбийский футболист случайно?):

A Comparison of SQL Server and InterBase Datatypes and Some Other Issues

Насколько я понял, клиенты подключаются используя чарсет базы (у меня - win1251), может быть, поэтому ibexpert видит все текстовые поля как win1251, хоть и указано, что поля юникод_фсс.

Правда, это написано про ODBC и OLEDB, а ibexpert вроде как говорят, общается с сервером напрямую.

Ну неужели никто ничего не знает??

Ф.

Зы. Вот Вальдерама пишет: For unknown reasons to me, UNICODE in InterBase requires three bytes per character. А я-то знаю, почему! См. The Unicode HOWTO: Introduction , про UTF-8

Рассказываю, кому интересно.

Попробовал войти так называемым Database Pilotом, который с JBuilderом поставляется (программа на Javе). Драйвер JayBird. Урл с указанием кодировки:



В таблице одно поле charset unicode_fss. Так вот, если я ввожу в таблицу английские буквы, они в ibexpertе отображаются также, а если русские, то в ibexpertе они превращаются в мусор, который и скопировать сюда страшно.

Правда, второе поле, которое не юникод, а win1251, вобще не удалось заполнить.

Я так понимаю, никто из понтовых знатоков с юникодом не работает, раз никто не поддерживает топик. Единственный совет, который они дают ( здесь ) - это не писать русские буквы из "нормального" ibexpertа в хранимые процедуры: видите ли, interbase хранит их в никому непонятном и не нужном юникоде.

Такие дела.

Я еще не пробовал UPPER, но там же дальше сказано в п. 10, что the default collations for these (ASCII, NONE, OCTETS, and UNICODE_FSS) character sets are also implemented within the engine. Наверно, если есть Collation, то и UPPER будет работать (система знает, что A=а и т.д).

Когда создаешь поле UNICODE_FSS, то можно указать к нему и Collation. Но выбор только из одного пункта - UNICODE_FSS. Для русского языка, надеюсь, это будет работать, если они не поленились настроить для нелатинских языков соответсвие большая/маленькая буква. Надо будет попробовать.

(А вот например в литовском языке, если я правильно ошибаюсь, где Y идет за I, поскольку Collation только один, сортировать будет как у всех остальных западноевропейцев)

Алексей, здравствуйте,

вашу книгу купил, но до главы "Русификация" еще не дочитал. Но я понял из pdfов, которые к серверу прилагались, что в CHAR(10) поместятся 30 английских букв и других знаков из ASCII, и догадываюсь, что только 15 русских букв.

Юникод я просто люблю. Я веб-программист, и приходится делать многоязычные сайты. Если использовать юникод, смогу сделать сайт даже на коптском

И делаю все это на Джаве. Вот пока надеюсь, что Джавные драйвера будут умно работать с юникодом (пока мои надежды оправдываются моим маленьким опытом с Database Pilotом из поставки JBuilderа) - по крайней мере с теми буквами, которые передаются 2-мя байтами а не тремя.

Вот когда придется в мои UDF строки поиска на коптском передавать - вот тут мне придется постичь как оно работает до самого конца!

Спасибо, Elias,

видимо, тоже самое надо будет делать при написании UDF. Чтобы моя функция разбирала юникодную строку, мне надо будет конвертить ее, например, в двухбайтный char.

Джавный же клиент, если пользоваться JayBirdом, кажется работает корректно, как показал мой опыт (с тем же lc_ctype=UNICODE_FSS)

К сожалению, нет времени мне засесть, когда я дойду до этого, я продолжу топик, и поделимся опытом.

Ф.