Кодировка в MySQL 4.1.* и MySQL 5.* (ветка 1.4.*) Кодировка в MySQL 4.1.* и MySQL 5.* (ветка 1.4.*)
 

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Main Menu

Кодировка в MySQL 4.1.* и MySQL 5.* (ветка 1.4.*)

Started by Makc666, January 09, 2008, 12:39:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Makc666

Кодировка в MySQL 4.1.* и MySQL 5.*

Провел исследование на основание вот этого поста #112987

Вывод такой:
У Coppermine нет никаких проблем с кодировкой в MySQL 4.1.* и MySQL 5.*, если MySQL установлен правильно!

Что такое правильно уставновлен MySQL 5.* (на примере UNIX системы FreeBSD)?
Правильно, это когда MySQL при чистой установке сконфигурирован вот с такой строкой:
make WITH_CHARSET=utf8 WITH_COLLATION=utf8_general_ci

Т.е. другими словами:

  • cd /usr/ports/databases/mysql51-client/
  • make WITH_CHARSET=utf8 WITH_COLLATION=utf8_general_ci
  • make install WITH_CHARSET=utf8 WITH_COLLATION=utf8_general_ci
  • cd /usr/ports/databases/mysql51-server/
  • make WITH_CHARSET=utf8 WITH_COLLATION=utf8_general_ci
  • make install WITH_CHARSET=utf8 WITH_COLLATION=utf8_general_ci

Через phpMyAdmin можно проверить, правильно ли у Вас всё собралось и установилось.

Достаточно выполнить запрос:
SHOW VARIABLES;
или два запроса по очереди:
SHOW VARIABLES LIKE 'character_%';
SHOW VARIABLES LIKE 'collation_%';

И в ответ вы должны получить:
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server utf8
character_set_system utf8
character_sets_dir /usr/local/share/mysql/charsets/
collation_connection utf8_general_ci
collation_database utf8_general_ci
collation_server utf8_general_ci


Дальше через phpMyAdmin создаётся база со сравнением utf8_general_ci
Запускается установка галереи install.php
И всё!

Никаких проблем!

Makc666

#1
А вот если при запросе:
SHOW VARIABLES;

Переменная character_set_database не совпадает с другими переменными character_set_*, к примеру:
character_set_client utf8
character_set_connection utf8
character_set_database cp1251
character_set_filesystem binary
character_set_results utf8
character_set_server cp1251
character_set_system utf8
character_sets_dir /usr/local/share/mysql/charsets/
collation_connection utf8_general_ci
collation_database cp1251_general_ci
collation_server cp1251_general_ci





Информация ниже относится только к ветке 1.4.*. Для ветки 1.5.* читайте тут.



Вот тогда нужно применять "патч" для файла
../include/functions.inc.php
diff -crbBN include/functions.inc.php include/functions.inc.php
*** include/functions.inc.php   Tue Nov  6 07:48:00 2007
--- include/functions.inc.php   Wed Jan  9 12:44:29 2008
***************
*** 184,189 ****
--- 184,192 ----
         }
         if (!mysql_select_db($CONFIG['dbname']))
                 return false;
+                 if ($CONFIG['dbcharset']) {
+                   mysql_query("SET NAMES '$CONFIG[dbcharset]'",$result);
+                 }
         return $result;
 }


А в файле:
../include/config.inc.php
дописать строку:
$CONFIG['dbcharset'] = "";
, в которой указать кодировку базы данных галереи!

Makc666

#2
Но как правильно заметиль пользователь DJMaze в своём посте #111987

SET NAMES - это не лучший способ для использования.

Что на делает в действительности запрос SET NAMES:

Он определяет как обрабатывается запросы и результаты от/к клиенту.
В данном случае
mysql_query("SET NAMES 'UTF8'",$result);
он говорит, что строка в UTF8 и MySQL самостоятельно конвертирует данные, если база данных в кодировке latin1 или любой другой.

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

Чтобы избежать подобной ситуации нужно или работать с данными как они есть, что означает бинарные данные (utf) храняться как строка и передаются как строка (без потерь)
ИЛИ
вы конвертируете все таблицы и возможно данные в кодировку UTF (но это зависит от того, находятся ли данные уже в UTF или нет).

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

Makc666

#3
Т.к. я не хочу, чтобы данная тема превращалась во "флейм", обсуждение данного вопроса можно продолжить тут:
http://forum.coppermine-gallery.net/index.php?topic=24323.0

P.S. Я поднял данный вопрос среди разработчиков. Если разговор закончится толков, то интересные выдержки напишу обязательно.

Makc666

Документации к MySQL -> разницу между 4.0 и 4.1
http://dev.mysql.com/doc/refman/4.1/en/charset-upgrading.html
QuoteIt is important to note that the "MySQL 4.0 character set" contains both character set and collation information in one single entity. Beginning in MySQL 4.1, character sets and collations are separate entities. Though each collation corresponds to a particular character set, the two are not bundled together.
+
MySQL 5.0 Reference Manual :: 9 Internationalization and Localization :: 9.1 Character Set Support
http://dev.mysql.com/doc/refman/5.0/en/charset.html

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

Quote from: bubastic on April 15, 2008, 08:13:19 AMНе понял Вашей фразы:
Quote4. Если честно, то никак. Нужно сливать базу через phpMyAdmin. Заливать на сервер с шелом. "Конвертировать" (преобразовавывать) через командную строку на сервере, где есть доступ к шелу (это наилучший вариант). И потом заливать в "правильную" базу через phpMyAdmin обратно.

Можно поподробней?

Т.к. кодировки были напутаны, то порядок такой:

1. Вы делаете обычный экспорт (т.е. ничего не меняя в его настройках) через phpMyAdmin в формате SQL (original.sql)
2. Заливает файл на хост с шелом
3. Выполняете команды
================================================
(с) Makc666

В первом окне консоли:

mysql -u root -p

DROP DATABASE `test1`;
DROP DATABASE `test2`;

CREATE DATABASE `test1` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE DATABASE `test2` DEFAULT CHARACTER SET cp1251 COLLATE cp1251_general_ci;

use test2;

set names utf8; source /dumps/original.sql;

Во втором окне консоли:

mysqldump -u root -p --create-options --compatible=mysql40 --default-character-set=cp1251 test2 > /dumps/dump.sql

В первом окне консоли:

use test1;

set names cp1251; source /dumps/dump.sql;

Во втором окне консоли:

mysqldump -u root -p --create-options --default-character-set=cp1251 test1 > /dumps/newbase.sql

(с) Makc666
================================================
4. Получаете файл newbase.sql, который можно заливать куда угодно через phpMyAdmin.
Только нужно помнить, что базу нужно создать заранее с нужным сопоставлением.

P.S.
Всё выше перечисленно выполняется при условии:
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server utf8
character_set_system utf8
collation_connection utf8_general_ci
collation_database utf8_general_ci
collation_server utf8_general_ci


Оригинальный мой пост msg251741 и продолжение обсуждения данного сообщения