Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 36
Добавление этой строки не поможет, если уже есть данные в кривой кодировки, а только усугубит ситуацию, так как у вас данные внутри уже будет в разных кодировках, и для приведения их в нормальный вид, уже придется по частям ковырять таблицу. И всё описанное прекрасно делается в бесплатной версии дампера.
Вообще-то там вся статья касается бесплатной версии, о платной версии только последний абзац 5 строчек и скриншот. Могу и убрать, если так режет глаза.
О, спасибо!
Паззл собран по кусочкам в одной статье. Забираю.
Паззл собран по кусочкам в одной статье. Забираю.
Вопрос, если выполнения бэкапа останавливается с ошибкой:
Что мне делать?
MySQL Error: File \'.\\ipb\\ipb_spider_logs.MYD\' not found (Errcode: 2) (D:\\www\\myhostname\\sxd\\index.php:1581)Что мне делать?
Сделать проверку таблиц MySQL, скорее всего побилась таблица.
Может помочь themanbehindthecode.com/2011/04/14/fix-myisam-myd-file-not-found-errcode2/
Может помочь themanbehindthecode.com/2011/04/14/fix-myisam-myd-file-not-found-errcode2/
Да, с таблицей я разобрался, бэкап прошел. А что делать вот с этим:
И так много раз.
?
Начало импорта БД `ipb`
Файл: ipb_2011-11-03_20-40-31.sql.gz
Notice: Uninitialized string offset: 0 (D:\\www\\myhostname.ru\\sxd\\index.php:796)
Notice: Uninitialized string offset: 0 (D:\\www\\myhostname.ru\\sxd\\index.php:805)
Notice: Uninitialized string offset: 0 (D:\\www\\myhostname.ru\\sxd\\index.php:815)
Notice: Uninitialized string offset: 1 (D:\\www\\myhostname.ru\\sxd\\index.php:833)И так много раз.
?
Эх, а я всю жизнь дампы правил с помощью iconv'a или enconv'a (из пакета enca) [правда, последний не всегда корректно отрабатывает].
А если нужно на лету, то средствами мускула:
А если нужно на лету, то средствами мускула:
select convert(convert(a using имя_кодировки_базы) using binary) from таблица;
В notepad++ можно быстрее это сделать, визуально хоть кусочек чтобы 100% убедится в верности решения.
И что вы хотели сказать этой строкой? Предлагаете вручную исправлять каждый текстовый столбец в каждой таблице?
А ну как будет выглядеть исправление таблиц того же упомянутого выше vBulletin 4 (у которого их около двух сотен).
Я же не говорю, что я прям открыл Америку, или какие-то недокументированные возможности MySQL использую, в дампере никакой магии нет, он тоже работает с MySQL используя SQL-запросы. Я просто предлагаю уже готовое решение, которое облегчает ручной труд.
А ну как будет выглядеть исправление таблиц того же упомянутого выше vBulletin 4 (у которого их около двух сотен).
Я же не говорю, что я прям открыл Америку, или какие-то недокументированные возможности MySQL использую, в дампере никакой магии нет, он тоже работает с MySQL используя SQL-запросы. Я просто предлагаю уже готовое решение, которое облегчает ручной труд.
Лично я в ручную конечно бы не правил. Я бы открыл дамп в notepad++ и нажал «кодировать в...»
А в CREATE TABLE notepad++ сам догадается кодировку поправить? Как и добавить кодировку соединения в дамп, чтобы потом данные нормально залились?
Вот тут паузу. Начать следует с того, откуда возникли кракозяблы. Готовые продукты потипу vBulletin не имеют проблем с установкой, если соблюдать требования хостинга. Все работает отлично.
Перенос? Аналогично или встроенным решением или саппорт просим слить/залить дамп в указанной кодировке. Не нужно ничего править в дампе, а то потом и получается что ничего не получается.
Да, это и к моему ответу выше относится.
Ниже я писал что не следует путать преобразование и кодировку. В предложенном мною способе никаких проблем при импорте не возникнет.Ничего править не нужно в CREATE TABLE. В поля при импорте в таблицу запишутся не кракозяблы, а нормальные символы которые я поправил в notepad++.И не важно в какой кодировке база. Я не делал преобразование, я менял кодировку.
Надеюсь не запутал вас.
Кодировку соединения или в phpmyadmin или саппорт.
Перенос? Аналогично или встроенным решением или саппорт просим слить/залить дамп в указанной кодировке. Не нужно ничего править в дампе, а то потом и получается что ничего не получается.
Да, это и к моему ответу выше относится.
Ниже я писал что не следует путать преобразование и кодировку. В предложенном мною способе никаких проблем при импорте не возникнет.Ничего править не нужно в CREATE TABLE. В поля при импорте в таблицу запишутся не кракозяблы, а нормальные символы которые я поправил в notepad++.И не важно в какой кодировке база. Я не делал преобразование, я менял кодировку.
Надеюсь не запутал вас.
Кодировку соединения или в phpmyadmin или саппорт.
Серьезно не имеют проблем vBulletin? Расскажите это тем юзерам которым я имправлял их базы…
Вообще загадочная у Вас позиция, если Вы с проблемой не сталкивались, значит она не существует.
Я что-то вообще запутался, что именно вы делаете в notepad++. Вы хотите изменить кодировку с cp1251 на utf8, или исправить несоответствие между кодировкой указанной в свойствах таблицы и кодировкой данных в них лежащих (т.е. те самые кракозябры исправить)?
Вообще загадочная у Вас позиция, если Вы с проблемой не сталкивались, значит она не существует.
Я что-то вообще запутался, что именно вы делаете в notepad++. Вы хотите изменить кодировку с cp1251 на utf8, или исправить несоответствие между кодировкой указанной в свойствах таблицы и кодировкой данных в них лежащих (т.е. те самые кракозябры исправить)?
Ага, я загадочный) Что я делаю в notepad++ все от случая. Просто нет необходимости — все прекрасно переносится обновляется. Скажите мне точную ситуацию я предложу решение, сами понимаете, глупо так просто что-то советовать.
Если я не вижу проблемы — действительно ее пока не существует. Я же не могу запариваться ситуацией, в которую возможно никогда не попаду) Если я столкнусь с vBulletin обращусь к вам)
Сдается мне просто поддержка в России у этой компании слабовата. Им не до Иванов.
Я всегда готов сдать позиции если не прав, а там сами решайте) Если хочется обозвать меня — разрешаю).
Если я не вижу проблемы — действительно ее пока не существует. Я же не могу запариваться ситуацией, в которую возможно никогда не попаду) Если я столкнусь с vBulletin обращусь к вам)
Сдается мне просто поддержка в России у этой компании слабовата. Им не до Иванов.
Я всегда готов сдать позиции если не прав, а там сами решайте) Если хочется обозвать меня — разрешаю).
А Вы допускаете, что кроме Вас есть другие люди и у них могут быть другие проблемы?) Проблемы описаны в статье, в том числе в каких случаях они возникают. Могу выложить пару php-скриптов которые воспроизводят эти проблемы, или даже просто SQL-запросы.
И вот к примеру на крупнейшем рунетовском сайте поддержки vBulletin исписали по это не существующей проблеме 27 страниц, и предлагают решать проблему хаком. Добавлением в скрипт 3-х запросов. А вариант с раскомментированием строки в конфиге лишь в конце. Притом написано, что он только для MySQLi, хотя это и не так (я ковырял исходники).
И вот к примеру на крупнейшем рунетовском сайте поддержки vBulletin исписали по это не существующей проблеме 27 страниц, и предлагают решать проблему хаком. Добавлением в скрипт 3-х запросов. А вариант с раскомментированием строки в конфиге лишь в конце. Притом написано, что он только для MySQLi, хотя это и не так (я ковырял исходники).
Нужно понять главное!
1) Есть кодировка символов и есть преобразование из одной кодировки в другую.
При смене кодировки появляются кракозяблы, при преобразовании — нет.
( меняется UTF8 на cp1251, к примеру, но текст остается читаемым) Это многие путают!
2 читать нужно в той же кодировке в какой лежат данные в базе. Лежат они в UTF8, указывайте mysql_set_charset( 'utf8' ) и читайте без проблем.
Дамперы, помоему, отошли уже. Обычные хостинги: письмо в техподдержку — тебе дамп твоей базы сделают так и зальют обратно. Это если не работает phpmyadmin или падает экспорт по непонятной причине.
1) Есть кодировка символов и есть преобразование из одной кодировки в другую.
При смене кодировки появляются кракозяблы, при преобразовании — нет.
( меняется UTF8 на cp1251, к примеру, но текст остается читаемым) Это многие путают!
2 читать нужно в той же кодировке в какой лежат данные в базе. Лежат они в UTF8, указывайте mysql_set_charset( 'utf8' ) и читайте без проблем.
Дамперы, помоему, отошли уже. Обычные хостинги: письмо в техподдержку — тебе дамп твоей базы сделают так и зальют обратно. Это если не работает phpmyadmin или падает экспорт по непонятной причине.
Дамперы, помоему, отошли уже. Обычные хостинги: письмо в техподдержку — тебе дамп твоей базы сделают так и зальют обратно.
Вы правда считаете, что на хостингах дампы делаются и заливаются чтением тикета? Вы не поверите — там тоже есть дамперы, неважно, как они называются.
Это их решения сервиса, дамперы или команды к mysqldump.exe — они могут что угодно городить, у них есть специалисты. Клиенту это все равно.
Вы думаете у всех хостеров прям такие большие спецы, которые в тонкостях MySQL разбираются? Максимум они вам сделают/восстановят дамп с помощью mysqldump, никто там не будет ковыряться в кривизне ваших кодировок бесплатно. Это не входит в их обязанности.
Так давите на меня — говорите за свой хостинг, пожалуста. Мне мой делает импорт по моей просьбе в указаной кодировке.
«Сделайте пожалуйста импорт в db в UTF-8 дамп в корне 1.sql»
Когда я это делаю, я знаю что прошу и проблем не возникало. Все возможные проблемы с импортом я на локале тестирую, потом прошу саппорт.
«Сделайте пожалуйста импорт в db в UTF-8 дамп в корне 1.sql»
Когда я это делаю, я знаю что прошу и проблем не возникало. Все возможные проблемы с импортом я на локале тестирую, потом прошу саппорт.
Скажем так у вас были описанные в статье проблемы которые помог решить хостинг? Если у вас не было проблем с кодировками, то вполне естественно, что дамп и штатными средствами отлично делается. Хотя не понимаю зачем для этого постоянно службу поддержки дергать.
Можем ради интереса сделать тестовый скрипт, который сделает пару неправильных таблиц описанных в статье, и попросите ваших хостеров их исправить. Заодно засечем сколько времени уйдет на решение проблемы вашим способом, и решение проблемы способом описанным в статье.
Можем ради интереса сделать тестовый скрипт, который сделает пару неправильных таблиц описанных в статье, и попросите ваших хостеров их исправить. Заодно засечем сколько времени уйдет на решение проблемы вашим способом, и решение проблемы способом описанным в статье.
Дорогой Zapimir, все проблемы с импортом я решаю на локале, лишь потом прошу саппорт сделать импорт в базу на сервер, подготовленного мною дампа в указанной мной кодировке.
Я же не 3 раза перед едой прошу саппорт делать импорт.
Вы пишите «который сделает пару неправильных таблиц». Ну раз они не правильные, кто виноват что кривая база вышла. Хостинг делает то что я писал и все. Суть кракозяблов как раз в том, что кто-то начал делать что-то не правильно с самого начала. Если вы используете готовые продукты, откуда там проблемы с кодировкой. Если проблемы с собственным продуктом, то это не этот блог.
Засекать время решения задачи немного неправильно. Те кто считает время/деньги пользуются готовыми продуктами по лицензии.
Я прекрасно понимаю, что с дампером пихнуть в базу дамп, быстрее чем просить саппорт.
Но это отходит все… в достойных системах есть готовые решения. Я про это писал с начала.
Я же не 3 раза перед едой прошу саппорт делать импорт.
Вы пишите «который сделает пару неправильных таблиц». Ну раз они не правильные, кто виноват что кривая база вышла. Хостинг делает то что я писал и все. Суть кракозяблов как раз в том, что кто-то начал делать что-то не правильно с самого начала. Если вы используете готовые продукты, откуда там проблемы с кодировкой. Если проблемы с собственным продуктом, то это не этот блог.
Засекать время решения задачи немного неправильно. Те кто считает время/деньги пользуются готовыми продуктами по лицензии.
Я прекрасно понимаю, что с дампером пихнуть в базу дамп, быстрее чем просить саппорт.
Но это отходит все… в достойных системах есть готовые решения. Я про это писал с начала.
Вы вообще читаете о чем пишу? vBulletin по вашему не готовый продукт? У него эта проблема из коробки. Понятное дело, что кракозябры из-за того, что кто-то где-то сделал косяк. В статье как раз решается вопрос, что с ними делать, а не кто виноват.
Я же в самом начале написал, что статья не о том как делать правильно, а о том как можно исправить проблему, которая уже случилась.
Я же в самом начале написал, что статья не о том как делать правильно, а о том как можно исправить проблему, которая уже случилась.
Дорогой Zapimir, не злитесь — я просто обычный мудак.Способ отличный.
Но vBulletin — продукт Вавилона. Он не виноват, что его полюбили в России((
Нельзя ругать хаммер, что у него налог на объем двигателя большой.
Но vBulletin — продукт Вавилона. Он не виноват, что его полюбили в России((
Нельзя ругать хаммер, что у него налог на объем двигателя большой.
vBulletin не единственный с подобными проблемами, просто это последнее, что помогал вылечить юзерам, вот и пришелся к слову. И тут не столько любовь или не любовь к России, а всё дело в том, что западные юзеры с этой проблемой не сталкиваются особо, так как кодировка по умолчанию их устраивает. А тем же американцам еще проще, у них весь алфавит на одном месте, что в latin1, что в cp1251, что в utf8.
Я думал тут будет про ALTER TABLE… CONVERT TO CHARACTER SET, а тут сделал дамп, залил дамп…
Тут как бы предлагается готовое решение. А вы предлагаете такие вещи делать, по принципу «Авось повезет», без бэкапа?
я имел в виду что есть встроенные в DB средства решения таких проблем. А «скачать дамп, подправить его, залить обратно» — это конечно универсальное решение, вместо любого DML подойдет. <sarcasm>Ну да, зачем UPDATE TABLE нужен, да еще на авось, без бэкапа :)</sarcasm>
Конечно, иногда дампы проще и/или быстрее чем сложные ALTER TABLE. Но в статье встроенные средства просто игнорируются — вместо того чтоб показать, чем Sybex Dumper лучше. Что и вызвало такие комментарии как этот
Конечно, иногда дампы проще и/или быстрее чем сложные ALTER TABLE. Но в статье встроенные средства просто игнорируются — вместо того чтоб показать, чем Sybex Dumper лучше. Что и вызвало такие комментарии как этот
Покажите место в статье, где я говорил что встроенные средства хуже, или где я писал что дамп нужно скачивать и что-то в нем править? Дампер как раз и использует эти встроенные средства, можно сказать представляет для них интерфейс.
Так я это и сказал. В статье не говорится, что встроенные средства хуже. В статье они просто игнорируются.
А дампер, как я понял, не использует ALTER TABLE, чтобы править кодировки — на то он и дампер. Но я могу и ошибаться конечно.
А дампер, как я понял, не использует ALTER TABLE, чтобы править кодировки — на то он и дампер. Но я могу и ошибаться конечно.
Вроде про ALTER TABLE и так куча всего написано, это же не обзор всех доступных способов.
Да и ALTER TABLE… CONVERT TO CHARACTER SET поможет только в случае изменения кодировки, но исправить неправильную кодировку он уже не сможет. Не считая того, что это как бы не готовое решение, его не используешь просто нажав кнопку.
Да и ALTER TABLE… CONVERT TO CHARACTER SET поможет только в случае изменения кодировки, но исправить неправильную кодировку он уже не сможет. Не считая того, что это как бы не готовое решение, его не используешь просто нажав кнопку.
Однажды по умолчанию была создана таблица в latin, когда ее переделали в UTF-8, крокозяблы не исчезли. Как выход в этом случае: надо задать нужную кодировку для каждого стрингового/текстового столбца.
Столкнулся тут недавно с БД в кои8 и сайтом в ср1251.
Для определения кодировки помог http://2cyr.com/decode/?lang=ru (сайт чужой, не сочтите за рекламу).
Для определения кодировки помог http://2cyr.com/decode/?lang=ru (сайт чужой, не сочтите за рекламу).
Помогло в одном из проектов. Спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Исправление и изменение кодировок MySQL