Смутно о escape-строке и о том, как она хранится в базе данных
В моем MySQL-вызове я избегаю строки с обратной косой чертой:
UPDATE `TABLE` SET `PERSONAL_BELONGINGS` = 'Tom\'s things' Но когда я смотрю в phpadmin – значение было сохранено следующим образом:
|Tom's things|
Почему обратная косая черта не сохраняется в базе данных? Это вызывает проблемы, когда я читаю это значение в javascript, а затем пытаюсь передать его – мои строки javascript прекратятся. Вот почему я сбежал от персонажа для начала.
Почему MySQL удаляет обратную косу «\» до ее сохранения в базе данных?
Если не сохранить его в базе данных с помощью «\» – что тогда лучше всего справиться с этим, поскольку вы передаете его обратно в javascript в виде строки? Чтобы избежать его снова, когда он передан как строка в javascript?
Позвольте мне начать с того, что вам действительно не нужно хранить данные в каком-либо конкретном экранированном формате в базе данных, вы позже пожалеете об этом, если вам нужно будет извлечь его в другом формате или позже искать данные по какой-либо причине. Формат, который вы сохраняете, теперь выглядит хорошо, и добавление обратных косых черт для Javascript лучше выполняется в коде при передаче данных в фактический Javascript.
Вот почему он сейчас ведет себя так же, как и он;
В строке 'Tom\'s things' \' является символьной escape-последовательностью и на самом деле используется только для того, чтобы позволить MySQL понять, как разбирать строку SQL, она никогда не сохраняется как есть в базе данных.
Причина, по которой вы избегаете символа в выражении SQL, который вы показываете для начала, заключается в том, что иначе MySQL не знает, что строка не заканчивается в одиночной кавычке после 'Tom .
Если вы используете подготовленные операторы MySQLi или PDO вместо того, чтобы самостоятельно создавать свои SQL-запросы, MySQL позволит вам полностью сохранить значения без каких-либо проблем. Это, безусловно, предпочтительный вариант, поскольку API-интерфейс MySQL, который не поддерживает подготовленные заявления, в любом случае устарел.
Обратная косая черта рассматривается как « escape-символ ». Если бы не было обратной косой черты, ваша строка закончилась бы с Tom но остальные s things могли бы вызвать синтаксическую ошибку.
\ Говорит MySQL, чтобы он не обрабатывал escape-код в качестве разделителя строк, но продолжал до тех пор, пока не будет найден следующий unescaped.
Этот escape-символ используется только для целей запроса и не рассматривается как часть строки, которую вы хотите обновить.
Как и Элвин, предлагаемый в комментариях, если вы хотите сохранить обратную косую черту в своей базе данных, вы должны добавить ее, добавив еще одну escape-косую черту, т.е. \\ . Это сделает ваш запрос похожим:
UPDATE `TABLE` SET `PERSONAL_BELONGINGS` = 'Tom\\\'s things'
И данные в базе данных будут выглядеть так:
|Tom\'s things|
Вы можете больше узнать о строковых литералах и экранировании специальных символов в MySQL Manual
Однако стоит отметить, что сохранение уже сбежавшей строки в базе данных является плохой практикой. Вы должны позаботиться об эвакуации специальных символов в свой код.
Потому что в MySQL обратная косая черта – это escape-символ (точно так же, как в PHP). Вы должны избегать обратной косой черты, чтобы сохранить ее, поэтому \\ сохранит один обратный слэш. \\\' будет хранить обратную косую черту с последующей цитатой, так как первая обратная косая черта избегает второго, а третий ускользает от цитаты.
Это вызывает проблемы, когда я читаю это значение в javascript
Конечно, этого не происходит .
Затем вы запираете свои деньги в сейфе, вы можете обвинить безопасного производителя, если его ограбят.
Но как только вы вернете свои деньги и их украли, вы все еще не можете обвинять в этом сейф.
Теперь это ваша ответственность.
Итак, если вам нужны ваши данные, которые можно использовать для javascript – просто избегайте этого.
Но, конечно, не используя mysql _escape_string ()