Публикации

Форумы

Как мы переходили на utf-8
 

Как мы переходили на utf-8

◄◄1 2 3 4 5 6 7 8 ►► 
Модераторы: Патрик, net1313, Predator, Perfecthus, Kapman
Автор Добавил
Offline Metaller
12.08.07 - 16:41
Metaller

Сообщений: 1059
Небольшая статья о переводе сайта на кодировку UTF-8 на личном примере.

Кому лень читать, вкратце резюмирую данную статью - кодировка UTF-8 является универсальной кодировкой, содержащей символы всех языков мира. Эта кодировка может стать тем единственным стандартом, который будет применяться на всех сайтах мира.

Мифы о проблемах, вызываемых этой кодировкой связаны лишь с неправильно настроенным ПО на хостинге. В этом случае остается либо отказаться от этой затеи, либо сменить хостинг, либо принудить хостера настроить ПО для работы с кодировкой UTF-8.

А теперь краткая инструкция.

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

2. Сохраняем полную копию нашей базы данных. Можно воспользоваться для этого утилитой phpMyAdmin, я же предпочитаю Sypex Dumper

3. Сохраняем архив на локальный компьютер, извлекаем из него *.sql файл и открываем его любым текстовым редактором, который поддерживает работу в кодировке UTF-8. Я воспользовался Notepad++

4. С дампом базы нам надо провести лишь 2 операции. В открытом файле заменить все строки "DEFAULT CHARSET=cp1251" на "DEFAULT CHARSET=utf8", что можно сделать через поиск и замену, и сохранить измененный файл в кодировке UTF-8 (для EmEditor - File - Save As - Encoding UTF-8. ). Очень важный момент! Обязательно уберите галочку Add a Unicode Signature (BOM). Это специальные 3 символа, которые добавляются для служебных целей вначале файла и очень частно доставляют множество проблем пользователям UTF-8.

5. Работа над базой данных завершена, можно загружать ее обратно на сервер с помощью phpMyAdmin или Sypex Dumper, больше с ней ничего делать не нужно.

6. Теперь необходимо изменить кодировку файлов движка. Скачайте из меню "Последние версии локализации e107" локализацию в кодировке UTF-8 (release или cvs) и залейте файлы из архива к себе на сервер, заменяя существующие. Кроме того, необходимо так же изменить кодировку файлов вашей темы и кодировку всех плагинов, которые вы используете и которые не входят в стандартный пакет е107. Строго говоря, перекодировать в UTF-8 нужно только файлы, которые содержат кирилические символы. Это самый кропотливый процесс - скачивайте нужные файлы с вашего сервера, открывайте на своем компьютере в редакторе и пересохраняйте в UTF-8 без BOM, затем закачивайте обратно на сервер.

7. Последний момент - необходимо открыть файл ../handlers/mysql_class.php найти function db_Connect и в самом конце этой функции перед последней фигурной скобкой прописать mysql_query("SET CHARACTER SET 'utf8'"); Получится примерно так
  1.                                 } else {
  2.                                         $this->dbError('dbConnect/SelectDB');
  3.                                 }
  4.                         }
  5.                 }
  6.                 mysql_query("SET CHARACTER SET 'utf8'");
  7.         }

Сохранить файл обратно на сервер. Эта строка говорит mysql серверу использовать для соединения кодировку UTF-8.

Вот и все, этого оказалось достаточно чтобы все заработало как надо. Если в каких то частях сайта вы обнаружите вместо букв знаки вопросов или еще какие-то аномалии, значит скорее всего вы не пересохранили нужные файлы в UTF-8 либо забыли при сохранении убрать галочку сигнатуры BOM.
Вернуться наверх
Сайт
Популярность сообщения: 1
Рекламный блок
VPS
Наверх

Offline DarkSpiderB
17.08.07 - 04:14
Сообщений: 40
А как быть, если на сайте используется импорт инфы с другого сайта, у них кодировка СР1251, ее каким нибудь образом ожно конвертнуть "на лету" в УТФ?
А то когда сайт на УТФе, импортируемый блок выводится абракадаброй.
Вернуться наверх
Популярность сообщения: 0
 
Offline Metaller
17.08.07 - 11:08
Metaller

Сообщений: 1059
Можно использовать обычные функции PHP для перекодировки.
Вернуться наверх
Сайт
Популярность сообщения: 0
 
