Форум сетевых администраторов

Форум сетевых администраторов (http://netadmin.ws/forum/index.php)
- PHP (http://netadmin.ws/forum/forumdisplay.php?forumid=6)
-- чтение вывода mysql (http://netadmin.ws/forum/showthread.php?threadid=7298)

Помещено demar 16-12-2003 в 11:52:

чтение вывода mysql

Добрый день!

Есть вот такой простенький запрос:
$sql = "SELECT url
FROM url_base
WHERE month(url_date)='3'";
Появляется ошибка "unexpected T_VARIABLE in /var/http/urlread.php on line 3".
�_то база содержащая полные url страниц, по которым бегают пользователи. В базу данные попадают с помощью perl-скрипта, в котором я, видимо, пропустил какой-то из неправильных знаков. Подозреваю, что ошибка связана с url содержащим неверные символы. Отсюда вопросы:
1. Есть ли способ посмотреть на каком именно знаке спотыкается скрипт?
2. Есть ли возможность преобразовать вывод из таблицы или спасет теперь уж только ручная правка?

Спасибо

Помещено demar 16-12-2003 в 19:27:

Проблема решена. Беда была не в url.
Но, вопрос все-равно остался.

Помещено Nevermind 17-12-2003 в 05:56:

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

Касательно локализации ошибки ничего сказать не могу. Но определенно есть какие-нибудь дебагеры и спецредакторы

Помещено demar 17-12-2003 в 22:49:

Спасибо за ответ.
Мне не совсем понятно: в какой части кода будет обнаружена ошибка. Преположим, что в таблице есть специальные символы.
Есть конструкция запроса $sql = ..., есть собственно запрос $result=... Далее мы присваваем какой-то переменной полученное значение: $var = $row[some_symbols]; В какой из трех частей будет определена ошибка? Если бы она определялась при использовании переменной $var, то сразу после определения в нее данных их можно было прогнать через preg_replace. Собственно, тогда можно было бы с помощью regexpo'в определить и именно те данные, которые вызвали остановку. Но, боюсь, что остановка будет происходить в первой части. Впрочем, если не ошибаюсь, сам mysql допускает использование regexp'ов :0)
И, наконец, самый смешной вопрос:
А может ли, в принципе, в таблице храниться какой-то набор символов или один символ способный(-ые) вызвать ошибку парсинга?
Я прогнал url'ы на наличие спецсимволов, и нашел их огромное множество. Однако, ошибки они не вызывали. Ведь если на мой вопрос существует лишь отрицательный ответ, то все вышесказанное не имеет смысла. :0)

Помещено Nevermind 18-12-2003 в 15:35:

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



mysql_query("SELECT FROM tbl WHERE id='".$id"'");

- это parse_error (здесь отвалится интерпретатор PHP), либо ошибка в синтаксисе языка SQL. Чтобы отлавливать первый вид ошибок надо на время отладки скрипта первой строчкой в нем прописать
PHP:



error_reporting(E_ALL);

и ни в коем случае не ставить нигде @ перед вызовом функций. Проку от них мало, а поставить можно будет всегда, когда скрипт уже будет отлажен.

Что до SQL-ошибок, то их можно отлавливать через PHP-функцию mysql_error(); следующим образом (из мануала):
PHP:



$q=mysql_error("SELECT * FROM tbl bla-bla-bla") or die(mysql_error());

Так что советую попробовать исполнять ваши запросы именно таким образом. Тогда и будет видно, ошибка у вас в первой части или где-то еще.

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

Полученная же строка может стать "опасной" по-моему, если только вы решите ее прогнать через интерпретатор (eval), тогда, конечно, крик начнется. Гораздо важнее следить за тем, что передается в строке запроса (тут возможны так называемые SQL-injections). Т.е. проверять, что число - это именно число и так далее.

Помещено demar 19-12-2003 в 16:30:

�_скейпить я их эскейпю, но мало ли... Наверное паранойя. А вот про
PHP:



mysql_error()

имел глупость напрочь забыть.
Снова спасибо :0)

Формат времени GMT. Текущее время 12:30.

Показаны 6 сообщений на этой странице