почему php не может просто конвертировать кавычки в html-сущности для mysql?

Question

PHP по умолчанию использует "волшебные кавычки", но за это получил много шума. Я понимаю, что это отключит его в следующей основной версии PHP.

Хотя аргументы против этого имеют смысл, я не понимаю, почему бы просто не использовать сущности HTML для представления кавычек вместо того, чтобы удалять и удалять косые черты? В конце концов, большая часть MySQL используется для вывода в веб-браузеры?

Например, вместо «используется», и это никак не повлияет на базу данных.

Другой вопрос, почему PHP не может просто настроить конфигурации для каждой версии PHP с этим тегом <? Php4 или <? Php5, чтобы соответствующие интерпретаторы могли быть загружены для этих версий? </p>

Просто любопытно. :)

Answer 1

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

Лучше избегать вывода во время его вывода. Это единственный раз, когда вы точно знаете, что вывод идет на веб-страницу, а не на файл журнала, электронную почту или другое назначение.

PS: PHP уже отключает магические кавычки по умолчанию в стандартном файле php.ini. Это устарело в PHP 5.3 и полностью удалено из языка в PHP 6.0.

Answer 2

Вот веская причина, в основном в ответ на ваш собственный опубликованный ответ: использование htmlspecialchars() или htmlentities() делает не делает ваш SQL-запрос безопасным . Вот для чего mysql_real_escape_string () .

Похоже, вы предполагаете, что проблема заключается только в одинарных и двойных кавычках. Запросы MySQL фактически уязвимы для символов \x00, \n, \r, \, ', " и \x1a в ваших данных. Если вы не используете подготовленные операторы или mysql_real_escape_string(), значит, у вас есть уязвимость внедрения SQL.

htmlspecialchars() и htmlentities() не преобразуют все эти символы, поэтому вы не можете сделать ваш запрос безопасным, используя эти функции. С этой целью addslashes() также не делает ваш запрос безопасным!

Другие меньшие недостатки включают в себя то, что другие авторы уже упоминали о MySQL, который не всегда используется для веб-контента, а также тот факт, что вы увеличиваете объем хранилища и индексное пространство, необходимое для ваших данных. (рассмотрите один байт памяти для символа кавычки, по сравнению с шестью или более байтами памяти для его формы сущности).

Answer 3

Я отвечу только на ваш первый вопрос.

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

Приятно видеть, что происходит magic_quotes; это является причиной многих проблем безопасности с PHP, и приятно видеть, что они принимают новый подход:)

Вы окажете себе большую услугу, если перефразируете свои подходы валидации для валидации в OUTPUT, для контекста, в котором вы работаете. Это может знать только вы, как программист.

Answer 4

Причина, по которой MySQL не конвертирует ' в ', заключается в том, что ' не '. Если вы хотите преобразовать ваши данные для вывода, вы должны делать это на уровне представления, а не в вашей базе данных. На самом деле не очень сложно просто позвонить htmlentities до / после эха.

Answer 5

Вы не можете просто конвертировать ' в '. Подумайте об этом: что происходит, когда вы хотите сохранить строку "'"? Если вы сохраняете ', то при загрузке страницы будет отображаться ', а не '.

Так что теперь вам нужно конвертировать ВСЕ HTML-сущности, а не только кавычки. Тогда вы начинаете сталкиваться со всевозможными странными проблемами конверсии. Самое простое решение - просто сохранить реальные данные в базе данных, и затем вы можете отобразить их так, как вам нравится. Возможно, вы захотите использовать настоящие кавычки - в большинстве случаев " и ' не наносят вреда за пределами скобок тега.

Иногда вам может потребоваться сохранить фактический HTML-код в поле и отобразить его в необработанном виде (при условии, что он проверен и очищен при входе / выходе.

Answer 6

Спасибо всем. Я должен был ДЕЙСТВИТЕЛЬНО подумать, что вы имели в виду и какие последствия это может иметь, если я заменю кавычки на объекты HTML вместо добавления косой черты к ним, но опять же, разве это тоже не меняет вывод / ввод?

Я не могу придумать причину, по которой мы НЕ МОЖЕМ или НЕ ДОЛЖНЫ использовать сущности HTML для mySQL, если мы даем понять, что все данные кодируются с использованием сущностей HTML. В конце концов, мой аргумент основан на том факте, что большая часть mySQL используется для вывода в HTML-браузеры, а также на том факте, что «и» и / могут нанести серьезный вред базам данных MySQL. Так не правда ли безопаснее кодировать »и "и / как объекты HTML перед отправкой их в виде запросов INSERT? Кроме того, мы собираемся использовать XML, так зачем тратить время на написание htmlentities, полосы и слэши и надстроек при доступе к данным, которые УЖЕ закодированы в сущностях HTML?