VBsupport перешел с домена .ORG на родной .RU
Ура!
Пожалуйста, обновите свои закладки - VBsupport.ru
Блок РКН снят, форум доступен на всей территории России, включая новые терртории, без VPN
На форуме введена премодерация ВСЕХ новых пользователей
Почта с временных сервисов, типа mailinator.com, gawab.com и/или прочих, которые предоставляют временный почтовый ящик без регистрации и/или почтовый ящик для рассылки спама, отслеживается и блокируется, а так же заносится в спам-блок форума, аккаунты удаляются
Если вы хотите приобрести какой то скрипт/продукт/хак из каталогов перечисленных ниже: Каталог модулей/хаков
Ещё раз обращаем Ваше внимание: всё, что Вы скачиваете и устанавливаете на свой форум, Вы устанавливаете исключительно на свой страх и риск.
Сообщество vBSupport'а физически не в состоянии проверять все стили, хаки и нули, выкладываемые пользователями.
Помните: безопасность Вашего проекта - Ваша забота. Убедительная просьба: при обнаружении уязвимостей или сомнительных кодов обязательно отписывайтесь в теме хака/стиля
Спасибо за понимание
Открываю в EmEditor, ищу "`post`", все русскими буквами показывается.
Значит идем дальше.
Quote:
2.1. Снова открываем дамп БД и смотрим кодировку таблиц, структура и содержимое которых было записано в дамп.
тут не поняла что нужно сделать. Где там что смотреть? Я в этом вообще ничего не понимаю.
OldEr
Специалист
Join Date: Jun 2007
Награды в конкурсах:
Posts: 4,731
Версия vB: 3.8.x
Пол:
Reputation:
Мастер 4229
Репутация в разделе: 2623
0
Quote:
Originally Posted by forumok
тут не поняла что нужно сделать. Где там что смотреть? Я в этом вообще ничего не понимаю.
Quote:
Originally Posted by OldEr
Дополнение: Нажимаем Ctrl + F и вводим "CHARSET=" (без кавычек). Если значение charset отлично, от той кодировки, в которой вы сохранили дамп, тогда при импорте нужно использовать принудительное указание кодировки (читаем здесь).
Помогите, прошу. Ну никак я в эти базы в своей голове уложить не могу.
Опишу что и как.
Отображается на форуме все нормально, вот с поиском проблемы, ищет как попало.
На форуме кодировка
В базе крякозябры. Сделал дамп, там стоит CHARSET=cp1251
Нужно проделывать все как тут описано, или можно как-то средствами phpMyAdmin?
Уж очень боюсь напортачить со всеми манипуляциями, а на форуме не мало сообщений таким трудом добытых.
@J. Corvin
Глумливый Специалист
Join Date: Aug 2005
Награды в конкурсах:
Posts: 774
Версия vB: 3.8.x
Reputation:
Professional 748
Репутация в разделе: 485
4
1: Настройка кодировок в сервисе MySQL
Все нижесказанное, по пункту 1, касается только тех случаев когда Вы располагаете собственной хост площадкой, или поднимаете локальный (тестовый) сервис MySQL.
Большинство проблем с кодировками отгребается именно на этапе работы (взаимодействия) MySQL и WEB сервиса (Апач и т.п.). Именно некорректная настройка самого MySQL может в конечном итоге и дать нечитаемые дампы, и даже при нормальном отображение кириллицы на форуме - дать нечитаемые крякозябры при прямом редактировании данных в таблицах базы и т.п.
В этой статье OldEr дал очень хорошее сравнение китайцев с шотландцами говорящими вроде бы на одном англицком языке, вот примерно об этом но применительно к самому MySQL сервису и пойдет речь.
Если сервис MySQL у вас настроен правильно, т.е. так как надо. То в самом движке форума уже можно ничего и не менять, всё будет работать вполне корректно.
По умолчанию в файле настроек mysql.ini (Те самые инструкции для сервиса MySQL согласно которым он и будет работать) не так много настроек касающихся кодировок.
Поэтому Нам придется руками дописать недостающие, и исправить существующие.
В частности нас будут интересовать следующие параметры: [client] - параметры сервисов которые по отношению к серверу баз данных (MySQL) являются клиентскими.
default-character-set=utf8 и
character-sets-dir=C:/MySQL/share/charsets/ - Путь к инструкциям кодировок
[mysql] - тут описываются общие инструкции сервера MySQL
default-character-set=utf8
[mysqld] - а тут инструкции непосредственно сервиса MySQL, параметров касающихся кодировок нужно указать три:
collation-server=utf8_general_ci
init-connect="SET NAMES utf8"
character-set-server=utf8
Далее в файле следует еще немало инструкций, и тут я их описывать не буду. Т.к. во первых сабж касается кодировок, а не общих настроек сервиса. Ну, а во вторых нюансов связанных с корректной, а главное высокопроизводительной работой сервиса - масса. И каждый случай индивидуален.
И последней инструкцией, которую тоже неплохо будет указать это: [mysqldump] - тут нужно задать кодировку в которой по умолчанию будет делаться дамп баз данных с помощью встроенных средств MySQL.
default-character-set=utf8
Больше о кодировках в файле инструкций можно ничего не писать. Указанного уже вполне достаточно для корректной работы сервиса.
P.S.
Все вышесказанное описано для кодировки UTF-8 (как самой, на мой взгляд, правильно используемой для наших целей). Но параметр UTF-8 с успехом можно заменить на latin1 или на cp1251.
N.B. Только следует помнить что при работе БД в latin1 несмотря на то что кодировка форума у Вас хоть и будет cp1251, и вроде бы все будет хорошо и чудесно отображаться кириллицей как на форуме, так и в БД, но никакие функции поиска по кириллице у Вас работать НЕ будут !!!
2: Кодировки файлов форума
Зачастую при использовании кодировки UTF-8 иногда и сами php скрипты (файлы) перекодируют из ANSI в UTF-8.
Особо большой пользы в этом нет, но многие (и я в том числе) любят оставлять в файлах комментарии на Русском языке. А корректно это только в том случае если сама кодировка файла - UTF-8.
Тут начинающего кодера ждет засада, о которой лучше знать заранее, а не ломать себе мозг в поисках решения выплывших проблем.
Причина ВСЕХ ошибок вызванных использованием скриптов сохраненных в UTF-8, называется - BOM (Byte Order Mark), не поленитесь и почитайте WIKI чтобы понимать, что такое BOM.
В общем, основная суть в том, что файлы сохраненные с BOM заголовком, имеют в самом начале три байта (0xEF, 0xBB, 0xBF) которые никак не видны в текстовых редакторах !!!
В частности, зарекитесь использовать для редактирования файлов сохранённых в UTF-8 - Блокнот Windows. Эта сволочь дописывает BOM заголовок даже туда где его не было.
Все нормальные текстовые редакторы запишут файл так как он лежал. Был в UTF-8 с BOM, значит перезапишем с BOM, был без оного, значит так и запишем...
Чем вообще чреват этот заголовок и как он себя проявляет.
Прежде всего тем, что PHP - это скриптовый язык. И соответственно, прежде чем в браузер пользователю будет отдан конечный HTML код, обработается множество файлов PHP и если хоть в одном из них окажутся эти самые три лишних байта в заголовке... а окажутся они естественно до сепаратора "<?php"... то очень просто представить (а зачастую и увидеть) что происходит когда хоть один байт оказывается раньше чем: <!doctype html...
Тут и непонятое съезжание дизайна... и отказ сервера отобразить страницу т.к. с куками возникла проблема... и т.д. и т.п.
Резюмируя:
1) Используйте для верстки хорошие, продвинутые текстовые редакторы. Даже если Вам всего на минуточку нужно только файлик открыть и всего-то один символ поменять...
2) Конвертируя файлы из ASCI в UTF-8 убедитесь что Ваш конвертор имеет опцию - Запись с BOM/ Запись без BOM.
И еще. Ни в коем случае запуская пакетную обработку файлов из ANSI в UTF-8 не включайте в нее ВЕСЬ каталог /forum т.к. там окажутся и файлы XML и JS и CSS. И если последним двум конвертация в UTF-8 не слишком навредит, то раскуроченный XML заставит Вас биться в нервной истерике. Так что относитесь к процессу конвертации внимательно и подходите к этому с умом.
Last edited by J. Corvin : 06-07-2011 at 05:44 AM.
Reason: Корректировка
Дополнение № 2: возможна ситуация, когда в дампе присутствуют "кракозябры" нескольких видов, либо содержится как текст, так и "кракозябры" - это означает, что данные в Вашей БД хранятся в различных кодировках. В этом случае обрабатывать дамп нужно по частям, но это уже тема для отдельной статьи.
У меня как раз такая ситуация - присутствует и кириллица, и крякозябры. Как быть?
Обсуждение цикла статей о кодировках
