xcorwin
Новичок
Срочно - кодировки мускуля и пхп
Посоветуйте пожалуйста, очень срочно нужно решить одну проблему...
Была база db0 - кодировка CP1251 базы/таблиц/полей (данные в CP1251)
Создал базу db1 - кодировка CP1251 также (база пуста)
Затем из db0 в db1 через PHP-скрипт законвертил данные (таблицы создавались с кодировкой по умолчанию, видать CP1251) с преобразованием данных из CP1251 в UTF8 в самом скрипте.
Т.е. в конце-концов в базе с CP1251-кодировкой хранились данные UTF8.
Все работало прекрасно (не было битых символов, крокозяблей и т.д.). Оказалось только что LIKE не работает, даже для латиницы.
Решено было сделать дамп таблицы, создать таблицу заново с кодировкой по умолчанию UTF8 и залить дамп обратно. Дамп делался с --compat=mysql323.
В момент сливания UTF8-данных с текущей таблицы (CP1251) некоторые символы кириллицы "побились" (т.е. вообще непонятно - почему не побились все символы, а только некоторые). Но я этого не заметил
Создал таблицу с кодировкой по умолчанию UTF8 и в нее залил дамп обратно. Естественно, что побитые символы залились и предыдущие данные не вернуть.
Вопрос №1:
Что нужно было сделать чтобы балгополучно решить проблему и данные бы не побились? Как вообще мускуль заставить не конвертировать кодировки, а брать и отдавать данные "как есть"?
Вопрос №2:
В таблице с уже испорченными данными например есть запись, которая выглядит как битая, т.е. при попытке
SELECT name FROM tab WHERE id=1
выдает к примеру 'К?анов', хотя до порчи данных там был 'Кшанов'. При попытке сделать апдейт-запрос
UPDATE tab SET name="Кшанов" WHERE id=1
(в UTF8) и затем SELECT-запрос, опять возвращает 'К?анов' (в UTF8, но с битым символом). Может это что-то в настройке кодировок или комбинация кодировок клиент/сервер между PHP/MySQL?
Т.е. может мускуль хранит-то правильно, а вот показывает неправильно? Или наоборот - в момент апдейта делает какую-то конвертацию?
Заранее спасибо за ответы!
Посоветуйте пожалуйста, очень срочно нужно решить одну проблему...
Была база db0 - кодировка CP1251 базы/таблиц/полей (данные в CP1251)
Создал базу db1 - кодировка CP1251 также (база пуста)
Затем из db0 в db1 через PHP-скрипт законвертил данные (таблицы создавались с кодировкой по умолчанию, видать CP1251) с преобразованием данных из CP1251 в UTF8 в самом скрипте.
Т.е. в конце-концов в базе с CP1251-кодировкой хранились данные UTF8.
Все работало прекрасно (не было битых символов, крокозяблей и т.д.). Оказалось только что LIKE не работает, даже для латиницы.
Решено было сделать дамп таблицы, создать таблицу заново с кодировкой по умолчанию UTF8 и залить дамп обратно. Дамп делался с --compat=mysql323.
В момент сливания UTF8-данных с текущей таблицы (CP1251) некоторые символы кириллицы "побились" (т.е. вообще непонятно - почему не побились все символы, а только некоторые). Но я этого не заметил
Создал таблицу с кодировкой по умолчанию UTF8 и в нее залил дамп обратно. Естественно, что побитые символы залились и предыдущие данные не вернуть.Вопрос №1:
Что нужно было сделать чтобы балгополучно решить проблему и данные бы не побились? Как вообще мускуль заставить не конвертировать кодировки, а брать и отдавать данные "как есть"?
Вопрос №2:
В таблице с уже испорченными данными например есть запись, которая выглядит как битая, т.е. при попытке
SELECT name FROM tab WHERE id=1
выдает к примеру 'К?анов', хотя до порчи данных там был 'Кшанов'. При попытке сделать апдейт-запрос
UPDATE tab SET name="Кшанов" WHERE id=1
(в UTF8) и затем SELECT-запрос, опять возвращает 'К?анов' (в UTF8, но с битым символом). Может это что-то в настройке кодировок или комбинация кодировок клиент/сервер между PHP/MySQL?
Т.е. может мускуль хранит-то правильно, а вот показывает неправильно? Или наоборот - в момент апдейта делает какую-то конвертацию?
Заранее спасибо за ответы!