| Грабли кодировочные... |
[Янв. 25, 2007|12:51 am] |
Веселую тему довелось поколупать сегодня. Началось все с того, что ![[info]](http://p-stat.livejournal.com/img/userinfo.gif) mambaram озадачил логами Slony-I с матюками на кривые данные в базе. Еще через некоторое время показал даже глючную запись из этой базы. Оказалось, что в поле с типом varchar влез символ с кодом 0x80, который в UTF-8 никак не укладывается.
Результаты экспериментов:
1. PostgreSQL 8.1.4 считает, что это корреткный UTF-8.
2. XML::LibXML, работающий через libxml2 тоже все это скушал (данные через него импортировались).
3. utf8::valid() выдал 1 на эту строку.
4. Slony-I, iconv и PgAdmin честно такую ситуацию обругали.
Полезные выводы:
1. Все текстовые данные перед внесением в БД нужно проверять чем-то еще (iconv?).
2. Ежели к целевой кодировке в iconv добавить //IGNORE, то "левые" символы будут просто пропущены (для Text::Iconv действительно).
3. Узнал также про //TRANSLIT в iconv'е, который есть, но не работает.
Мысли:
Неужели в PostgreSQL за такое время нельзя было нормальную поддержку UTF-8 реализовать?.. |
|
|
| Comments: |
1. Все текстовые данные перед внесением в БД нужно проверять чем-то еще (iconv?).
Железно. Именно иконвом можно.
Вот только мне такой подход не нравится - фактически, придется за СУБД задачу решать. Теперь размышляю, не стоит ли пропатчить постгрес по части понимания UTF-8.
насмешил :)
PostgreSQL, PostgreSQL ... UTF-8, а у нас тут один из крупнейших провайдеров до сих пор почту только 7-bit принимает, соответссно все почти все русские письма херятся :)
Ага. По мнению Perl, вообще бывает UTF-8 и utf8.
И в юникодовых эмпиреях до сих пор воюют - как должна проходить обработка utf-8: strict или safe?
Как по мне, первый случай (что-то матерится / вымирает, встретив "неправильный символ") - глупость в среднем. В общем случае мы обычно не можем контролировать транспорт - и вполне можем получить что угодно в довесок к тексту. Разумнее было бы поведением "по умолчанию" делать сброс левых символов... | |
sleepy