Скобки PDO/MYSQL () в запросе

Возникли некоторые проблемы с выполнением запроса PDO LIKE, содержащего ().

<?php

...    

$text_with_parentheses = '%'.$text_with_parentheses.'%'

$sth = $dbh->prepare('SELECT * FROM '.$table.' WHERE alarm LIKE :alarm');
$sth->bindParam(':alarm' , $text_with_parentheses);
$sth->execute();
$response = $sth->fetch();

...

?>

Строковое значение, которое я запрашиваю, представляет собой текст предупреждения, хранящийся в столбце varchar utf8_uncode_ci. Это выглядит так:

'ABCD. Статус ABCD (6): (сбой)'

Кажется, я не могу понять, как избежать круглых скобок. Протестировано как через PHP/PDO, так и напрямую в консоли MYSQL. Для тестирования я проверил следующее непосредственно в консоли MYSQL.

SELECT * FROM `table` WHERE `column`='ABCD. Status ABCD (6): (fail)'

Он возвращает 0 результатов.

Единственный способ получить какие-либо результаты - как в PDO, так и в консоли MYSQL - это сделать:

SELECT * FROM `table` WHERE `column` LIKE 'ABCD. status ABCD%'

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

У кого-нибудь есть идеи? Это похоже на проблему с MYSQL.


mysql pdo
person Jakob Brøgger    schedule 03.03.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Скобки не имеют абсолютно никакого значения ни в строках mysql, ни в PDO.

Ваша проблема вызвана чем-то другим.

Выберите существующее значение из базы данных и закодируйте его, чтобы увидеть все непечатаемые символы:

echo rawurlencode($value);

а потом сравните.

Подлинная строка ABCD. Status ABCD (6): (fail) сделает

ABCD.%20Status%20ABCD%20%286%29%3A%20%28fail%29

в то время как один из базы данных что-то другое. Сравните и проверьте разницу.

person Your Common Sense    schedule 03.03.2017
comment
Используется rawurlencode($value); на тестовой странице для проверки ввода и вывода. получил его на работу. Кажется, вы правы (конечно;)). Я лучше посплю, а завтра снова прогоню код. - person Jakob Brøgger; 03.03.2017
comment
Выяснилось, что проблема на самом деле заключалась в том, что некоторые из отправленных сигналов тревоги содержали двойные кавычки (), а сохраненная копия имеет вид %22 (закодированный URL-адрес). - person Jakob Brøgger; 03.03.2017