К вопросу о кодировке WordPress
Как известно, для того, чтобы WordPress нормально работал, требуется единая кодировка базы данных и самого блога. Абсолютное большинство проблем, связанных с WordPress (установка и настройка) напрямую зависят от соответствия этих кодировок. Объясняется это очень просто: получив данные, WordPress сохраняет их в базе данных в той же кодировке.
Собственно, так поступают (наверное) все «движки». И это вполне нормально и очевидно.
На данный момент существуют две серьезные проблемы.
Первая - использование AJAX. Нравится он кому-нибудь или нет, но эта технология неизбежно будет развиваться и внедряться в WordPress. С точки зрения пользователя, AJAX очень удобен, поскольку не требуется перезагружать страницы для обновления данных. В WordPress'е AJAX используется, например при добавлении новой рубрики в редакторе; для удаления (с анимацией) рубрик, ссылок, записей и т.д.
Проблема здесь в том, что AJAX будет корректно работать только в UTF-8. Так уж он устроен. По этой причине, если мы хотим его полноценно использовать, нужно либо использовать UTF-8, либо придумывать различные функции кодирования/декодирования кодировки блога в/из UTF-8.
Пока это была единичная функция (добавление рубрики), то это можно как-то обойти. Но, с выходом WordPress 2.1, ситуация изменилась. AJAX используется шире, включая и работу с т.н. автосохранением. Для корректной работы этих новшеств требуются не просто исправления, а большие «костыли», которые не так и просто реализовать, не говоря уже о поддержке в будущих версиях. Такой подход, конечно же очень сложен и неоптимален.
Вторая проблема является чисто технической: база данных MySQL должна уметь корректно работать с юникодом (UTF-8). А это возможно только начиная с версии 4.1. То есть, даже если мы решим использовать UTF-8 (тем самым решая проблему №1), то сталкиваемся с тем, что не каждый хостер может предложить качественную работу базы данных с юникодом. Кроме этого, на русскоязычных хостингах, как правило, кодировка WINDOWS-1251 используется по умолчанию. Если не знать эти нюансы, то возникают проблемы при работе с WordPress. Например, выпадающие буквы «ш» и «и» стали уже «классикой» такого рода проблем.
Я неоднократно заявлял, что кодировка блога должна быть в кодировке базы данных. Это как аксиома. Но похоже, я нашел способ заставить WordPress работать с любой кодировкой базы данных. Грубо говоря: кодировка базы данных теперь не имеет значения.
Получается, что становится некритичным версия MySQL (>4.0.0): теперь нам не нужно использовать команды «SET...» для управления кодировкой базы данных.
Пока мне удалось реализовать этот алгоритм на тестовом блоге (WordPress 2.1) и никаких проблем не замечено. Пока я решил не выкладывать и не публиковать готовые файлы, поскольку нужно отработать еще несколько вопросов. В частности, я еще не до конца продумал процесс обновления блогов: для тех, кто работал в WINDOWS-1251, ничего менять в БД не придется, а для тех, кто использовал UTF-8, но захочет использовать кодировку БД сервера (WINDOWS-1251), могут возникнуть различные проблемы.
Правда пока только теоретические, поскольку я реализовал автоматическое определение кодировки - то есть блог сам будет принимать решение в какой кодировке хранятся данные в базе данных. На тестовом блоге, где изначально стояла кодировка UTF-8 (соответственно и записи были в этой же кодировке), после перехода на WINDOWS-1251 не было замечено ни одной ошибки. (То есть одни данные записывались в UTF-8, а другие в WINDOWS-1251). Но для окончательного вывода о нажедности автоопределения требуется еще тестирование.
Пока что результаты более, чем обнадеживающие. При этом не потребуется вносить никаких «костылей» в сам «движок» и не нужно будет переделывать функции плагинов и шаблонов (если, конечно они работают через wpdb).
После отработки основных вопросов я планирую выпустить WordPress 2.1 (своей сборки) для тестеров.
Постоянная ссылка: http://maxsite.org/?p=182
Версия для печати
