2010-01-07 2 views
4

Предполагая, что мой проект является 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 не предлагает, тоже. Пока что просмотр моей песочницы проекта с изменениями также говорит «нет». Тем не менее, я не уверен, что я что-то пропускаю.

+0

Я знаю, что у меня были проблемы с «utf-8» как аргумент htmlentities, но, к сожалению, я не могу точно вспомнить, что это такое. Однако, обратите внимание на «умные кавычки» Windows-1252 (обычно из MS Word) и другие символы в этом диапазоне (особенно в содержимом, представленном пользователем). В частности, UTF8 использует диапазон '\ xC280- \ xC29F' и Windows-1252' 'x80- \ x9F''; а также высокие символы ASCII '\ x81 \ x8D \ x8F \ x90 \ x9D'. –

+0

@Frank, но они не будут подвержены htmlspecialchars(), они? htmlspecialchars() делает только '&" '<> '. htmlentities() - это другое дело. –

+0

Хороший улов на htmlentities(). Это, вероятно, будет сложнее, и хорошо иметь в виду. Спасибо за отзыв, ребята ! – pinkgothic

ответ

5

Я думаю, что цитата из PHP руководства в другой вопрос отвечает это определенно:

Для целей этой функции, то кодировок ISO-8859-1, ISO-8859-15, UTF-8 , cp866, cp1251, cp1252 и KOI8-R фактически эквивалентны, так как символы, затронутые htmlspecialchars(), занимают одинаковые позиции во всех этих кодировках.

"&> и так далее все они имеют один и тот же код в каждом из этих кодировок, и даже в UTF-8, они требуют только одного байта, так как UTF-8 символов будет занимать несколько байт только тогда, когда это необходимо. Поэтому, даже если вы обрабатывали данные UTF-8 с ISO-8859-1 до сих пор, выход будет идентичным при переключении на явный ввод UTF-8.

+0

Мне нравится, когда люди просто цитируют руководство! (Т.е. + 1 для RTXM) –

+0

Фактически это цитата из вопроса, на которую ссылается @pinkgothic, поэтому это не было * действительно * означало как RTFM :) –

+1

Да, я так рассчитывал. Спасибо, что подтвердил и успокоил мою паранойю: D Очень благодарен. – pinkgothic

-1

Нет, это не будет отличаться, потому что если вы не предоставили какой-либо кодировки, PHP угадает, поэтому он будет использовать UTF-8.

+2

То есть * полностью * неправильный PHP <5.4.0 будет * предполагать * ISO-8859-1 и> = 5.4.0 будет * предполагать * UTF-8. –