>>27379
Против urldecode в парсере разметки у меня есть три возражения:
(1) Эта функция попросту не предназначена для того, чтобы ей скармливали целый URL (а не некую подстроку URL). Она может исказить его (из URL с одним параметром запроса получится URL с двумя):
$ php -r 'printf("%s\n", urldecode("https://example.org/path?query=x%26y%3Dz"));'
https://example.org/path?query=x&y=z
(2) Вызов этой функции может привести к тому, что корректная с точки зрения стандарта ссылка не сможет быть запощена: https://example.org/path?query=%FF
является корректной ссылкой, ибо нигде не сказано, что URL encoded-сегменты обязаны быть валидным UTF-8. Более того, и по сей день существуют серверы, которые принимают запросы в кодировках, отличных от UTF-8: например, поиск Google по адресу https://www.google.com/search?q=%FF
у меня (ваш результат может отличаться) интерпретирует этот один байт 0xFF как букву «я» в кодировке cp1251 (скриншот прилагаю). А в результате декодирования получается невалидный UTF-8, который невозможно вставить в БД.
(3) Это браузер пользователя делает URLы читаемыми или же нечитаемыми: можно запостить https://ru.wikipedia.org/wiki/Красота
, а можно и https://ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0
. Я всего лишь предлагаю отображать ссылки так, как их запостил пользователь. То, что ваш браузер вставляет «%D0%9A%D1%80%D0%B0%D1%81%D0%BE%D1%82%D0%B0» вместо «Красота» при копировании URL, так это особенность вашего браузера, которую, скорее всего, можно решить его настройкой.
На практике декодирование вызывает (вместе с принудительным разбиением на слова) проблему >>/d/3043, а также другую проблему. Если эти проблемы будут тем или иным образом решены, то вопрос о том, нужно ли декодировать, с моей точки зрения, не будет очень существенным. Просто оно для этого не предназначено.
