QueryString malformed after URLDecode


15

Я пытаюсь передать строку Base64 в веб-приложение C# .Net через QueryString. Когда строка прибывает, знак «+» (плюс) заменяется пробелом. Похоже, что это делает автоматический процесс URLDecode. У меня нет контроля над тем, что передается через QueryString. Есть ли способ справиться с этой серверной стороной?

Пример:

http://localhost:3399/Base64.aspx?VLTrap=VkxUcmFwIHNldCB0byAiRkRTQT8+PE0iIHBsdXMgb3IgbWludXMgNSBwZXJjZW50Lg== 

Производит:

VkxUcmFwIHNldCB0byAiRkRTQT8 PE0iIHBsdXMgb3IgbWludXMgNSBwZXJjZW50Lg== 

Люди предложили URLEncoding строки запроса:

System.Web.HttpUtility.UrlEncode(yourString) 

Я не могу сделать это, как я не имею никакого контроля над вызовом (который отлично работает с другими языками).

Существовал также предложение о замене пространств со знаком плюс:

Request.QueryString["VLTrap"].Replace(" ", "+"); 

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

Моя основная цель - перехватить QueryString до того, как она будет запущена через декодер.

С этой целью я попытался взглянуть на Request.QueryString.toString(), но это содержало ту же неверную информацию. Есть ли способ взглянуть на необработанный QueryString до, это URLDecoded?

После дополнительных испытаний выяснилось, что .Net ожидает, что все, входящее в QuerString, будет закодировано в URL, но браузер не будет автоматически кодировать GET-запросы.

  0

ОК, так что теперь я полностью в догадках, как SO работает.В вопросе явно указано, что нет способа изменить то, что передано в QueryString, но все правильные ответы (т. Е. Заменить пространство на плюс до base64-декодирования) были проголосованы. Go figure ... 23 сен. 082008-09-23 22:32:06

11

Вы можете вручную заменить значение (argument.Replace(' ', '+')) или обратитесь к HttpRequest.ServerVariables["QUERY_STRING"] (еще лучше HttpRequest.Url.Query) и разобрать его самостоятельно.

Вы должны попытаться решить проблему, в которой указан URL; знак плюса должен быть закодирован как «% 2B» в URL-адресе, потому что плюс в противном случае представляет собой пробел.

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

+2

Самый простой способ сделать это - использовать Uri.EscapeDataString/Uri.UnescapeDataString. 09 дек. 112011-12-09 20:46:47


1

Если вы URLEncode строку перед добавлением ее в URL-адрес, у вас не будет ни одной из этих проблем (автоматический URLDecode вернет его в исходное состояние).


0

Я ни в коем случае не разработчик C#, но похоже, что вам нужно указать ENCODE свою строку Base64 перед отправкой его в качестве URL-адреса.

+1

У него нет контроля над URL-адресом - см. Его вопрос. 23 сен. 082008-09-23 21:36:24


0

Не могли бы вы просто предположить, что пространство есть + и заменить его?

Request.QueryString["VLTrap"].Replace(" ", "+"); 

;)


1

Ну, очевидно, вы должны иметь строку Base64 URLEncoded перед отправкой его на сервер.
Если вы не можете этого сделать, я бы предложил просто заменить любые встроенные пространства на +; так B64 строки не suposed иметь пробелы, его законную тактику ...

  0

«Ну, очевидно, вы должны иметь строку Base64 URLEncoded перед отправкой на сервер» ... он сказал, что он не контролирует это. 23 сен. 082008-09-23 21:43:03

  0

Отсюда очевидно ... и альтернатива потом. 23 сен. 082008-09-23 23:06:10


1

System.Web.HttpUtility.UrlEncode(yourString) будет делать трюк.


1

В качестве быстрого взлома вы можете заменить пространство символом плюс до base64-декодирования.


14

Предлагаемое решение:

Request.QueryString["VLTrap"].Replace(" ", "+"); 

должно работать нормально. Что касается вашей озабоченности:

У меня было это, но я беспокоился об этом, и я должен был упомянуть об этом, чтобы начать, это то, что я не знаю, какие другие символы могут быть искажены в дополнение к знаку плюса ,

Это легко устранить reading about base64. Единственными не буквенно-цифровыми символами, которые являются законными в современной базе64, являются «/», «+» и «=» (которые используются только для заполнения).

Из них «+» - это единственное, что имеет особое значение как экранированное представление в URL-адресах. В то время как другие два имеют особое значение в URL-адресах (разделитель путей и разделитель строки запроса), они не должны создавать проблемы.

Поэтому я думаю, что все должно быть в порядке.


4

У меня такая же проблема, за исключением того, что у меня есть контроль над моим URL. Даже с Server.URLDecode и Server.URLEncode она не преобразует его обратно в + знак, даже если моя строка запроса выглядит следующим образом:

 
http://localhost/childapp/default.aspx?TokenID=0XU%2fKUTLau%2bnSWR7%2b5Z7DbZrhKZMyeqStyTPonw1OdI%3d 

Когда я выполнить следующее.

string tokenID = Server.UrlDecode(Request.QueryString["TokenID"]); 

это еще не превращает %2b обратно в + знак. Вместо этого я должен сделать следующее:

string tokenID = Server.UrlDecode(Request.QueryString["TokenID"]); 
tokenID = tokenID.Replace(" ", "+"); 

Тогда он работает правильно. Действительно странно.

+5

У меня была такая же проблема. Похож на 'Request.QueryString [" TokenID "]' возвращает уже строку с URL-адресом. Передав его Server.UrlDecode, вы дважды выполняете urldecoding. 11 янв. 122012-01-11 19:55:17


2

У меня была аналогичная проблема с параметром, который содержит значение Base64, и когда он поставляется с '+'. Только Request.QueryString ["VLTrap"]. Заменить ("", "+"); отлично работал для меня; no UrlEncode или другое кодирование помогает, потому что даже если вы показываете закодированную ссылку на странице самостоятельно с «+», закодированной как «% 2b», то это браузер, который сначала меняет ее на «+», когда она отображается, и когда вы нажимаете на нее, браузер меняет его на пустое пространство. Поэтому нет никакого способа контролировать это, поскольку оригинальный плакат говорит, даже если вы показываете ссылки сами. То же самое с такими ссылками даже в html-письмах.


1

Если вы используете System.Uri.UnescapeDataString(yourString), он будет игнорировать +. Этот метод следует использовать только в таких случаях, как ваш, когда строка была закодирована с использованием какого-то устаревшего подхода на клиенте или сервере.

Смотрите этот блог: http://blogs.msdn.com/b/yangxind/archive/2006/11/09/don-t-use-net-system-uri-unescapedatastring-in-url-decoding.aspx