- Переход сайта с cp1251 на utf-8, felix, 11:05 , 24-Фев-08 (1)
>[оверквотинг удален] >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 и восстанавливаешь базу. Делал такое неоднократно.
- Переход сайта с cp1251 на utf-8, angra, 17:20 , 24-Фев-08 (2)
- Переход сайта с cp1251 на utf-8, felix, 20:32 , 24-Фев-08 (3)
>Что такое set names вы похоже не знаете, с условиями эксплуатации мускула >за пределами хомпаг не знакомы. > >Автору топика могу посоветовать внимательно просмотреть скрипты на наличие use utf8. Когда >выводятся строки имеющие и неимеющие жестко поставленный флаг utf8_on, то что-либо >из них превращается в крякозябры. Если use utf8 нужен для каких-либо >операций, то можно ограничить его блоком. Скрипты не при чем. У топикстартера данные из базы выводятся некорректно. А такое бывает, если html-страница уже в юникоде, а данные из базы --в koi8-r или cp1251. Еще раз -- при переходе на другую кодировку спасает dump/restore с промежуточной перекодировкой данных в dump. Перекодировку можно сделать даже в kate или kwrite.
- Переход сайта с cp1251 на utf-8, angra, 20:46 , 24-Фев-08 (4)
- Переход сайта с cp1251 на utf-8, felix, 04:52 , 25-Фев-08 (5)
>>Скрипты не при чем. > >Вы действительно думаете что так хорошо знаете perl? Боюсь вас разочаровать, но >если вы с чем то не сталкивались, это не значит что >такого не бывает. Сталкивался, но тут Вы правы. :-)) > > >Еще раз почитайте что делает set names, внимательно почитайте. У меня например >есть таблицы где часть полей в utf8, часть в latin1, а >часть в cp1251 и проблем не возникает. Опять таки не забывайте ну вот для такого случая Ваш вариант как раз и подходит. А скажите, для чего нужно хранение данных в разных кодировках в одной таблице? Кроме как для возможностей корректной сортировки, больше ничего на ум не приходит. >что конвертацию вашим методом зачастую нельзя делать в продекшеновых условиях, так >как затянется она на часы, а за такое по головке не >погладят. а на резервном сервере? >При этом я не отрицаю что у автора могли быть ошибки конвертации >базы, но он вообще не упомянул что она конвертировалась. Ну да упоминаний не было. Было лишь сказано, что переходит с cp1251 на utf-8.
|