Это в принципе первое, что приходит в голову, но не хотелось ковыряться в скриптах форума, и не забывать их править при обновлениях.
В последнее время перешел на поведенческие фильтр, их сложнее ботам вычислить, чем простое переименование полей.
Ну тут как бы сложнее ситуация, так как в версии 2 вообще минимизированы все служебные запросы, всё это делалось для ускорения парсинга. В принципе версии Pro даже есть кнопка Сохранить SQL, в этом режиме дампер как раз сохраняет все запросы в SQL-файл, в таком виде он получается съедобным для всего стороннего софта. Можно увидеть какие именно запросы добавляет дампер при восстановлении.
vBulletin не единственный с подобными проблемами, просто это последнее, что помогал вылечить юзерам, вот и пришелся к слову. И тут не столько любовь или не любовь к России, а всё дело в том, что западные юзеры с этой проблемой не сталкиваются особо, так как кодировка по умолчанию их устраивает. А тем же американцам еще проще, у них весь алфавит на одном месте, что в latin1, что в cp1251, что в utf8.
Вроде про ALTER TABLE и так куча всего написано, это же не обзор всех доступных способов.
Да и ALTER TABLE… CONVERT TO CHARACTER SET поможет только в случае изменения кодировки, но исправить неправильную кодировку он уже не сможет. Не считая того, что это как бы не готовое решение, его не используешь просто нажав кнопку.
А Вы допускаете, что кроме Вас есть другие люди и у них могут быть другие проблемы?) Проблемы описаны в статье, в том числе в каких случаях они возникают. Могу выложить пару php-скриптов которые воспроизводят эти проблемы, или даже просто SQL-запросы.
И вот к примеру на крупнейшем рунетовском сайте поддержки vBulletin исписали по это не существующей проблеме 27 страниц, и предлагают решать проблему хаком. Добавлением в скрипт 3-х запросов. А вариант с раскомментированием строки в конфиге лишь в конце. Притом написано, что он только для MySQLi, хотя это и не так (я ковырял исходники).
Вы вообще читаете о чем пишу? vBulletin по вашему не готовый продукт? У него эта проблема из коробки. Понятное дело, что кракозябры из-за того, что кто-то где-то сделал косяк. В статье как раз решается вопрос, что с ними делать, а не кто виноват.
Я же в самом начале написал, что статья не о том как делать правильно, а о том как можно исправить проблему, которая уже случилась.
Покажите место в статье, где я говорил что встроенные средства хуже, или где я писал что дамп нужно скачивать и что-то в нем править? Дампер как раз и использует эти встроенные средства, можно сказать представляет для них интерфейс.
Серьезно не имеют проблем vBulletin? Расскажите это тем юзерам которым я имправлял их базы…
Вообще загадочная у Вас позиция, если Вы с проблемой не сталкивались, значит она не существует.
Я что-то вообще запутался, что именно вы делаете в notepad++. Вы хотите изменить кодировку с cp1251 на utf8, или исправить несоответствие между кодировкой указанной в свойствах таблицы и кодировкой данных в них лежащих (т.е. те самые кракозябры исправить)?
Скажем так у вас были описанные в статье проблемы которые помог решить хостинг? Если у вас не было проблем с кодировками, то вполне естественно, что дамп и штатными средствами отлично делается. Хотя не понимаю зачем для этого постоянно службу поддержки дергать.
Можем ради интереса сделать тестовый скрипт, который сделает пару неправильных таблиц описанных в статье, и попросите ваших хостеров их исправить. Заодно засечем сколько времени уйдет на решение проблемы вашим способом, и решение проблемы способом описанным в статье.
Вы думаете у всех хостеров прям такие большие спецы, которые в тонкостях MySQL разбираются? Максимум они вам сделают/восстановят дамп с помощью mysqldump, никто там не будет ковыряться в кривизне ваших кодировок бесплатно. Это не входит в их обязанности.
И что вы хотели сказать этой строкой? Предлагаете вручную исправлять каждый текстовый столбец в каждой таблице?
А ну как будет выглядеть исправление таблиц того же упомянутого выше vBulletin 4 (у которого их около двух сотен).
Я же не говорю, что я прям открыл Америку, или какие-то недокументированные возможности MySQL использую, в дампере никакой магии нет, он тоже работает с MySQL используя SQL-запросы. Я просто предлагаю уже готовое решение, которое облегчает ручной труд.
Добавление этой строки не поможет, если уже есть данные в кривой кодировки, а только усугубит ситуацию, так как у вас данные внутри уже будет в разных кодировках, и для приведения их в нормальный вид, уже придется по частям ковырять таблицу. И всё описанное прекрасно делается в бесплатной версии дампера.
Вообще-то там вся статья касается бесплатной версии, о платной версии только последний абзац 5 строчек и скриншот. Могу и убрать, если так режет глаза.
В последнее время перешел на поведенческие фильтр, их сложнее ботам вычислить, чем простое переименование полей.
Да и ALTER TABLE… CONVERT TO CHARACTER SET поможет только в случае изменения кодировки, но исправить неправильную кодировку он уже не сможет. Не считая того, что это как бы не готовое решение, его не используешь просто нажав кнопку.
И вот к примеру на крупнейшем рунетовском сайте поддержки vBulletin исписали по это не существующей проблеме 27 страниц, и предлагают решать проблему хаком. Добавлением в скрипт 3-х запросов. А вариант с раскомментированием строки в конфиге лишь в конце. Притом написано, что он только для MySQLi, хотя это и не так (я ковырял исходники).
Я же в самом начале написал, что статья не о том как делать правильно, а о том как можно исправить проблему, которая уже случилась.
Вообще загадочная у Вас позиция, если Вы с проблемой не сталкивались, значит она не существует.
Я что-то вообще запутался, что именно вы делаете в notepad++. Вы хотите изменить кодировку с cp1251 на utf8, или исправить несоответствие между кодировкой указанной в свойствах таблицы и кодировкой данных в них лежащих (т.е. те самые кракозябры исправить)?
Можем ради интереса сделать тестовый скрипт, который сделает пару неправильных таблиц описанных в статье, и попросите ваших хостеров их исправить. Заодно засечем сколько времени уйдет на решение проблемы вашим способом, и решение проблемы способом описанным в статье.
А ну как будет выглядеть исправление таблиц того же упомянутого выше vBulletin 4 (у которого их около двух сотен).
Я же не говорю, что я прям открыл Америку, или какие-то недокументированные возможности MySQL использую, в дампере никакой магии нет, он тоже работает с MySQL используя SQL-запросы. Я просто предлагаю уже готовое решение, которое облегчает ручной труд.
Может помочь themanbehindthecode.com/2011/04/14/fix-myisam-myd-file-not-found-errcode2/