Developing.ru

2 Absurd
ага? контрпример:
вставить в БД текст, содержащий ', при этом использовать ' в запросе:
$x="bla-'bla'-bla";
mysql_query("UPDATE table SET text=' $x ' WHERE ...");
=> mysqlerror!!!
*а) как я помню в PHP вот такие же чудеса есть echo ' \' '; выведет просто одерную кавычку
б) я имел в в иду просто перепутицу с кавычками, которых иногда не хватает

В PHP есть кавычки, содержимое которых не интерпретируется - одинарые кавычки.
'This is a \ " string'. Для регекспов и запросов лучше использовать их. В C# тоже есть буквальные строчки, начинаются с @ - @"This is \a string".

berkut писал(а):addslashes()

вообще, ужасная функция! пусть у нас есть текст "bla-\"bla\"-bla", и нам его надо отредактировать. то есть мы его открыли, отредактировали и сохранили. и так 5 раз! и с каждым сохранением применяется addslashes. тогда у нас получиться "bla-\\\\\"bla\\\\\"-bla" примерно вот такое чудо! Никуда не годиться! ТЕм более если сохраняем не в файл, а в БД, то там багов не оберемся с распознованием симовлов!

вот я чаго давно езе задумал и сделал

addslashes()

Я, например, стараюсь всегда выбрать тот вид кавычек, с которыми будет меньше гемморою :-)

собственно говоря, это не баги никакие, это просто так и забумано. надо понимать что в скобочках пишется! ))
сначала в PHP: \ - там спец.симов, типа для \n \t \r и прочего. чтобы это не было спец символом, а просто печаталась \, надо написать \\
т.е. echo "\\"; будет \

что касается mysql: пишем запрос, чтоб поступал вот так

в mysql: UPDATE field="bla-bla-bla"
следовательно в php будет так: " UPDATE field=\"bla-bla-bla\" " (с использованием спец симовлов, потому что если в запросе вместо \" написать просто " то php воспримет их как открывающие-закрывающие скобки --> ошибка)

тепрь когда у нас в тексте содержаться кавычки:
текст: камон, "биг-блэк-брозерс", камон!
в mysql тогда должно поступить так: UPDATE field="камон, \"биг-блэк-брозерс\", камон!" (тож спец символы и БД, аналогично, что и в предыдущем примере)

и наконец в PHP, поднатужимся, вспомним все что выше получится:
mysql_query(" UPDATE field=\"камон, \\\"биг-блэк-брозерс\\\", камон!\" ") (в запросе все " заменили на \", а \ на \\)...

воть! и никаких глюков! а как уже заменять и прочее - это дело техники, главное все писать в кавычках. И никаких проблем с & < > я не встречал. но вообще, можно воспользоваться для такого htmlspecialchars()... и для пущей уверрености, сами запросы писать только с " и \", а в тексте заменять все " на ' str_replace-ом...

можно провести анолгоию для ', заменив выше все " на '
что касается ' - то никаких баг при вот таком не бывало у меня:
mysql_query(" UPDATE field=\"камон, \\\"биг-блэк-брозерс\\\", ' ' ' ' ' камон!\" ")

Не понял? Может на русском сказать:
зафиксить - исправить
багис - ???

Тьфу. Понял, "зафиксить баги с"...
В Мускуле есть проблема со вставкой только ' и \ - перед вставкой ставь \' и \\. В ПХП админе даже написано об этом на каждой странице :-)
Вообще можешь в критических местах ставьть \ перед символом - это будет означать, что это именно символ, а не управляющий знак.

Спасибо помогло введение в начало страницы
@setlocale(LC_ALL,'ru_RU.cp1251');

Есть еще вопрос
как можно зафиксить багис запросами, содержащими ", &, ', <, > и несколькими пробелами

1) Попробуй покопаться в настройках.
# Example mysql config file.
# Copy this file to c:\my.cnf to set global options
#
# One can use all long options that the program supports.
# Run the program with --help to get a list of available options


# This will be passed to all mysql clients
[client]
default-character-set=cp1251
character-sets-dir = d:/usr/local/mysql/share/charsets

[mysqld]
default-character-set=cp1251
character-sets-dir=d:/usr/local/mysql/share/charsets/
ariable = innodb_lock_wait_timeout=50

[mysql]
default-character-set = cp1251
2) Можно перекомпилить MySQL из исходных текстов с использованием ключа --with-charset=cp1251.
3) Можно пользоваться UTF-8 локалью

Возникла такая проблема,
поставил на сайт поиск php/MySQL все работает, но когда ищет в русских текстах не может из нижнего регистра перевести на верхний и наоборот, при чем с английским все нормально, хостер что то темнит, в начале говорили что баг на серваке, но они так и не могут понять в чем причина.
Может кто сталкивался с подобной проблемой?
:shock: :shock: :shock: