https://www.opennet.ru/openforum/vsluhforumID8/5578.html Сервер на Windows 2003 R2<br>Apache2<br>perl 5.8.8<br>mod_perl2<br>Mysql51<br><br>Сохранил все конфиги Apache2, Perl-кие модули с кодировкой UTF-8.<br>Прописал в заголовках: &lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"&gt;.<br>В соединении с базой указываю: SET NAMES 'utf8'<br>В перловских модулях указываю: use utf8;<br>При открытии странички, текст который был написан в скриптах с кодировкой utf-8 отображается нормально, а текст из базы каракулями.<br><br>Подскажите куда рыть надо!!!<br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#9 Fri, 29 Feb 2008 04:41:21 GMT Самый простой способ в этом разобраться сделать тестовую таблицу с указанием разных кодировок для полей и поиграться с ней записывая и считывая данные с разными set names причем делайте это в стандартном клиенте, а не в своей программе, дабы исключить лишний слой. Также стоит обратить внимание на значение таких переменных выдаваемых по \s в стандартном клиенте<br>Server characterset: latin1<br>Db characterset: latin1<br>Client characterset: latin1<br>Conn. characterset: latin1<br>set names меняет последние два. <br><br>После этого уже не тяжело будет выяснить в чем именно у вас проблема с уже существующими данными. Не исключен вариант что записаны данные в кодировке, отличной от указанной в свойствах таблицы/поля. <br><br>Есть еще крайний вариант - использование binary вместо char/varchar, в этом случае мускул не совершает никаких преобразований, а отдает как есть, дальше уже на стороне приложения конвертим. Однако по ряду причин такой способ нежелателен. <br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#8 Thu, 28 Feb 2008 04:31:57 GMT ну так я указывал set names utf8<br><br><br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#7 Wed, 27 Feb 2008 16:24:23 GMT Можно все, вопрос будет ли работать :)<br>Если вы скажете что поле имеет кодировку cp1251, а внутрь запихнете в utf8, то ничего хорошего не получите. Другое дело, если указано что поле в utf8, данные в нем в utf8, а обращаясь к базе вы ставите set names cp1251, то получите вы ответ в cp1251, при условии что конвертация возможна. Так что при условии конвертируемого набора символов можно писать и читать в произвольных кодировках, главное правильно указывать set names<br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#6 Wed, 27 Feb 2008 11:58:12 GMT Извини что так долго не писал!!!<br>MySQL я неочень знаю.<br><br>Тогда получается я могу поставить на таблицу любую кодировку, а данные в этой таблице могут хранится в другой кодировке????<br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#5 Mon, 25 Feb 2008 01:52:52 GMT &gt;&gt;Скрипты не при чем. <br>&gt;<br>&gt;Вы действительно думаете что так хорошо знаете perl? Боюсь вас разочаровать, но <br>&gt;если вы с чем то не сталкивались, это не значит что <br>&gt;такого не бывает. <br><br>Сталкивался, но тут Вы правы. :-))<br>&gt;<br>&gt;<br>&gt;Еще раз почитайте что делает set names, внимательно почитайте. У меня например <br>&gt;есть таблицы где часть полей в utf8, часть в latin1, а <br>&gt;часть в cp1251 и проблем не возникает. Опять таки не забывайте <br><br>ну вот для такого случая Ваш вариант как раз и подходит. А скажите, для чего нужно хранение данных в разных кодировках в одной таблице? Кроме как для возможностей корректной сортировки, больше ничего на ум не приходит.<br><br>&gt;что конвертацию вашим методом зачастую нельзя делать в продекшеновых условиях, так <br>&gt;как затянется она на часы, а за такое по головке не <br>&gt;погладят. <br><br>а на резервном сервере? <br><br>&gt;При этом я не отрицаю что у автора могли быть ошибки конвертации <br>&gt;базы, но он вообще не упомянул что она конвертировалась. <br><br>Ну да упоминаний не было. Было лишь сказано, что перех https://www.opennet.ru/openforum/vsluhforumID8/5578.html#4 Sun, 24 Feb 2008 17:46:24 GMT &gt;Скрипты не при чем. <br><br>Вы действительно думаете что так хорошо знаете perl? Боюсь вас разочаровать, но если вы с чем то не сталкивались, это не значит что такого не бывает.<br><br>&gt;У топикстартера данные из базы выводятся некорректно. А <br>&gt;такое бывает, если html-страница уже в юникоде, а данные из базы <br>&gt;--в koi8-r или cp1251. Еще раз -- при переходе на другую <br>&gt;кодировку спасает dump/restore с промежуточной перекодировкой данных в dump. Перекодировку можно <br>&gt;сделать даже в kate или kwrite. <br><br>Еще раз почитайте что делает set names, внимательно почитайте. У меня например есть таблицы где часть полей в utf8, часть в latin1, а часть в cp1251 и проблем не возникает. Опять таки не забывайте что конвертацию вашим методом зачастую нельзя делать в продекшеновых условиях, так как затянется она на часы, а за такое по головке не погладят. <br>При этом я не отрицаю что у автора могли быть ошибки конвертации базы, но он вообще не упомянул что она конвертировалась.<br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#3 Sun, 24 Feb 2008 17:32:16 GMT &gt;Что такое set names вы похоже не знаете, с условиями эксплуатации мускула <br>&gt;за пределами хомпаг не знакомы. <br>&gt;<br>&gt;Автору топика могу посоветовать внимательно просмотреть скрипты на наличие use utf8. Когда <br>&gt;выводятся строки имеющие и неимеющие жестко поставленный флаг utf8_on, то что-либо <br>&gt;из них превращается в крякозябры. Если use utf8 нужен для каких-либо <br>&gt;операций, то можно ограничить его блоком. <br><br>Скрипты не при чем. У топикстартера данные из базы выводятся некорректно. А такое бывает, если html-страница уже в юникоде, а данные из базы --в koi8-r или cp1251. Еще раз -- при переходе на другую кодировку спасает dump/restore с промежуточной перекодировкой данных в dump. Перекодировку можно сделать даже в kate или kwrite.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#2 Sun, 24 Feb 2008 14:20:00 GMT Что такое set names вы похоже не знаете, с условиями эксплуатации мускула за пределами хомпаг не знакомы. <br><br>Автору топика могу посоветовать внимательно просмотреть скрипты на наличие use utf8. Когда выводятся строки имеющие и неимеющие жестко поставленный флаг utf8_on, то что-либо из них превращается в крякозябры. Если use utf8 нужен для каких-либо операций, то можно ограничить его блоком. <br> https://www.opennet.ru/openforum/vsluhforumID8/5578.html#1 Sun, 24 Feb 2008 08:05:48 GMT &gt;[оверквотинг удален]<br>&gt;Mysql51 <br>&gt;<br>&gt;Сохранил все конфиги Apache2, Perl-кие модули с кодировкой UTF-8. <br>&gt;Прописал в заголовках: &lt;meta http-equiv="Content-Type" content="text/html; charset=utf-8"&gt;.<br>&gt;В соединении с базой указываю: SET NAMES 'utf8' <br>&gt;В перловских модулях указываю: use utf8; <br>&gt;При открытии странички, текст который был написан в скриптах с кодировкой utf-8 <br>&gt;отображается нормально, а текст из базы каракулями. <br>&gt;<br>&gt;Подскажите куда рыть надо!!! <br><br>Сделай дамп базы в старой кодировке. Затем перекодируешь его (это обычный текстовый файл) в utf-8 и восстанавливаешь базу. Делал такое неоднократно.<br><br>