Смена кодировки сайта на UTF-8 (часть 1) | ВесьТоп создание и продвижение сайтов

Поддержка сайта

Высокие позиции в поисковой системе, на прямую зависят от развития вашего сайта.

Продвижение сайтов

Эффективность стратегий продвижения подтверждается сотрудничеством с крупными клиентами и отзывами о нашей работе.

Создание сайтов

Мы делаем сайты быстро, недорого и профессионально. От работы с нами, у вас останутся только положительные эмоции.

Смена кодировки сайта на UTF-8 (часть 1)

Смена кодировки сайта на UTF-8 (часть 1)

Переход сайта на кодировку UTF-8

Это пост программиста с описанием решения реальной проблемы.

Недавно мне пришлось перенести старый форум, написанный на PHP и базу данных mySQL, на новый хостинг. Старый сайт был уничтожен ненадежным хостинг-провайдером, который, помимо баз данных, удалил также резервные копии многих сайтов. К счастью, на моем компьютере были файлы сайта и старая копия базы данных. Все современные хостинг-хосты используют кодировку UTF-8, что обеспечивает плавное отображение кириллицы. Мой архив таблиц базы данных представлял собой текстовый файл .sql, который из-за особенностей старого хостинга был в странной кодировке, которая вместо кириллических символов содержала такие символы, как: ëàñóâàé

Я пользуюсь услугами двух крупнейших хостинг-провайдеров в Болгарии и сначала обратился за помощью к одному, затем к другому, но оба сказали, что не могут помочь, потому что при экспорте данных была допущена ошибка. Однако я продолжал пробовать и читать закодированные тексты, которые помню по памяти. Например, на форуме подписей пользователей я вскоре увидел, что каждому болгарскому символу соответствует ровно один из этих странных с рябью и точками сверху. Например:

Оптимизация Google — Оптимизация для поисковых систем Google — Легко найти свой веб-сайт
жизнь, вселенная и жизнь, вселенная и все остальное

Это был хороший знак, потому что это означает, что при такой кодировке нет потери данных. Недавно я обнаружил, что кодировка — это расширенные наборы символов ASCII — ISO_8859-1 (или ISO Latin 1).

Изменить кодировку файла

В Linux есть команда iconv, которая легко меняет кодировку файла. Например:

iconv -f cp1251 -t utf8 db.sql gt; db-new.sql

Из файла db.sql в CP1251 при кодировании создается новый файл db-new.sql в кодировке UTF-8.

Это здорово, но у меня это не сработало, и я получил такие ошибки, как:

iconv: недопустимая последовательность ввода в позиции 114

Эта ошибка означает, что iconv достигает символа, который не может понять, и останавливается на нем. Есть опция -c, которая может указать программе игнорировать неизвестные символы и продолжить до конца файла.

У меня это не сработало и усугубило ситуацию — исчезли большие части файла.

Проверка кодировки файла в Linux выполняется командой:

файл -i db.sql

Я начал детально просматривать данные. Текстовый файл .sql, содержащий все таблицы и данные, имел размер около 270 МБ, что является проблемой для многих текстовых редакторов. В Linux рекомендуется открывать похожие файлы из консоли с помощью команды less. Например:

меньше db.sql

Он легко обрабатывает огромные текстовые файлы даже при быстрой прокрутке или поиске. Задержка возникает только при быстром возврате по тексту.

С программой less я понял, в чем проблема — было смешанное кодирование. Некоторые таблицы базы данных были в кодировке cp1251, другие — в latin1. Вот почему iconv не работал, как и другие подобные программы, которые я пробовал.

И тогда мне пришла в голову умная идея (и, вероятно, единственно возможная) сделать таблицу соответствия символов. Мне нужно было найти соответствующую букву в файле .sql для каждой буквы в кириллице, в верхнем и нижнем регистре. Затем я заменю каждый странный символ на соответствующий в кириллице, тем самым изменяя только буквы с кодировкой Latin1, не затрагивая буквы в cp1251. Затем осталось перейти на UTF8.

Я использовал здесь таблицу http://cstein.kings.cam.ac.uk/~chris/shtools/xterm/charsets.utf8.txt

В первой таблице последние 4 строки — это прописные и строчные буквы кириллицы, которые присутствуют в моем файле .sql.

Я создал таблицу сопоставления и создал новый файл с подстановочными знаками. И, конечно же, это случилось не в первый раз. Я искал, где я был неправ, и эта таблица http://unicode-table.com/en/sections/cyrillic/ напомнила мне, что есть несколько дополнительных букв кириллицы, которые мне нужно пропустить в таблице сравнения. Наконец я пришел:

