Предполагая, что мой проект является UTF-8 во всем и всегда используется с UTF-8 кодировкой, есть все законно, что могло сломаться, если я меняю все вхождения htmlspecialchars($var)
к htmlspecialchars($var, ENT_QUOTES, 'utf-8')
?Добавление параметра «utf-8» вхождения htmlspecialchars() - может ли он что-нибудь сломать?
Я знаю одно: очевидно, ENT_QUOTES
отличается от ENT_COMPAT
тем, что он также избегает одиночных кавычек. Предполагая, что я знаю, что это само по себе ничего не сломает, есть ли что-нибудь еще?
сформулирован иначе:
Есть ли мыслимые результат htmlspecialchars() при использовании без параметра кодировки, только Приведенных данных из кодировки, которая будет отличаться от htmlspecialchars() при использовании с параметром charset?
(Is, в любой момент, htmlspecialchars($stringThatIsValidUTF8, ENT_QUOTES) !== htmlspecialchars($stringThatIsValidUTF8, ENT_QUOTES, 'utf-8')
?)
Мое понимание не говорит, что нет, никогда. Another question here on stackoverflow не предлагает, тоже. Пока что просмотр моей песочницы проекта с изменениями также говорит «нет». Тем не менее, я не уверен, что я что-то пропускаю.
Я знаю, что у меня были проблемы с «utf-8» как аргумент htmlentities, но, к сожалению, я не могу точно вспомнить, что это такое. Однако, обратите внимание на «умные кавычки» Windows-1252 (обычно из MS Word) и другие символы в этом диапазоне (особенно в содержимом, представленном пользователем). В частности, UTF8 использует диапазон '\ xC280- \ xC29F' и Windows-1252' 'x80- \ x9F''; а также высокие символы ASCII '\ x81 \ x8D \ x8F \ x90 \ x9D'. –
@Frank, но они не будут подвержены htmlspecialchars(), они? htmlspecialchars() делает только '&" '<> '. htmlentities() - это другое дело. –
Хороший улов на htmlentities(). Это, вероятно, будет сложнее, и хорошо иметь в виду. Спасибо за отзыв, ребята ! – pinkgothic