2 октября 2007

Возвращаясь к вопросу кодировки

Читали 3071 раз
Рубрика: Плагины и хаки
Навигация: Главная » WordPress » Плагины и хаки

В WordPress 2.2 появился дополнительный параметр конфигурации DB_CHARSET, который позволяет выполнить запрос «SET NAMES 'utf8'». Это отличное решение, поскольку раньше для этого необходимо было вручную править файл wp-bd.php и дописывать нужные строчки.

Наряду с DB_CHARSET появился и параметр DB_COLLATE, который теоретически должен влиять на параметр COLLATION_SERVER, т.н. кодировку сравнения. Если кратко, то MySQL позволяет хранить каждую таблицу, каждое поле в любых кодировках. То есть даже если база данных установлена в utf-8, то можно спокойно создать таблицу в cp-1251, а в ней поле в latin7. Параметр DB_COLLATE как раз и служит для такого управления.

Проблема в том, что разработчики WordPress так и не решили вопрос использования DB_COLLATE и по сути он сейчас вообще не используется. Точнее он задействуется только в процессе инсталяции при создании таблиц.

Поскольку для наших серверов типичным является кодировка cp-1251, то в своей сборке WordPress я добавил код, который реализует возможности DB_COLLATE. Однако существует один момент, который необходимо учитывать. Дело в том, что при создании таблиц необходимо явно указывать кодировку. То есть никакие предварительные SQL-запросы просто не работают.

Всё это приводит к тому, что те плагины, которые создают свои таблицы, создают их в кодировке по-умолчанию. Поэтому в каких-то случаях это может привести к неверной их работе.

Выход только один: нужно явно указывать кодировку при создании таблиц.

Вот пример SQL-запроса, где кодировка указана:

$createT = "CREATE TABLE db_table (
            id bigint(20) NOT NULL auto_increment,
            name varchar(255) NOT NULL default '',
            code text,
            PRIMARY KEY (id)) COLLATE utf8_general_ci";

Данный запрос создаст таблицу с кодировкой сравнения utf8_general_ci.

Что же делать в случае, если плагин не указывает кодировку? Тут есть несколько решений.

Первое и самое очевидное, это вручную прописать utf8_general_ci в коде плагина. Правда этот способ годится только для тех случаев, когда вы это делаете для себя.

Второй способ - сразу после создания таблицы (обычно после активации плагина) перейти в phpMyAdmin и вручную сменить кодировку.

Третий способ - написать функцию, которая будет учитывать кодировку, указанную в конфигурации WordPress. В своей сборке WordPress 2.3 я добавил такую функцию:

function maxsite_collate() {
	if ( defined('DB_COLLATE') ) {
		if ( version_compare(mysql_get_server_info(), '4.1.0', '>=')
			&& (DB_COLLATE != '' ) )
			$out = ' COLLATE ' . DB_COLLATE;
		else $out = '';
	}
	else $out = '';

	return $out;
}

Эта функция возвращает строчку « COLLATE utf8_general_ci» в случае, если версия MySQL старше 4.1 и константа DB_COLLATE определена.

Пример использования функции (пример из плагина Ушки) :

	if ( function_exists('maxsite_collate') )
			$collate = maxsite_collate();
		else $collate = '';

	$query = "SHOW TABLES LIKE '" . $ushki_db_table . "'";

	if(!$result = $wpdb->get_var($query)) {
		$createT = "CREATE TABLE $ushki_db_table (
		ushki_id bigint(20) NOT NULL auto_increment,
		ushki_name varchar(255) NOT NULL default '',
		ushki_code text,
		PRIMARY KEY (ushki_id)) {$collate}";
		$wpdb->query($createT);
	}

То есть вначале мы получаем строчку COLLATE в $collate, а после этого дописываем переменную в SQL-запрос.

Собственно функция maxsite_collate сделана только ради совместимости со старыми версиями WordPress, потому что в них не предусмотрена константа DB_COLLATE. Для новых версий (> 2.2) можно сразу написать:

	$collate = DB_COLLATE;

	$query = "SHOW TABLES LIKE '" . $ushki_db_table . "'";

	if(!$result = $wpdb->get_var($query)) {
		$createT = "CREATE TABLE $ushki_db_table (
		ushki_id bigint(20) NOT NULL auto_increment,
		ushki_name varchar(255) NOT NULL default '',
		ushki_code text,
		PRIMARY KEY (ushki_id)) {$collate}";
		$wpdb->query($createT);
	}