Кодировка в MySQL

David Jones, 226 просмотров

На локальном сервере кодировка всей базы — latin1, и на сайте всё отображается нормально.
Непосредственно через PhpMyAdmin видны кракозябры, но это не суть.

При переносе базы на хостинг, та же latin1 при загрузке сайта рисует непонятно что и пропадает регистронезависимость.
Отчего может быть так, что перенесенная база на другом сервере кривит кодировкой, и как можно решить проблему?

Примечание:
Данные на русском.
Они заносились в БД через админ-панель, при этом через PhpMyAdmin были нечитабельны. Но всё работало.
Сейчас перевёл весь сайт на UTF-8, всё хранится в нём. Вроде, работает.
Только почему-то опять регистрозависимое всё, хотя все кодировки стоят _ci
Скажем, проблему не решил, но обошел. )

Примечание:
Японский Городовой,
в скрипте обращения к полям шли строчными буквами, а в базе поля были написаны заглавными. На локальной машине всё работает - на хостинге пришлось поменять поля в БД, чтобы скрипт их видел.

В целом, то, что я перевел на UTF работает нормально.

Примечание:
Ну естественно, я бы не стал так писать. Но был готовый скрипт, в котором сделано именно так. И оно изначально работало, потому я не менял все эти имена.

В общем, ладно. UTF так UTF.

Ответы:

Comador

На локале делаешь дамп базы со своей кодировкой, а на хостинге создаешь базу в такой же кодировке и вытягиваешь из дампа.

Есть еще стопроцентный вариант, ставить быстро устаревающую куку при посещении страниц сайта и отдачу картинок производить при ее наличии

Вопрос в том, данные на каких языках хранятся? Ты что, пытаешься хранить русский в latin1? Тогда решение проблемы - применение кодировки, предназначенной для данного языка, в случае русского это cp1251 или сразу UTF-8.

Японский Городовой

1. Про "пропадает регистронизависимость" - враньё. Её и не было, потому что не может быть при неверной кодировке.
2. На вопрос "отчего может быть" ответ простой: кодировка данных не совпадает с указанной при создании таблицы.
3. Если что-то не работает, значит, не весь сайт перевел. Собственно, правила для правильной работой с кодировкой в мускуле всего два:
- кодировка, указанная на таблице, должна отражать реальную кодировку данных. если данные в утф, то чарсет на таблице должен стоять тоже утф. Если это не так, то пересоздать и перезалить. Заливая - указывать кодировку дампа.
- кодировка, посылаемая при коннекте в SET NAMES. Должна совпадать с кодировкой сайта.
При соблюдении этих простых условий, никогда никаких проблем с кодировками не будет.

Японский Городовой

огосподи, кодировка ДАННЫХ не имее никакого отношения к НАЗВАНИЯМ полей.
обращаться к идентификаторам в БД нужно всегда ТОЧНО, независимо от того, как оно "работает"
а лучше не выпендриваться и взять за правило писать все с маленькой буквы.

15 лет назад

RPI.su - самая большая русскоязычная база вопросов и ответов. Наш проект был реализован как продолжение популярного сервиса otvety.google.ru, который был закрыт и удален 30 апреля 2015 года. Мы решили воскресить полезный сервис Ответы Гугл, чтобы любой человек смог публично узнать ответ на свой вопрос у интернет сообщества.

Все вопросы, добавленные на сайт ответов Google, мы скопировали и сохранили здесь. Имена старых пользователей также отображены в том виде, в котором они существовали ранее. Только нужно заново пройти регистрацию, чтобы иметь возможность задавать вопросы, или отвечать другим.

Чтобы связаться с нами по любому вопросу О САЙТЕ (реклама, сотрудничество, отзыв о сервисе), пишите на почту [email protected]. Только все общие вопросы размещайте на сайте, на них ответ по почте не предоставляется.