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