|
Задавайте вопросы, мы ответим
Вы не зашли.
Ломаю голову, не знаю что делать. Итак есть сайт, на котором стали отображаться знаки вопроса вместо "И" и "Ш". Есть один дамп базы в кодировке ANSI (русский текст абракадабра). Когда я дамп перекодирую в utf-8, то русский тест становится виден за исключением "И" и "Ш"... Как победить этот косяк?
Спасибо.
Неактивен
Попробуйте сделать резервную копию в той же кодировке, что и таблица (так, чтобы
MySQL не делал перекодирований на своей стороне). После этого нужно написать правиль-
ное название кодировки в SET NAMES резервной копии (и в идеале — в командах соз-
дания таблиц) и перезалить данные из резервной копии назад в MySQL.
Неактивен
А можно по шагам? Я все-таки новичок )
Т.е. делаю дамп базы как есть... т.е. со знаками вопроса в тексте? А как сделать в той же кодировке что и таблица и какая таблица?
Неактивен
Таблица — та, в которой знаки вопроса. Можно посмотреть ее структуру:
SHOW CREATE TABLE tablename. Там будет указана кодировка, в которой
хранятся данные в этой таблице.
Можно сделать резервную копию в этой кодировке:
mysqldump --default-charset=charset >filename
Получится файлик, в котором будут данные в том виде, в котором они есть
в таблице. Если там уже знаки вопроса, то ничего сделать нельзя, т.к. они
сохранены как есть в базе. Скорее всего, однако, у Вас будет файлик с
нормальными данными (но в другой кодировке, из-за чего все ошибки и
возникают).
Неактивен
А если у меня во многих таблицах иная кодировка?
А сохранять всю базу нужно или только те таблицы, в которых знаки вопроса?
Неактивен
Тогда те, в которых битая кодировка, конечно. Лучше привести все таблицы к
одному виду — проще будет администрировать.
Неактивен
Подскажите, пожалуйста как правильно быть.
Мне передали на администрирование форум.
Задача, перенести на новый хост, обновить версию движка, установить несколько хаков.
На изначальном хосте, проблем с кодировкой не наблюдалось.
Для переноса форума, я получил архив с базой в виде бинарных файлов(если я правильно это называю - файлы access.frm, access.MYD, access.MYI и т.д...) + файлы из дериктории сайта. База большая. Весит более 1 гб. При открытии локально в MySQL менеджере, в полях таблицы, вместо русских букв кракозябры. Если не обновлять форум, то в принципе, в браузере все отображается нормально. Но после обновления, начинаются кракозябры и на форуме 
Как я понимаю, нужно исправить базу, до обновления движка...
Для этого, воспользовавшись Вашим советом, при помощи SQL запроса: SHOW CREATE TABLE tablename, выяснил, что все таблицы в ней сохранены в кодировке Latin1 
Опять-же руководствуясь Вашим советом, для пробы, я экспортировал одну из таблиц в SQL файл...
А дальше у меня ничего не получается... Вы предположили:
Если там уже знаки вопроса, то ничего сделать нельзя
у меня к счастью, вроде бы другая ситуация, так как при открытии в текстовом редакторе(AlkePAD, Notepad++ и в обычном блокноте), я вижу нормальные читабельные буквы.
Однако при импорте этого SQL файла, в UTF8 базу и заранее созданную UTF8 таблицу, при просмотре в MySQL менеджере, все равно остаются кракозябры.
Я пробовал делать преобразование как при импорте в базу, так и в Notepad++ до импорта. В Notepad++, все отображается нормально и после перекодировки.
В то-же время, мои собственные таблицы(с другого сайта), которые я создавал сам изначально, в этом же менеджере все читаются нормально.
Как правильно поступить?
И есть ещё один вопрос. Прикреплённые файлы, хранятся в этой же базе(не в файлах сайта). Я так понимаю, что преобразование, с этими файлами не пройдёт в любом-случае? Файлы испортятся?
В админке форума предусмотрен вариант переноса прикреплённых файлов из базы в папку сайта. Следует ли выполнить этот перенос? Или все же можно преобразовать и с файлами?
И если нужно вынести файлы из базы, то следует ли их после преобразования, вернуть назад?
В каком варианте будет лучше производительность? С вложенными файлами в базу или файлами в папке сайта?
Заранее большое спасибо, за помощь.
Отредактированно taravasya (11.04.2011 11:46:17)
Неактивен
Во обще не понятное что-то..
Выходит, так что если я импортирую sql файл, в кодировке Latin1, то импорт завершается нормально, но опять же с кракозябрами. Если же я преобразую его в UTF8, то импорт заканчивается ошибкой:
MySQL server has gone away
Структура таблицы создается, но данные не импортируются...
Отредактированно taravasya (11.04.2011 21:14:33)
Неактивен
Начать стоит с чтения статьи — http://sqlinfo.ru/articles/info/5.html
Проблема состоит в том, что кодировка обозначена, как latin1, но в действительности —
другая. Нужно ее угадать и прописать.
Файлы лучше хранить в виде файлов. Тогда на них не будут тратиться драгоценные
ресурсы процессора.
MySQL server has gone away говорит о том, что соединение было прервано со стороны
сервера. Возможно, сам сервер плохо собран (например, FreeBSD и падает), возмож-
но, Ваше соединение убивается со стороны хостинга. Можно попробовать сделать
изменение в несколько alterов — так, как написано в статье.
Неактивен
Да спасибо. Я прочитал эту статью... Но что то последовательное повторение, не даёт результатов.
Но после экспорта данных в кодировке Latin1, в текстовом редакторе все отображается нормально. Это показатель того, что кодировка для экспорта подобрана правильно? Или даже если всё нормально отображается в тексте, после импорта в базу, всё-равно могут возникнуть "кракозябры"?
Я воспользовался, скриптом Sypex Dumper, он сделал читабельный sql(в том же Latin1), в полученных файлах я меняю строки:
Отредактированно taravasya (13.04.2011 05:40:47)
Неактивен
Произошёл сдвиг!
Вместо
Please Help Me!!!!!!!!!!!!!!!!!!!
Отредактированно taravasya (13.04.2011 11:44:57)
Неактивен
Сделал, абсолютно, точно такой же реверанс, только в сторону cp1251.
Сделал дамп в кодировке latin1
Заменил COLLATE и DEFAULT CHARSET с Latin1 на cp1251
Файлы не стал перекодировать, так как после перекодировки, при сравнении TotalCommander, говорит что они одинаковые...
Создал базу в кодировке cp1251.
Импортировал туда дамп.
Вставил в файл с подключением такой код:
Неактивен
Кажется, Вы сами ответили на свой вопрос. SET NAMES надо делать в ту
кодировку, которую Вы (ну или Ваш сценарий) ожидает получить. Ваш
сценарий ожидает получить cp1251, а хранить данные можно и в utf8.
Неактивен
Да похоже на то... Но тем не менее, когда я пытался настроить базу в utf8, а подключение в cp1251, то кое-где у меня всё-равно проскакивали кракозябрики. В основном в тех местах, которые ранее заполнялись пользователями в админ панели. Подозреваю, что там происходило перемешивание кодировки данных из-за неправильных настроек.
Смешно, сказать но будучи сам не уверен, что всё сделал правильно, тем не-менее, вывел для себя такую формулу:
База в cp1251
Таблицы в сp1251
Если есть возможность, то добавляю в my.ini:
Отредактированно taravasya (15.04.2011 21:32:53)
Неактивен
Представьте себе книгу. Обычную бумажную. На обложке написано:
«This is a book». На каком языке напечатано содержимое? Если Вы
подумали, что на английском — Вы ошиблись, т.к. кто-то «добрый»
напечатал на русском, а обложку оставил как есть.
Так же и с форумом — Вы можете выводить данные в utf8, но когда
Вы делаете это в обрамлении cp1251 (весь остальной шаблон верстки
форума), это выглядит странно по меньшей мере.
Неактивен
Вы простите меня,.. я понимаю, это уже конечно становится похожим на флейм.. но я правда хотел бы разобраться.
Вот Вы говорите:
На обложке написано:
«This is a book». На каком языке напечатано содержимое?...
.....кто-то «добрый» напечатал на русском, а обложку оставил как есть.
----
Вы можете выводить данные в utf8, но когда
Вы делаете это в обрамлении cp1251 (весь остальной шаблон верстки
форума), это выглядит странно по меньшей мере.
Но в том то и весь фокус. Что когда у меня всё было в utf8(настройки форума согласно мануалу), настройки сервера, база,.. всё было приведено к одному знаменателю - utf8
И форум не работал! Во обще.
Когда я сделал "смешанные настройки" (см 11-й пост), то форум стал работать почти нормально. Лишь местами начиная косячить.
Когда же я теми же средствами и тем же способом, всё перевёл на cp1251(а cp1251 для булки в той же мере не стандартен как и utf8 - то-есть требовало отдельных настроек в админке), всё затикало как часики!
Вот и вопрос,.. где порыта собака?
Неактивен
С таким же успехом Вы могли бы обозначить, что данные находятся в кодировке
«китайский упрощенный». В случае, если клиент попросит тот же «китайский упро-
щенный», MySQL не будет перекодировать данные, а значит, Вы получите ровно то,
что сохранено в базе. Проблема возникает не во время обозначения, а во время
перекодирования данных. Исходя из общих соображений, однако, обозначение
данных правильной кодировкой (т.е. той, в которой они находятся реально) полез-
нее.
Неактивен
