|
ru.cgi.perl
- RU.CGI.PERL ------------------------------------------------------------------
From : Dmitry Koteroff 2:5020/400 18 Jul 2002 19:31:23
To : Andrey Sapozhnikov
Subject : Re: обработка данных из формы
--------------------------------------------------------------------------------
Здравствуйте, Andrey.
18 июля 2002 года, четверг, 12:55. Вы написали:
>> Думаю, MySQL вставит это дело корректно в любом случае, потому что, в
>> отличие от типа text, поля типа blob никак не перекодируются. А байты
>> между апострофами воспринимаются, как есть (боюсь соврать, что это
>> есть в документации - но помню, где-то видел).
> Вот только между апострофами не любые байты могут быть. Для того я
> пример с UTF-8 и привел. Как нам впихнуть в blob байт 0xD0 если в UTF-8
> нет символа с таким байтом? Вариант - эскейпить все non-ASCII, скажем
> как \<octal code>. Hо все равно через задницу это. Зачем парсеру SQL
> надрываться пытаясь впихнуть десятимегабайтный объект таким образом?
Hе уверен, что в MySQL есть какой-то другой способ записи блобов. Hасчет
utf8 - это вопрос из другой области. Hу и что, что символа с таким кодом
нет?.. Ведь с MySQL как работа происходит: открываем сокет, пихаем туда
команды авторизации, а затем - пихаем SQL-запросы (вернее, БАЙТЫ
SQL-запросов, ибо никакой перекодировки и анализа на этапе передачи данных
серверу, насколько мне известно, не происходит). То, что между апострофами,
воспринимается именно как БАЙТЫ. При этом, если тип поля - text и включена
перекодировка на сервере (MySQL это коддерживает), то спострофы ограничивают
ТЕКСТОВУЮ строку. Если же тип поля - блоб (или же применяется метафункция
binary - кажется, она так называется), то содержимое между апострофами
воспринимается просто как поток байтов.
--
С уважением,
Дмитрий Котеров (dk@dklab.ru), ведущий программист (http://www.dklab.ru).
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
