А зачем FB2.5 вставляет X перед строковой константой?
А зачем FB2.5 вставляет X перед строковой константой?
если в теле процедуры написать например _utf8 '';, то после создания процедуры отображаться это будет как _utf8 X'';.
Это зачем?
Это зачем?
Re: А зачем FB2.5 вставляет X перед строковой константой?
где отображаться? В ISQL воспроизводится? Вообще - X это префикс 16-ричного значения. Непонятно, кто и зачем им подменяет оригинал.
Re: А зачем FB2.5 вставляет X перед строковой константой?
Да, создавал процедуру в ISQL и смотрел результат там-же. X присутствует.
Re: А зачем FB2.5 вставляет X перед строковой константой?
Вдогонку. Похоже сервер не просто подставляет X, а преобразует строку:
_utf8 'ZZ' -> _utf8 X'5A5A'
_utf8 'СЏ' (это 'я') -> _utf8 X'D18F'
_win1251 'я' -> _win1251 X'FF'
_utf8 'ZZ' -> _utf8 X'5A5A'
_utf8 'СЏ' (это 'я') -> _utf8 X'D18F'
_win1251 'я' -> _win1251 X'FF'
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: А зачем FB2.5 вставляет X перед строковой константой?
Ставлю на Адриано.dimitr писал(а):Непонятно, кто и зачем им подменяет оригинал.
Re: А зачем FB2.5 вставляет X перед строковой константой?
смотрел через show или через экспорт в скрипт?mustafa писал(а):Да, создавал процедуру в ISQL и смотрел результат там-же. X присутствует.
это сразу было понятно Но вопрос "зачем" остается открытым. Чарсет коннекта какой? Если отличается от utf8/win1251, то это скорее правильно.mustafa писал(а):Похоже сервер не просто подставляет X, а преобразует строку
Re: А зачем FB2.5 вставляет X перед строковой константой?
1 SHOW
2 и дефолтный чарсет базы WIN1251 и подключения WIN1251 и всё одно для _win1251 преобразует.
2 и дефолтный чарсет базы WIN1251 и подключения WIN1251 и всё одно для _win1251 преобразует.
Re: А зачем FB2.5 вставляет X перед строковой константой?
Дмитрий, а почему нечитабельный текст это правильно?
что криминального например в: coalesce(RDB$GET_CONTEXT(...), _utf8 'пусто'), что надо это преобразовывать в hex?
что криминального например в: coalesce(RDB$GET_CONTEXT(...), _utf8 'пусто'), что надо это преобразовывать в hex?
Re: А зачем FB2.5 вставляет X перед строковой константой?
ты DDL серверу скармливаешь в кодировке подключения, например win1251. А внутри в нем есть куски в другой кодировке, указанной через префикс. Сервер текст процедуры пытается сохранить в столбце utf8, для чего перекодирует его из win1251. Это делается целиком (как блоб), без повторного парсинга. Чтобы транслитерация прошла успешно, надо гарантировать принадлежность всех символов блоба к win1251. Префиксные литералы это портят, поэтому и приводятся заранее (при парсинге) к hex-виду (сиречь: ascii, которая априори совместима с utf8). Как-то так.
Re: А зачем FB2.5 вставляет X перед строковой константой?
то есть, мораль такая - в процедурах и триггерах не писать _utf8 '...', а писать просто строковую константу. Если она написана в 1251, то она преобразуется в юникод, и будет нормально работать в коннектах как 1251, так и utf8.
В противном случае, поытка писать константы utf для использования с другими национальными кодировками может привести к проблемам. Например, пишем _win1251 '...', потом открываем коннект в win1252, и ... перекодировки нет, облом.
Грубо говоря, если начал работать с базой в utf8, и с чарсетом коннекта utf, то уже нет смысла указывать _кодировка.
p.s. могу быть неправ, только не знаю в чем.
В противном случае, поытка писать константы utf для использования с другими национальными кодировками может привести к проблемам. Например, пишем _win1251 '...', потом открываем коннект в win1252, и ... перекодировки нет, облом.
Грубо говоря, если начал работать с базой в utf8, и с чарсетом коннекта utf, то уже нет смысла указывать _кодировка.
p.s. могу быть неправ, только не знаю в чем.
Re: А зачем FB2.5 вставляет X перед строковой константой?
В приведённом примере это замена cast (получается короче и читабельней ), т.к. для этих функций объявлен чарсет NONE, а у меня независимо от чарсета подключения (воизбежание попыток перекодировки в чарсет подключения) строки в эти функции всегда передаются в utf8.
Потому как не всегда можно гарантировать что все и всегда будут подключаться только с определённым чарсетом, а перейти разом на юникод как-то не получается.
Потому как не всегда можно гарантировать что все и всегда будут подключаться только с определённым чарсетом, а перейти разом на юникод как-то не получается.