sed ‘s / À / А / gs / Á / Б / gs / Â / В / gs / Ã / Г / gs / Ä / Д / gs / Å / Е / gs / Æ / / gs / Ç / З / GS / È / I / GS / É / J / GS / Ê / K / GS / Ë / L / GS / Ì / M / GS / Í / H / GS / Î / O / GS / Ï / P / GS / Ð / Р / gs / Ñ / С / gs / Ò / Т / gs / Ó / У / gs / Ô / Ф / gs / Õ / Х / gs / Ö / Ц / gs / × / Ч / gs / Ø / Ш / gs / Ù / Щ / gs / Ú / Ъ / gs / Ü / Ь / gs / / / Ю / gs / ß / Я / gs / à / а / gs / á / б / gs / â / в / gs / ã / г / GS / ä / д / gs / å / е / gs / æ / ж / gs / ç / з / gs / è / и / gs / é / й / gs / ê / к / gs / л / л / gs / ì / м / gs / í / н / gs / î / о / gs / ï / п / gs / ð / р / gs / ñ / с / gs / ò / т / gs / ó / у / gs / ô / ф / gs / õ / х / gs / ö / ц / gs / ÷ / ч / gs / ø / ш / gs / ù / щ / gs / ú / ъ / GS / ý / ь / gs / þ / ю / gs / ÿ / я / g ‘db.sql gt; db-new.sql

Эта замечательная команда из Linux заменяет каждый символ после s / на соответствующий символ до / g в файле db.sql с очень хорошей скоростью. Результат сохраняется в файле db-new.sql.

Я открыл файл db-new.sql, и все выглядело нормально — база данных сохранена! Поспешил похвастаться в Facebook группе Программисты ?????? Я не знал, что у меня еще много работы ??????

Создание базы данных UTF8

Чтобы все в порядке с кириллицей, включая сортировку по алфавиту, все в базе данных mySQL должно быть в кодировке UTF8. Он начинается с создания новой базы данных с сопоставлением utf8_bin, и каждая таблица должна быть в сопоставлении utf8_bin. Важно отметить, что если база данных не была в этом сопоставлении, когда вы ее создавали, и вы изменили ее после того, как в ней уже есть таблица, это обычно не помогает. Определения таблиц должны заканчиваться на ENGINE = MyISAM DEFAULT CHARSET = utf8 COLLATE = utf8_bin;

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

Помимо таблиц, каждый столбец, содержащий кириллицу, должен иметь параметры сортировки utf8_bin или utf8_general_ci.

Разница между ними в том, что utf8_bin сравнивает символы как двоичные данные и используется, когда мы хотим различать строчные и прописные буквы при сортировке и сравнении.

Если мы используем utf8_general_ci, то при поиске в таблице «Vada» мы получим такие результаты, как «Vada», «vada», «VADA», «VaDa» и т. Д. Поэтому utf8_bin чаще всего используется для текстовых столбцов:

`name` varchar (255) COLLATE utf8_bin NOT NULL DEFAULT »,

Вот почему мне пришлось сделать еще несколько замен в файле .sql, чтобы изменить все определения таблиц:

sed ‘s / CHARSET = latin1 / CHARSET = utf8 / gs / CHARSET = cp1251 COLLATE = cp1251_general_cs / CHARSET = utf8 COLLATE = utf8_bin / gs / CHARSET = cp1251 COLLATE = cp1251_general_ciET / CL8 = cp1251_bulgarian_ci / CHARSET = utf8 COLLATE = utf8_bin / gs / набор символов latin1 / набор символов utf8 / gs / CHARACTER SET latin1 / набор символов utf8 / gs / сопоставление latin1_bin / сопоставление utf8_bin / gs / COLLATE latin1_fbin / сопоставление / collate utf8_bin / gs / collate cp1251_bulgarian_cs / collate utf8_bin / gs / collate cp1251_general_cs / collate utf8_bin / g ‘db-new.sql gt; db-utf8.sql

Здесь, в файле db-utf8.sql, есть описания таблиц и данных, которые находятся в UTF-8. Сам файл db-utf8.sql также имеет кодировку UTF-8. И новая база данных была создана с сопоставлением UTF-8. Осталось импортировать файл в базу. Конечно опять возникла проблема ?????? Размер файла составлял около 270 МБ. Большинство хостинг-провайдеров имеют ограничение на импорт файлов размером 50 МБ.

Продолжение следует … (подпишитесь на сообщения в блоге SEO)

Продолжение в разделе Изменение кодировки сайта на UTF-8 (часть 2)

Читайте так же:
Not found

Нам доверяют

Интернет магазин