русификация

PostgreSQL 8.4.0 UTF conversion

Представим себе типичную ситуацию: есть таблица в UTF8, какой-то клиент вводит туда данные, работая, скажем, в кодировке windows-1251 и вводит, например, знак номера.

Потом другой клиент, работая уже в KOI8-R сделает по этой таблице SELECT и вместо результатов выборки увидит

ERROR: character такой-то of encoding "UTF8" has no equivalent in "KOI8R"

До версии PostgreSQL 8.1.4 выдавалось предупреждение, а три года назад это стало ошибкой, что сделало жизнь невыносимой: во многих случаях спец-символы не важны (скажем, при отладке в консоли), а работающих запросов хочется.

Начиная с 8.1.4 я делаю патчи для этой функциональности: вместо выдачи ошибки и прекращения запроса невыводимый символ просто меняется на пробел. Дошла очередь и до 8.4.0:

Патчи для старых версий тоже можно брать у меня:

Стандартный дисклеймер: если вы не знаете что такое "патч", то он вам не нужен.

P.S. Своего мнения про 8.4 пока не имею, сформирую - напишу. Пока тестирую, в бой выставлять рановато. pg_migrator не понравился, слишком уж много дополнительных условий, в которых я не уверен.

Drupal + PostgreSQL = еще один патч

В процессе попыток использования Drupal 6.5 с PostgreSQL выявилась мелкая неприятность: интерфейс к постгресу не вполне правильно эскейпит строки со спецсимволами. Постгрес хочет, чтобы ему давали в виде E '\r\n', а Друпал дает без E. Пожелание это новое, появилось в какой-то из восьмых версий, на функциональность не влияет, но противно забивать лог неизвестно чем.

Патч прилагается: drupal65-pgsql8x-patch2.diff.gz

В Drupal тоже настучал, глядишь добавят в 6.6 или там в семерку (до кучи сдал туда же предыдущий патч, от него тоже никакого вреда, кроме пользы).

Drupal + PostgreSQL: вторая попытка

Внезапно возникшее отвращение к MySQL (каменты тоже читать) заставило посмотреть на связку Drupal + PostgreSQL еще раз.

Если аккуратно, то все работает. Т.е. к core у меня и раньше претензий не было, а сломался я в модуле Backup-Restore. Сейчас - с минимальным набором 3rd-party (Tagadelic, Inline Tags, Site Menu, Pathauto, Transliteration) все вроде живет. Точнее, Transliteration не транслитерирует, но оно этого и с MySQL не делало, но всяких сообщений об ошибках и прочих безобразий пока нет,...

Лечение проблем LC_COLLATE при использовании UTF-8 в PostgreSQL под FreeBSD

Как я уже писал, при использовании UTF-8 в PostgreSQL под FreeBSD результат больно бъется: сортировка русских букв неправильная (касается это только буквы ё). Причина - в кривой locale под FreeBSD (и Mac OS X).

Естественно, на эти грабли уже много раз наступали и для PostgreSQL 8.1 существуют патчи имени Palle Girgensohn, позволяющие использовать IBM-овскую библиотеку ICU в которой все сделано правильно для безумного количества языков.

Postgresql 8.3b1 UTF conversion patch

Я уже писал (а потом писал еще), что, в силу многих причин, стандартное поведение PostgreSQL при конверсии из UTF-8 в однобайтовые русские кодировки меня не устраивает. Ну нельзя обижаться и ломаться в ситуации, когда мы, например, импортировали текст в кодировке windows-1251 с кавычками-лапками, а показать хотим его в KOI8-R, где кавычек-лапок нет.

Патч для версий 8.1.4-8.2 можно найти по ссылке выше. Для 8.3-beta1 он не подходит, поэтому пришлось сделать новый: postgres-8.3.b1-conversion.patch.gz

Это хак, правильность которого я обсуждать не желаю, ибо идеологически он неверен, но без него не работают старые приложения.

Русификация MovableType

Русификация MovableType состоит из таких шагов
  1. Русификация дат
  2. Русификация имен файлов для dirify
  3. Перевод темплейтов и системных сообщений
Первые два пункта требуют правок кода, каковые правки и были сделаны. Все действия производились над MovableType 3.33

UTF-8 и только он

Мы живем в 21-м веке, когда передача лишних байтов через всю планету не стоит вообще ничего. Работа с многобайтовыми кодировками сейчас поддержана везде, на очень старые версии браузеров закладываться смысла нет (примечание от меня, как от автора Russian...

Postgresql 8.2, UTF8 и русские буквы

В отличие от PostgreSQL 8.1.x, табличка преобразования UTF8<—>CP1251 уже нормальная, € там имеется.

Однако сама идеология осталась порочной, мне не нужны ошибки при попытке конверсии, я хочу их маскировать. Впрочем патч от 8.1.5 вполне подходит и к 8.2

Postgresql 8.1.x и UTF-8

В PostgreSQL начиная с версии 8.1.4 ужесточили правила конверсии из UTF-8 в однобайтовые кодировки. Если раньше при неконвертируемом символе было предупреждение, которое попадало в лог (или в приложение, если оно читало Warnings) и все работало, то сейчас неправильный символ приводит к ошибке и запрос не выполняется.

Тут же выяснилось, что у этих криворуких уродов таблица преобразования из/в windows-1251 неверная, там пропущен символ €. Пришлось, как водится, править.

патч для таблиц перекодировки UTF8<->CP1251 PostgreSQL 8.1.4 и 8.1.5

Заметим, что введение такой безусловной функциональности в minor-версии &mdash это моветон. Разработчики нам обещают, что в пределах minor-а все будет работать без backup/restore базы, а это нифига не так, приложения просто перестали работать совсем. Впрочем, багу с конверсией посчитали vulnerability, что вполне верно если перекодировке подвергается пользовательский ввод. Но не во всех приложениях это впрямую пользовательский ввод, более того у нас правильность символов контролируется на этапе ввода, а значит нам такая неотключаемая проверка нафиг не нужна.

Пришлось делать патч, который ее относительно safe выключает: все неизвестные символы при преобразовании UTF8->однобайтная кодировка меняются на пробел. Вот этот патч: качать. Естественно, этот патч можно рекомендовать только тем, кто понимает что делает.

Subscribe to русификация