 |
 |
Форум сетевых администраторов » Программирование » PHP » чтение вывода mysql
| Автор |
| Тема |
 |
|
 |
|
|
|
Участник
Зарегистрирован: Dec 2003
Место проживания:
Публикаций: 6
Статус:  |
Добрый день!
Есть вот такой простенький запрос:
$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. Есть ли возможность преобразовать вывод из таблицы или спасет теперь уж только ручная правка?
Спасибо
Сообщить модератору об этом сообщении | Предупреждение | IP: определен
|
16-12-2003 11:52 |
|
|
Участник
|
Проблема решена. Беда была не в url.
Но, вопрос... |
[сооб. #56832]
16-12-2003 19:27 |
|
|
Участник+
|
| Преобразовать можно с помощью регулярных... |
[сооб. #56845]
17-12-2003 05:56 |
|
Участник+
Зарегистрирован: Feb 2002
Место проживания: RU, VLadivostok
Публикаций: 145
Статус: |
Преобразовать можно с помощью регулярных выражений. Получаешь строку, прогоняешь ее через preg_replace и удаляешь свои неправильные знаки.
Касательно локализации ошибки ничего сказать не могу. Но определенно есть какие-нибудь дебагеры и спецредакторы
Сообщить модератору об этом сообщении | Предупреждение | IP: определен
|
|
17-12-2003 05:56 |
|
|
Участник
|
Спасибо за ответ.
Мне не совсем понятно: в... |
[сооб. #56913]
17-12-2003 22:49 |
|
Участник
Зарегистрирован: Dec 2003
Место проживания:
Публикаций: 6
Статус: |
Спасибо за ответ.
Мне не совсем понятно: в какой части кода будет обнаружена ошибка. Преположим, что в таблице есть специальные символы.
Есть конструкция запроса $sql = ..., есть собственно запрос $result=... Далее мы присваваем какой-то переменной полученное значение: $var = $row[some_symbols]; В какой из трех частей будет определена ошибка? Если бы она определялась при использовании переменной $var, то сразу после определения в нее данных их можно было прогнать через preg_replace. Собственно, тогда можно было бы с помощью regexpo'в определить и именно те данные, которые вызвали остановку. Но, боюсь, что остановка будет происходить в первой части. Впрочем, если не ошибаюсь, сам mysql допускает использование regexp'ов :0)
И, наконец, самый смешной вопрос:
А может ли, в принципе, в таблице храниться какой-то набор символов или один символ способный(-ые) вызвать ошибку парсинга?
Я прогнал url'ы на наличие спецсимволов, и нашел их огромное множество. Однако, ошибки они не вызывали. Ведь если на мой вопрос существует лишь отрицательный ответ, то все вышесказанное не имеет смысла. :0)
Сообщить модератору об этом сообщении | Предупреждение | IP: определен
|
|
17-12-2003 22:49 |
|
|
Участник+
|
| В "конструкции запроса", думается мне, может... |
[сооб. #56966]
18-12-2003 15:35 |
|
Участник+
Зарегистрирован: Feb 2002
Место проживания: RU, VLadivostok
Публикаций: 145
Статус: |
В "конструкции запроса", думается мне, может быть немного вариантов ошибок. Либо простейшая опечатка (ну, или ее разновидности - не поставили точку с запятой и т.д.), например, так:
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). Т.е. проверять, что число - это именно число и так далее.
Сообщить модератору об этом сообщении | Предупреждение | IP: определен
|
|
18-12-2003 15:35 |
|
|
Участник
|
| _скейпить я их эскейпю, но мало ли... Наверное... |
[сооб. #57033]
19-12-2003 16:30 |
|
|
|
Формат времени GMT. Текущее время 12:19.
|
Правила форума:
Вы не можете создавать новые темы.
Вы не можете отвечать на существующие темы.
Вы не можете прикреплять файлы.
Вы не можете редактировать свои сообщения. |
HTML теги выкл.
Спец. код вкл.
Смайлики вкл.
[IMG] тег выкл.
|
|
|
|
| |
Page generated in 0.09184909 seconds (92.51% PHP - 7.49% MySQL) with 23 queries.
|
|
