UrlEncoding-Safe Delimiter

Question

Таким образом, сайт, на котором я работаю, имеет систему фильтров, которая работает путем передачи системы ключей и значений через строку запроса.

Весь сайт скоро подвергнется повторному фактору, и я поддерживаю существующий сайт, поэтому, прежде чем мы обсудим ПРАВИЛЬНЫЙ способ реализации этого, мне просто нужны идеи для изменения моего разделителя.

Текущий формат выглядит так:

cf=<key>:<value>

Проблема в том, что я недавно столкнулся с проблемой, потому что некоторые из наших новых значений для этого фильтра содержат :. Т.е.: cf=MO_AspectRatio:16:10

Значение - это с кодировкой UrlEn, но браузеры де-кодируют% 3a в: на лету, потому что: по сути не нарушает URL.

Мне нужны предложения по безопасным URL-адресам, которые не имеют смысла :, -, _, &, ?. Я не ищу решения вроде () или чего-то дикого.

Answer 1

Эта статья в Википедии полезна для получения дополнительной информации о незарезервированных и зарезервированных символах.

Пока тильда ~ , вероятно, лучший вариант. Но есть вероятность, что он рано или поздно сломается. Или вы должны документально подтвердить и подтвердить это при вводе пользователем.

Answer 2

А как насчет трубы?

cf=MO_AspectRatio|16:10

Answer 3

Общий синтаксис схемы URI допускает два допустимых разделителя параметров: & и ;. Я всегда видел первое и никогда не позднее. Символ ? необходим для правильной идентификации начала строки запроса, поэтому я бы не рекомендовал его использовать. То же самое относится к /, используемому в URL.

Любой символ, который не является одним из них и не является частью ваших значений, является приемлемым. Вот список возможных, отсортированных по моим собственным предпочтениям, за исключением тех, которые вы явно отклонили:

, + | # $ !

Любой из них должен сделать.

Кроме того, даже если вы специально просили не делать этого: в будущем рефакторинге попробуйте использовать реальные параметры URI (используя &). Избавит вас от головной боли.

Answer 4

Самым простым решением является кодирование base64 всей строки, а затем декодирование base64 на входе.

Другой вариант - дважды кодировать его перед выводом, а затем один раз кодировать его при вводе (на всех входных данных будет выполняться автоматический url-код php, или, возможно, apache не уверен, кто это делает).