Здравствуйте, уважаемые разработчики.

Такая проблема возникла с кодировкой. Сразу прошу прощения, если такая тема встречалась - я честно пыталась найти через поиск и ЧАВО, время потеряла, а ответа не нашла (может конечно терпения не хватило).

Итак. При переносе с одного сервера на другой данные стали отображаться таким образом.
ЗАО «Красноярская буровая компания»

Вообще данные природы utf-8. Таблицам и полям тоже назаначено быть utf8_general_ci. Но в таком виде «ÐšÑ€Ð°ÑÐ½Ð¾ данные отображаются и на сайте и в базе (после переезда на другой сервер). То есть если напрямую сделать обзор полей базы, то теперь там все выглядит также «ÐšÑ€Ð°ÑÐ½Ð¾. Раньше выглядело корректно.
Рискнула на авось поменять для одного (не особо важного поля) кодировку на cp1251, в итоге она совсем слетела, после чего, разумеется, вернув кодировку на место, данные не вернулись, а стали выглядеть уже таким необратимым образом °?????‹?‚???µ ?°???†?????

Сама, глядя на кракозябры, думаю: они выглядят таким образом, как выглядят символы природы utf8, отображенные в cp1251. Но тем не менее они находятся в поле с кодировкой UTF8, потому как есть - так и имеем:((

может быть во время импорта данных в базу была высталена неверная кодировка по умолчанию?

может быть
вообще забыла сказать: импорт делался не мной, но человек, выполнявший импорт, сказал, что возможно не правильно импортнул.. Сейчас мне протсо поручено из того что есть, как-то вернуть нормальный вид, причем желательно не обращаясь к старым базам (так как срок лицензии на панель управления истек вчера и доступ закрыт к базам на старом сервере) такие дела:(

есть шанс как-то вернуть прежние данные? ведь судя по виду кракозябров, данные вообще не потеряны, но как их выудить-то?

http://www.phpfaq.ru/charset#repair
http://powerman.name/RTFM/MySQL-charset.txt
http://forum.php-myadmin.ru/viewtopic.php?id=95
http://forum.infobox.ru/viewtopic.php?=&p=26636
http://webgui.uanet.biz/poleznye_melochi (раздел о базе данных)
http://www.phpinside.ru/?q=node/707

если не трудно, отпишитесь потом о результатах

Не сделав перед этим бэкап таблицы? Перед вообще любыми телодвижениями по поводу базы? Жесть.
С таким подходом, боюсь, базе недолго жить осталось.

У него дамп остался?

m0ro, спасибо за ссылки, но честно говоря ни одна не помогла, хотя ссылки очень хорошие действительно..
Просто мне видимо слишком экстремальные условия возможно поставили: не как сделать ЗАНОВО корректный дампинг таблиц, а как починить уже запоротые данные, не имея доступа к исходным данным. В ссылках в основном даны очень хорошие рекомендации о том, как дампингнуть корректно базы и как переконвертировать данные одной природы в данные другой природы. У меня же не совсем то: у меня данные в таблице лежат такие ÐºÐ°Ñ буровая ко. Сравнение таблиц настроено сразу было и есть на utf8_general_ci

Пыталась дампингнуть то, что есть и переконвертировать средствами пхп (iconv, mb_convert_encoding) - ничто не помогло. Также сохраняла текстовым файлом в утф8 и в анши, открывала в браузерах текстовые файлы, настраивая кодировку браузера - ничто не помогло:(

Добавлено @ 08:51

Дампа исходника нет.



Вроде ясно дала понять, что осуществляла это действие сознательно (содержимое этого поля есть в текством файле под рукой, записей именно в этой "экспериментальной" таблице одна). И дамп разумеется всей этой кракозябринской горе-базы есть. И вообще - не в этом суть собственно-то...

Feldmarschall, Вы можете помочь советом, как вернуть данные, находясь в таких экстремальных условиях?



Это сообщение отредактировал(а) yalo - 10.4.2008, 09:13

из какой кодировки в какую?

поначалу из utf8 в cp1251, файл сохраняла, куда эту гадость вставляла, как ansi... может неверно рассудила

Впрочем дело не в этом, так как не получив корректного результата от бессилия начала дергать из 1251 в утф8, файл сохранять и так и сяк (про логику действий сразу предупреждаю - не спрашивайте, когда что-то не получается, и догадаться не могу никак что сделать и совета нет, остается дергать все подряд и тыкать пальцем в небо... плохо конечно когда так:(, а что делать? иногда помогает  )

Это сообщение отредактировал(а) yalo - 10.4.2008, 09:49

дело не в логике.
просто сама по себе фраза "использовал iconv" смысла не несет. главное - откуда куда.
почтовый декодер Лебедева показывает самый лучший результат при перекодировании 1252 - утф. Но при этом теряет некоторые буквы. которые в исходнике обозначены квадратиками. 
Я бы сказал, что они потеряны безвозвратно, если бы меня не посрамили с таким заявлением совсем недавно

Дамп, который есть сейчас, ТОЧНО делался при совпадении кодировки таблицы и клиента? 
Квадратики в исходнике - это не результат вставки в форум?

точного ответа дать не могу, так как не мной дамп делался, но на момент постановки задачи передо мной, в таблицах и полях назначено было utf8_general_ci



хм.. а почему квадратики? у Вас квадратики??  Такие символа ÑÐ½Ð¾Ñ я бы  скорее назвала "ND1/2D3/4N"   ну или что-то типа того


согласна, прошу прощения за отсутствие конкретики (когда писала про iconv тут же в голове пронеслось автоматически, что и в одну и в другую сторону конвертировала, подумала что нет смысла уточнять, забыв что на форуме нет телепатов   )

Это сообщение отредактировал(а) yalo - 10.4.2008, 10:54

у меня здесь второй по счету - квадратик.


кто мешает сделать дамп самой?


не важно, что назначено.
важно, чтобы при создании дампа кодировка клиента была указана такая же.

в общем нет исходной корректной БД

Это сообщение отредактировал(а) yalo - 10.4.2008, 11:13

я не про ту базу говорю, а про эту.
вот эта строчка 

точно ли отражает то, что лежит сейчас в базе.
Дамп, который есть сейчас, ТОЧНО делался при совпадении кодировки таблицы и клиента? 
Квадратики в исходнике - это не результат вставки в форум? 

что-то я совсем запуталась.. дело в том что у МЕНЯ ВОБЩЕ НЕТ КВАДРАТИКОВ


а у меня что-то вроде английской D  

вот непосредственно из базы символы, НЕ из текстового файла омоР(нажала обзор в пхпмайадмине, потом редактировать текстовое поле и оттуда выделила и скопировала эти символы, также можно надеюсь адекватно отобразить содержимое базы?) В данных символах я щас вижу НЕ квадратики, а D3/4D1/4D3/4D (я примерно конечно же символы описываю  )




насчет дампинга запоротой базы... даже не знаю, может я и не правильно делаю дампинг, но при экспорте я не вижу никакого выбора кодировок, и кроме того: то что я вижу в текстовом файле, который пытаюсь переконвертнуть и то, что в базе - выглядит все одинаково. Этого разве недостаточно, чтобы видеть что на этом этапе, по крайней мере явной, потери нет


Это сообщение отредактировал(а) yalo - 10.4.2008, 11:54

в общем, перекодируй это из 1252 в utf-8