Іноді при імпорті готової бази даних ми стикаємося з необхідністю змінити її кодування (будь то cp1251 або latin1 або ще щось) на utf8. При цьому потрібно міняти і кодування самої БД MySQL і всіх її таблиць і полів. Вручну, зрозуміло, це безглузда витрата часу. Як же налаштувати відображення даних з бази в правильному кодуванні?
Спосіб 1. Якщо немає часу вникати, треба зробити швидко!
Нехай, наприклад, наші таблиці в базі мають кодування latin1. а дані - cp1251. Робимо слеующее:
- експортуємо БД з кодуванням latin1;
- (*) Конвертуємо дані (див нижче приклади скриптів iconv) з cp1251 в utf8; (Якщо дані без українських символів, то напевно можна пропустити);
- замінюємо в дампі все, що пов'язано з latin1 на utf8 за допомогою пошуку та масової заміни по всьому дампи БД;
- створюємо нову базу в utf8 або видаляємо все таблиці зі старої бази;
- розгортаємо (імпортуємо) дамп вже з даними в utf8 в нову базу.
* - Наступний скрипт знаходить всі файли в поточному каталозі з розширенням * .java. перекодовує їх в UTF-8 і результат копіює в папку res
перекодування всіх файлів в директорії з їх заміною
або файли необхідного типу і рекурсивно (в прикладі txt файли):
або так (рекурсивне перекодування всіх файлів html):
Спосіб 2. Хочеться розібратися що до чого!
Кодування БД MySQL - бувають правильні - ті які нам підходять і неправильні - які нам не треба. Якщо у вас сайт російською мовою, а для вашої бази даних виставлена кодування latin1, значить це другий варіант - нас це кодування не влаштовує. Тобто нам потрібна інша кодування - cp1251 (рідна кодування Віндовс) або utf-8 (в даний час швидко набирає обертів у використанні). Чому в більшості випадків використовується latin1 - а причина напевно в тому, що MySQL при установці за замовчуванням вказує кодування latin1 для новостворених БД і скоріше за все тому, що розробники живуть і кодят в Швеції. І якщо при установці і / або налаштування не спромоглися змінити, то такою вона і залишиться за замовчуванням (до речі можна напевно взяти на замітку - якщо ваш хостер створює вам БД з кодуванням за замовчуванням в latin1 то можна припустити що він не змінював умовчання, а це в свою чергу може свідчити про невисокий рівень кваліфікації або йому просто лінь, що до речі теж є дуже погано ...). Але справа не в замовчуванні і хостингу, а в можливих проблемах. Так сайт буде працювати і текст буде показуватися нормально - але наприклад при пошуку видаватиме зовсім не те що просиш.
Я зіткнувся з проблемою неправильної кодування при налаштуванні joomla, також при перенесенні з одного сервера на інший БД торрент трекера, ну і власне всюди де вона спочатку неправильно налаштована.
Якщо піти почитати документацію, то можна припустити що нам треба ось це
If you want to change the table default character set and all character columns (CHAR, VARCHAR, TEXT) to a new character set, use a statement like this:
ALTER TABLE tbl_name CONVERT TO CHARACTER SET charset_name;
Але якщо почитати далі
Warning: The preceding operation converts column values between the character sets. This is not what you want if you have a column in one character set (like latin1) but the stored values actually use some other, incompatible character set (like cp1251). In this case, you have to do the following for each such column:
ALTER TABLE t1 CHANGE c1 c1 BLOB;
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET cp1251;
Тобто просто конвертувати у нас не вийде, треба спочатку привести до двійковим даними. Тобто все таки можна. Але! Треба виконати цей запит для кожного стовпця в кожній таблиці. Якщо це робити вручну то можна зламати клавіші так довго доведеться писати запити.
Після довгих пошуків і мук остаточний варіант виглядає так:
1. Дізнаємося в якому кодуванні лежать наші дані в БД
Відкриваємо phpmyadmin, вибираємо нашу БД і дивимося на стовпець Порівняння для таблиць - в моєму випадку це - latin1_swedish_ci.
Тобто у мене стоїть latin1_swedish_ci (Шведський, нечутливий до регістру) - питається навіщо мені для російськомовного сайту зберігати дані в шведській кодуванні?
2. Збереження дампа (бекапа) в кодуванні latin1
Це треба провернути так що б не вийшло не Новомосковскемое м'ясо. Робиться в консолі сервера
user - ім'я користувача для доступу до БД
password - пароль цього користувача
bdname - ім'я бази для якої ми робимо дамп
-default-character-set = latin1 до цього ключа особливу увагу - після знака одно треба писати кодування вашої БД.
3. Перекодування дампа в потрібне кодування і з потрібними параметрами
Призначення ключів наступне:
-f ISO-8859 - конвертувати з кодування ISO-8859 (ви можете запитати чому iso-8859-1 а не latin1, тому що це одне і те ж, та й врахуйте що у вас може бути інша кодування)
-t UTF-8 - в кодування UTF-8
dump_bdname.sql - файл який ми будемо конвертувати
dump_bdname_utf8.sql - результати запишуться в цей файл
Цією командою ми все що є в latin1 переробляємо в utf8.
Також в разі проблем можна запустити з ключем -c (пропускати на виведення неприпустимі знаки).
(Варіант для Віндовс - можна відкрити наприклад через Notepad ++ натиснути виділити все (Ctrl + A), вирізати (Ctrl + X), потім вибрати Кодування - convert to UTF-8 і вставити (Ctrl + V).)
4. Розстановка правильного DEFAULT CHARSET
Отже у нас є дамп, причому в потрібній нам кодуванні. Але в ньому так само є записані директиви SET NAMES codepage; і DEFAULT CHARSET codepage;
Запуск наступної команди замінює в дампі всі згадки latin1 на utf8
(Варіант для Віндовс - знову таки в Notepad ++ через пошук знайти і замінити всі latin1 на utf8)
5. Відновлення бази даних з конвертувати дампа
Цією командою ми заливаємо такою як нам треба дамп в нашу нову таблицю (яку попередньо треба створити)
Після цього можна спокійно користуватися нашою базою, яка тепер в правильному кодуванні.
PS: Це все можливо якщо у вас є доступ до shell сервера (ssh).
Вітання! українські написи в футере зроблені за допомогою модуля або в тілі шаблону?