Промяна на енкодинга на сайт към UTF-8 (част 2)

Това е публикация за програмисти, продължение на статията Промяна на енкодинга на сайт към UTF-8 (част 1)

Импорт на голяма база данни в cPanel споделен хостинг

Тук възможностите не са много. Ако нямаш SSH достъп до хостинга, трябва да направиш sql файла на zip и да го качиш по FTP на сървъра. Сред това създаваш новата база и пишеш писмо до поддръжката да импортне таблиците в новата база. Не всички хостинг доставчици разрешават SSH достъп.

Друг вариант е да опиташ да разделиш .sql файла на няколко части, като всяка е под 50MB.

Ако имаш SSH достъп можеш сам да направиш импорт или експорт на база, през криптирана SSH връзка със сървъра на хостинга.

Под Linux мога да направя това с една единствена команда през криптиран SSH тунел и без предварително да качвам файла на базата на сървъра 😉

Изпълнявам от моята машина и от директорията, в която се намира файла на базата db.sql командата:

cat db.sql | ssh -p 23 cpanel_user@your.site.com  mysql -u db_user -p'db_password' db_name

Стандартния порт за SSH е 22, но при някои хостинги е 23 и се подава в параметър „p“. Ако не е въведен предварително твоя публичен ключ на хостинга, тогава горната команда ще те попита за паролата за cPanel.

Това което се случва е следното: на моята машина изпълнявам cat db.sql, която почва да печата на стандартния изход всички данни от архива на базата. Подават се по криптирана връзка към машина your.site.com на SSH порт 23 и там на отдалечената машина се изпълнява команда mysql, която започва да приема данните и да ги налива в базата db_name.

Създаване на архивно копие на база данни през SSH връзка

Мога също да правя обратното действие и да си правя архиви на базата отново през криптирана връзка.

ssh -p 23 -C cpanl_user@your.site.com mysqldump -u db_user -p'db_password' db_name | gzip > db_name.sql.gz

При тази команда правя от моята машина криптирана връзка с машината на хостинга your.site.com на SSH порт 23 като -C включва компресиране на данните. Там на отдалечената машина се изпълнява командата mysqldump, която извлича описания на таблици и данни за цялата база. Ако паролата на базата данни съдържа знак ‘ той ще трябва да се напише като \’  След като данните за архива се извлекат, те започват да се предават компресирани и криптирани към моята машина, където при мен се изпълнява командата gzip, която поема данните и ги записва локално във файла архив db_name.sql.gz. Красота! 🙂

.

Продължавам историята за спасяване на сайта от част 1 (вж. линка в началото).

Ok. Базата данни е успешно качена на хостинга. За съжаление не сме приключили. За да излиза коректно кирилицата трябва първо да потърсиш в кода дали някъде софтуера прави mySQL заявка SET NAMES ‘cp1251’.

Може да потърсиш това на локалната машина, в главната уеб директория с команда:

grep -r "SET NAMES" *

Ако откриеш такова го смени на SET NAMES ‘utf8’;

Тази заявка се прави веднага след връзката с базата данни. Може да има и още една заявка:

„SET CHARACTER SET utf8“

Всъщност, би трябвало когато всичко е готово, да може да работи и без тази излишни заявки. Не се препоръчва да се ползват и може да тестваш накрая да ги изключиш.

Увери се, че всички файлове, които печатат HTML таг с charset са като този:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Сега идва веселата част – всички файлове на сайта трябва да имат UTF-8 кодиране. Това са всички файлове, които съдържат кирилица .php , .js и .tpl ако ползва темплейти. Темплейтите обикновено не съдържат текст, а само променливи като {$VAR}, но те също участват за кодирането на символите. При мен отделно имаше също и имейл темплейти.

Обикновено файловете са десетки. Може първо да пробваш една хитрост. В главната уеб директория във файла .htaccess добави на нов ред директивата: AddDefaultCharset UTF-8

Ако това не помогне, ще трябва да прекодираш всички файлове.

Бърза смяна на енкодинга на файлове под Линукс

Аз ползвам команда utf8, която сам съм написал в моя .bashrc файл в моята home директория. Тя е bash функция:

# utf8
function utf8() # convert text file from cp1251 to utf8
{
local TMPFILE=tmp.$$

if [ -f $1 ] ; then
iconv -f cp1251 -t utf8 "$1" > $TMPFILE
mv $TMPFILE "$1"
fi
}

По този начин команда utf8 file.txt ползва iconv за обръщане на енкодинга от cp1251 до utf8.

Внимание! Добра идея е да направиш резервни копия на файловете преди употреба, защото командата презаписва оригинала. Ако енкодинга на file.txt не е cp1251 например вече е utf8, тогава символите на кирилица стават нечетими.

Като имам тази команда изпълнявам:

 for i in `ls *.php`; do  if [ -f $i ]; then utf8 $i; fi;    done

Тази команда сменя бързо енкодинга на всички php файлове в текущата директория.

След като и файловете са в UTF-8 вече кирилицата трябва да се чете.  Все още обаче може да се очакват проблеми с кирилицата, ако се ползват някои стари функции и може да се наложи промяна на някои функции.

Провери във всички php файлове дали някъде се ползва функция substr като в главната уеб директория на твоята машина пуснеш търсене за:

grep -r substr *

Замени тази функция с mb_substr() и по подобен начин за всички функции като strlen, strpos, split и други от библиотеката Multibyte string като всяка функция получава префикс „mb_“.

Това ще реши проблема със странни символи ромб с въпросителна като: � и по-сериозни проблеми с неправилно сравнение и отрязване на низове.

Добра идея е да се ползва

Поставено в конфигурационен файл, който се зарежда преди другите файлове. Тази функция ще осигури правилната работа на всички mb_ функции при работа с низовe на кирилица.

 

Регулярни изрази и сравнение с кирилица.

Ако искаш да провериш дали една променлива съдържа буква на кирилица, ползвай:

if(preg_match('/[АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЬЮЯабвгдежзийклмнопрстуфхцчшщъьюя]/u',$var))

вместо

if(preg_match('/[А-Яа-я]/u',$var))

Итерация по букви на кирилица.

Ако искаш да обработиш един низ с кирилица буква по буква. Направи:

$chrArray = preg_split('//u',$text, -1, PREG_SPLIT_NO_EMPTY);
foreach($chrArray as $char){
echo $char;
}

Заключение

В резултат на всичко това имаме работещ сайт http://asl-bg.com изцяло на UTF-8. Сайтът е на повече от 12 години.

За нов сайт винаги ползвай само кодировка UTF-8 за всички файлове и базата данни.

Прочетена:2884
« Предишна публикация

Промяна на енкодинга на сайт към UTF-8 (част 1)

Преминаване на сайт към UTF-8 енкодинг Това е публикация за програмисти, описваща решаването на реален проблем. Наскоро ми се наложи да прехвърля стар сайт форум, написан на PHP и mySQL база данни към нов хостинг. Старият ... Повече информация »

Следваща публикация »

Бутони за социално споделяне на линкове v.5

Ето новата 5-та версия на JavaScript-а за социални бутони. Скриптът се предлага за безплатно ползване от Ganbox.com. За незапознатите, това са малки бутончета, които се показват в страници на твоя сайт и всеки, който посещава страницата ... Повече информация »

Напишете коментар