Каков правильный способ для плагинов создавать таблицы со специальными соображениями кодировки / сопоставления?

Я использую WordPress> = 3.8. Значения charset / collation по умолчанию в wp-config.php:

define('DB_CHARSET', 'utf8'); define('DB_COLLATE', ''); // Becomes utf8_general_ci 

Я в ситуации, когда utf8_general_ci будет адекватным , но что-то более конкретное ( utf8_danish_ci ) всегда сможет лучше описать мои данные. Кроме того, данные, которые извлекаются из внешнего источника, всегда будут UTF-8.

Я разрабатываю плагин, который создает некоторую таблицу

 CREATE TABLE plugin_table( some_id INT NOT NULL, some_data VARCHAR(100) NOT NULL, PRIMARY KEY (some_id) ) ENGINE=InnoDB; 

Каков правильный способ обработки кодировки и / или сортировки?

Одним из решений является использование вышеприведенного утверждения, возвращающегося к глобальной конфигурации. Как уже упоминалось, это будет работать в моей ситуации, и с точки зрения разработчика я думаю, что разумно потребовать utf8mb4 либо utf8 либо utf8mb4 .

Другое решение – явно установить настройки кодировки / сортировки:

 ...) ENGINE=InnoDB [DEFAULT CHARSET=utf8] [COLLATE utf8_danish_ci]; 

Это позволит мне настроить таблицу наиболее подходящим образом для хранения данных, которые я должен хранить, и при тестировании я подтвердил правильность сравнения буквы Å , которая обрабатывается по-разному с помощью utf8_general_ci и utf8_danish_ci . Это, похоже, работает, но я не знаю, хорошая ли это или плохая практика, и, в частности, я не знаю, может ли это вызвать осложнения в другом месте (например, следует ли изменять настройки при запросе таблицы?).

У этого вопроса есть несколько кузенов, но это не похоже на дубликат. В ближайшем ответе также упоминается явный метод выше, с комментарием, что может быть более целесообразным использовать значения по умолчанию «поэтому пользователь может переопределить их, если у них есть веские причины».

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

Важно понимать, что никогда не будет «веской причины» использовать не-UTF-8. Что касается сортировки, вопрос менее ясен.

Вопрос сводится к следующему: учитывая некоторую конфигурацию ядра, отличную от UTF-8, которая будет считаться неподдерживаемой, следует ли мне предпринять шаги для правильного поведения моего плагина?

Solutions Collecting From Web of "Каков правильный способ для плагинов создавать таблицы со специальными соображениями кодировки / сопоставления?"

Я думаю, что эта проблема обрабатывается WooCommerce в их плагине. Он также создает свои собственные таблицы, и именно так они заботятся о части Collation. (Я имею в виду файл class-wc-install.php WooCommerce). Они написали следующий код в функции create_tables

 global $wpdb; $collate = ''; if ( $wpdb->has_cap( 'collation' ) ) { if ( ! empty($wpdb->charset ) ) { $collate .= "DEFAULT CHARACTER SET $wpdb->charset"; } if ( ! empty($wpdb->collate ) ) { $collate .= " COLLATE $wpdb->collate"; } } 

И тогда эта переменная $ collate добавляется в конце запроса CREATE TABLE .

Поэтому в этом случае запрос может выглядеть так:

 CREATE TABLE plugin_table( some_id INT NOT NULL, some_data VARCHAR(100) NOT NULL, PRIMARY KEY (some_id) ) $collate; 

Поэтому они обнаруживают WordPress's Collate и charset и добавляют их.

Надеюсь, поможет 🙂