Сервер на Windows 2003 R2
Apache2
perl 5.8.8
mod_perl2
Mysql51Сохранил все конфиги Apache2, Perl-кие модули с кодировкой UTF-8.
Прописал в заголовках: <meta http-equiv="Content-Type" content="text/html; charset=utf-8">.
В соединении с базой указываю: SET NAMES 'utf8'
В перловских модулях указываю: use utf8;
При открытии странички, текст который был написан в скриптах с кодировкой utf-8 отображается нормально, а текст из базы каракулями.Подскажите куда рыть надо!!!
>[оверквотинг удален]
>Mysql51
>
>Сохранил все конфиги Apache2, Perl-кие модули с кодировкой UTF-8.
>Прописал в заголовках: <meta http-equiv="Content-Type" content="text/html; charset=utf-8">.
>В соединении с базой указываю: SET NAMES 'utf8'
>В перловских модулях указываю: use utf8;
>При открытии странички, текст который был написан в скриптах с кодировкой utf-8
>отображается нормально, а текст из базы каракулями.
>
>Подскажите куда рыть надо!!!Сделай дамп базы в старой кодировке. Затем перекодируешь его (это обычный текстовый файл) в utf-8 и восстанавливаешь базу. Делал такое неоднократно.
Что такое set names вы похоже не знаете, с условиями эксплуатации мускула за пределами хомпаг не знакомы.Автору топика могу посоветовать внимательно просмотреть скрипты на наличие use utf8. Когда выводятся строки имеющие и неимеющие жестко поставленный флаг utf8_on, то что-либо из них превращается в крякозябры. Если use utf8 нужен для каких-либо операций, то можно ограничить его блоком.
>Что такое set names вы похоже не знаете, с условиями эксплуатации мускула
>за пределами хомпаг не знакомы.
>
>Автору топика могу посоветовать внимательно просмотреть скрипты на наличие use utf8. Когда
>выводятся строки имеющие и неимеющие жестко поставленный флаг utf8_on, то что-либо
>из них превращается в крякозябры. Если use utf8 нужен для каких-либо
>операций, то можно ограничить его блоком.Скрипты не при чем. У топикстартера данные из базы выводятся некорректно. А такое бывает, если html-страница уже в юникоде, а данные из базы --в koi8-r или cp1251. Еще раз -- при переходе на другую кодировку спасает dump/restore с промежуточной перекодировкой данных в dump. Перекодировку можно сделать даже в kate или kwrite.
>Скрипты не при чем.Вы действительно думаете что так хорошо знаете perl? Боюсь вас разочаровать, но если вы с чем то не сталкивались, это не значит что такого не бывает.
>У топикстартера данные из базы выводятся некорректно. А
>такое бывает, если html-страница уже в юникоде, а данные из базы
>--в koi8-r или cp1251. Еще раз -- при переходе на другую
>кодировку спасает dump/restore с промежуточной перекодировкой данных в dump. Перекодировку можно
>сделать даже в kate или kwrite.Еще раз почитайте что делает set names, внимательно почитайте. У меня например есть таблицы где часть полей в utf8, часть в latin1, а часть в cp1251 и проблем не возникает. Опять таки не забывайте что конвертацию вашим методом зачастую нельзя делать в продекшеновых условиях, так как затянется она на часы, а за такое по головке не погладят.
При этом я не отрицаю что у автора могли быть ошибки конвертации базы, но он вообще не упомянул что она конвертировалась.
>>Скрипты не при чем.
>
>Вы действительно думаете что так хорошо знаете perl? Боюсь вас разочаровать, но
>если вы с чем то не сталкивались, это не значит что
>такого не бывает.Сталкивался, но тут Вы правы. :-))
>
>
>Еще раз почитайте что делает set names, внимательно почитайте. У меня например
>есть таблицы где часть полей в utf8, часть в latin1, а
>часть в cp1251 и проблем не возникает. Опять таки не забывайтену вот для такого случая Ваш вариант как раз и подходит. А скажите, для чего нужно хранение данных в разных кодировках в одной таблице? Кроме как для возможностей корректной сортировки, больше ничего на ум не приходит.
>что конвертацию вашим методом зачастую нельзя делать в продекшеновых условиях, так
>как затянется она на часы, а за такое по головке не
>погладят.а на резервном сервере?
>При этом я не отрицаю что у автора могли быть ошибки конвертации
>базы, но он вообще не упомянул что она конвертировалась.Ну да упоминаний не было. Было лишь сказано, что переходит с cp1251 на utf-8.
Извини что так долго не писал!!!
MySQL я неочень знаю.Тогда получается я могу поставить на таблицу любую кодировку, а данные в этой таблице могут хранится в другой кодировке????
Можно все, вопрос будет ли работать :)
Если вы скажете что поле имеет кодировку cp1251, а внутрь запихнете в utf8, то ничего хорошего не получите. Другое дело, если указано что поле в utf8, данные в нем в utf8, а обращаясь к базе вы ставите set names cp1251, то получите вы ответ в cp1251, при условии что конвертация возможна. Так что при условии конвертируемого набора символов можно писать и читать в произвольных кодировках, главное правильно указывать set names
ну так я указывал set names utf8
Самый простой способ в этом разобраться сделать тестовую таблицу с указанием разных кодировок для полей и поиграться с ней записывая и считывая данные с разными set names причем делайте это в стандартном клиенте, а не в своей программе, дабы исключить лишний слой. Также стоит обратить внимание на значение таких переменных выдаваемых по \s в стандартном клиенте
Server characterset: latin1
Db characterset: latin1
Client characterset: latin1
Conn. characterset: latin1
set names меняет последние два.После этого уже не тяжело будет выяснить в чем именно у вас проблема с уже существующими данными. Не исключен вариант что записаны данные в кодировке, отличной от указанной в свойствах таблицы/поля.
Есть еще крайний вариант - использование binary вместо char/varchar, в этом случае мускул не совершает никаких преобразований, а отдает как есть, дальше уже на стороне приложения конвертим. Однако по ряду причин такой способ нежелателен.