То, что символ зарезервирован в общем компоненте URL-адреса, не означает, что он должен быть экранирован, когда он появляется в компоненте или в данных в компоненте. Символ также должен быть определен как разделитель в общем синтаксисе или синтаксисе конкретной схемы, и внешний вид символа должен находиться в пределах данных.

Текущий стандарт для универсальных URI - это RFC 3986, в котором говорится следующее:

2.2. Зарезервированные символы

URI включают компоненты и подкомпоненты, разделенные символами в «зарезервированном» наборе. Эти символы называются «зарезервированными», потому что они могут (или не могут) определяться как разделители общим синтаксисом, синтаксисом каждой схемы или синтаксисом конкретной реализации алгоритма разыменования URI. Если данные для компонента URI будут конфликтовать с назначением зарезервированного символа в качестве разделителя [выделено мной], то конфликтующие данные должны быть закодированы в процентах до формирования URI.

   reserved    = gen-delims / sub-delims

   gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

   sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
               / "*" / "+" / "," / ";" / "="

3.3. Компонент пути

[...]

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

[...]

3.4 Компонент запроса

[...]

      query       = *( pchar / "/" / "?" )

Таким образом, запятые явно разрешены в строках запроса и должны быть экранированы в данных только в том случае, если определенные схемы определяют это как разделитель. Схема HTTP не использует запятую или точку с запятой в качестве разделителя в строках запроса, поэтому их не нужно экранировать. Другой вопрос, соответствуют ли браузеры этому стандарту.

Использование CSV должно нормально работать для строковых данных, вам просто нужно следовать стандартным соглашениям CSV и либо заключать данные в кавычки, либо экранировать запятые с помощью обратной косой черты.

Что касается RFC 2396, он также позволяет использовать неэкранированные запятые в строках HTTP-запроса:

2.2. Зарезервированные символы

Многие URI включают компоненты, состоящие из определенных специальных символов или разделенные ими. Эти символы называются «зарезервированными», поскольку их использование в компоненте URI ограничено их зарезервированной целью. Если данные для компонента URI будут конфликтовать с зарезервированной целью, то конфликтующие данные должны быть экранированы перед формированием URI.

Поскольку запятые не имеют зарезервированной цели в схеме HTTP, их не нужно экранировать в данных. Замечание из п. 2.3 о зарезервированных символах, которые изменяют семантику при процентном кодировании, применяется только в общем случае; символы могут быть закодированы в процентах без изменения семантики для конкретных схем и при этом оставаться зарезервированными.

Чтобы ответить, что допустимо в строке запроса, я проверил, какие специальные символы заменяются хромом при выполнении запроса:

Space -> %20
! -> !
" -> %22
# -> removed, marks the end of the query string
% -> %
& -> &
' -> %27
( -> (
) -> )
* -> *
+ -> + (this usually means blank when received at the server, so encode if necessary)
, -> ,
- -> -
. -> .
/ -> /
: -> :
; -> ;
< -> %3C
= -> =
> -> %3E
? -> ?
@ -> @
[ -> [
\ -> \
] -> ]
^ -> ^
_ -> _
` -> `
{ -> {
| -> |
} -> }
~ -> ~

Extended ASCII (like °) -> Every character from this set is encoded

Примечание. Это, вероятно, не означает, что вам не следует экранировать символы, которые не были заменены при создании URI для ссылок. Например, часто рекомендуется не использовать ~ в URI из-за проблем совместимости, но это все еще допустимый символ.

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

Итак, чтобы ответить, что следует закодировать: недопустимые символы и символы, которые вы хотите рассматривать буквально, но имеют особое значение или могут вызвать проблемы на стороне сервера.

Просто используйте ?q=1+2+3

Я отвечаю здесь на четвертый вопрос :), который не задавал, но все началось с: как передать список чисел а-ля значения, разделенные запятыми? Мне кажется, что лучший подход - просто передать их через пробел, где пробелы будут закодированы в форме URL до +. Отлично работает, если вы знаете, что значения в списке не содержат пробелов (а числа, как правило, не содержат).

page.html? q = 1; q = 2; q = 3

это действительный URL?

да. ; зарезервирован, но не RFC. Контекст, определяющий этот компонент, - это определение типа мультимедиа application/x-www-form-urlencoded, который является частью стандарта HTML (раздел 17.13.4.1). В частности, скрытая записка, спрятанная в разделе B.2.2:

Мы рекомендуем, чтобы разработчики HTTP-сервера, и в частности разработчики CGI, поддерживали использование; вместо &, чтобы избавить авторов от необходимости экранировать символы & таким образом.

К сожалению, многие популярные серверные инфраструктуры сценариев, включая ASP.NET, не поддерживают такое использование.

Я хотел бы отметить, что page.html?q=1&q=2&q=3 также является допустимым URL-адресом. Это вполне законный способ выражения массива в строке запроса. Ваша серверная технология определит, как именно это будет представлено.

В классическом ASP вы проверяете Response.QueryString("q").Count, а затем используете Response.QueryString("q")(0) (и (1) и (2)).

Обратите внимание, что вы тоже видели это в своем ASP.NET (я думаю, что это не было предназначено, но посмотрите):

Default.aspx?a=1;a=2&b=1&a=3

Request.QueryString["a"] = "1;a=2,3"
Request.QueryString["b"] = "1"

Обратите внимание, что точка с запятой игнорируется, поэтому вы указали a дважды и дважды получили его значение, разделенное запятой. Использование всех амперсандов Default.aspx?a=1&a=2&b=1&a=3 даст a как «1,2,3». Но я уверен, что есть способ получить каждый отдельный элемент, если сами элементы содержат запятые. Это просто свойство по умолчанию для неиндексированной QueryString, которое объединяет вложенные значения вместе с разделителями-запятыми.

Я была такая же проблема. URL-адрес, на который была сделана гиперссылка, был сторонним URL-адресом и ожидал список параметров ТОЛЬКО в формате page.html?q=1,2,3, а URL-адрес page.html?q=1%2C2%2C3 не работал. Мне удалось заставить его работать с помощью javascript. Возможно, это не лучший подход, но вы можете проверить решение здесь, если оно кому-то поможет.

Если вы отправляете закодированные символы в файл FLASH / SWF, вам следует КОДИРОВАТЬ символ дважды !! (из-за парсера Flash)