Проблема с заменой спец.символа при вносе данных в базу MySQL

[Alina]

Проблема с заменой спец.символа при вносе данных в базу MySQL

Добрый день!

Я столкнулась с такой проблемой. Мне предоставили текст для размещения на сайте, но для начала его надо было внести в базу MySQL. Все кавычки в тексте выглядели довольно странно. Это даже не обычные угловые кавычки, использующиеся в Ворде и иже с ним. Эти кавычки выглядят как две точки вверху строки и имеют код ¨ При внесении в базу вся запись MySQL (весь текст на русском во всех полях данной записи) кодируется то ли в Юникод, то ли еще как. Вид ОНО имеет следующий: ЃN„@„‚„q„y„„„‚„p„w„~„p„‘ „Ѓ„‚„p„{„„„y„{„pЃN, „w„…„‚„~„p„|. Использование функций mysql_escape_string, mysql_real_escape_string, htmlentities для обработки строки перед ее внесением в базу ничего не дает.
Вопросы:
1. С помощью какой функции можно "обезопасить" данную строку?
2. Если использовать замену вручную с помощью str_replace или с помощью регулярных выражений, то как им передать не сам символ, а его код?
3. Нет ли еще таких вот "коварных" символов?

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

 

[Screjet]

Можно уточнить,

Использование функций mysql_escape_string, mysql_real_escape_string, htmlentities для обработки строки перед ее внесением в базу ничего не дает.

что именно должно давать? Может, просто, проблема в несовместимости кодировок отображения в разных местах?
Если так, то поможет с конвертациями коировк iconv.

 

[Alina]

В смысле, строка получается в том же немыслимом виде, типа
N„@„‚„q„y„„„‚„p„w„~„p„‘ „Ѓ„‚„p„{„„„y„{„pЃN, „w„…„‚„~„p„|.
Смотрю записи в базе данных. Все остальные записи в нормальном виде. Из чего я делаю вывод, что проблема "на входе". Что-то в форме или в коде обработки полученных переменных я сделала не так.
Форма - самая элементарная - три текстовых поля, одно textarea, две радио-кнопки. Никаких наворотов.
Код обработки - минимальный. Как уже писала выше, пыталась использовать функции mysql_escape_string и проч.

Да, если заносить ту же запись через phpMyAdmin, то он (phpMyAdmin) успешно преобразует этот символ в ¨ Что именно он использует для этого преобразования, я не нашла. Не очень долго искала, прямо скажу.

 

[Profic]

Alina
вот это

N„@„‚„q„y„„„‚„p„w„~„p„‘ „Ѓ„‚„p„{„„„y„{„pЃN, „w„…„‚„~„p„|.

это оригинал или результат?

 

[Alina]

Это результат как он виден в базе. Оригинал - русский текст с этими самыми кавычками.

 

[Profic]

Alina
а можно увидеть русский текст с этими самыми кавычками?

 

[Alina]

Пожалуйста:
¨Право и жизнь¨, журнал.

 

[Profic]

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

 

[Alina]

Profic
Посмотрите хтмл-код этой страницы. Разве они отображаются как обычные кавычки? Нет, они в коде выглядят как &amp#168; Ну то есть не "

Все равно большое спасибо. Проблема решилась сама собой. Видимо, случилась она из-за того, что я решила "сэкономить" на своей форме - сделала только поля, а кодировку в meta писать не стала. Или может, это был глюк?

И еще одно решение нашла.

$html_entities_match = array('#&(?!(\#[0-9]+;))#', '#<#', '#>#');
$html_entities_replace = array('&amp;', '&lt;', '&gt;');
preg_replace($html_entities_match, $html_entities_replace, $message);

 

[Profic]

кодировку в meta писать не стала

скорее вего проблема была именно в этом