Offline goodwin
18.08.07 - 22:24
Сообщений: 5
На самом деле в e107 поддержки UTF-8 нет.
Поэтому кому нужно конвертнуть, пишем $text=iconv("windows-1251"," UTF-8",$text).
И плюс
– Цитата: 
Если в каких то частях сайта вы обнаружите вместо букв знаки вопросов или еще какие-то аномалии, значит скорее всего вы не пересохранили нужные файлы в UTF-8 либо забыли при сохранении убрать галочку сигнатуры BOM.
к этому, ищем функции substr, strlen и т.п., и меняем их на mb_substr(,,, CHARSET), mb_strlen(, CHARSET) и т.п.
Все подряд конечно менять не нужно, только где текст UTF-8 проходит (например с плагином календарь можно увидеть проблемы, footer.php и т.д.)


Вернуться наверх
Популярность сообщения: 0
 
Offline Metaller
18.08.07 - 22:27
Metaller

Сообщений: 1059
Если уж вы предлагаете использовать мультибайтовые функции вместо стандартных, тогда вместо iconv нужно использовать mb_convert_encoding
Вернуться наверх
Сайт
Популярность сообщения: 0
 
Offline goodwin
19.08.07 - 02:14
Сообщений: 5
То чем конвертнуть входящий поток СР1251 в UTF-8, вобщем то не важно.

Хотел просто обратить внимание, желающих перейти на UTF-8, что в e107 нет поддержки данной кодировки. Т.е. в ряде модулей (нешел ещё в rss трансляциях (rss.php), по нему и приведу пример), обрезка текста происходит просто: substr($value['description'] ,0,150) .
И что имеем в итоге: от начала текста будет отрезано 150 знаков, но в utf-8 на одну русскую букву уходит два знака, поэтому вместо 150 русских букв, увидим чуть больше половины (если текст целиком на русском), и если скажем два знака русской буквы попадут на 150 и 151 позиции, то ещё и концовка этого текста будет заканчиваться каким нибудь квадратиком, т.к. второго знака не будет.
Если просканить движок на употребление в нем substr, то употребляется данная функция часто. Поэтому кто перейдет на utf-8 будет хоть как иметь проблемы, нужно будет выискивать все места, где substr употребляется данным образом и хакать.
Поэтому кто не особо в PHP, не рекомендую пока переходить на UTF-8, до лучших времен...

Вернуться наверх
Популярность сообщения: 0
 
Offline Metaller
19.08.07 - 19:30
Metaller

Сообщений: 1059
Функция substr употребляется конечно часто, но в большинстве случаев она используется для операции над URLами и т.п. некирилическими строками. По пальцам можно пересчитать случаи, когда это действительно доставит проблему.

Конечно можно не переходить и по старинке пользоваться национальной кодировкой, и тогда полноценной поддержки международного стандарта UTF-8 в е107 в ближайшие годы можно не ждать совсем.

UTF-8 это шаг в web 2.0, это шаг к всеобщим стандартам. Используя эту кодировку на своих сайтах и сообщая о возможных проблемах разработчикам можно сделать движок лучше.
Вернуться наверх
Сайт
Популярность сообщения: 0
 
Offline Igor&
19.08.07 - 20:33
Сообщений: 196
Ставил сразу UTF-8, проблема только в отображении месяца в online_extended_menu в теме lamb (тема для галереи). Основная тема e107v4a, в ней время от времени проскакивают непонятные символы в датах, отображение месяца в новостях и плагинах. Но никакой закономерности в появлении аномалий не видно.
Вернуться наверх
Популярность сообщения: 0
 
Offline DarkSpiderB
20.08.07 - 11:39
Сообщений: 40
– Цитата: 
iconv

– Цитата: 
mb_convert_encoding

А какая из них быстрее, чем предпочтительнее пользоваться?
Вернуться наверх
Популярность сообщения: 0
 
Offline Metaller
20.08.07 - 12:11
Metaller

Сообщений: 1059
У меня на хостинге первая не поддерживается, пользуюсь второй, хотя думаю особой разницы между ними нет.
Вернуться наверх
Сайт
Популярность сообщения: 0
 
◄◄1 2 3 4 5 6 7 8 ►► 
Как мы переходили на utf-8

Перейти:  Вернуться наверх