Почему делает HttpUtility. UrlEncode (HttpUtility. UrlDecode (“%20”)), возвращаются + вместо %20?
3 ответа
Цитата из этой ссылки
Я сам сталкивался с этим. если ты могут менять пробелы на% 20s то IE7 их правильно конвертирует. Firefox хоть возьмет их буквально (по крайней мере, при использовании Заголовок Content-disposition), чтобы вы это нужно будет сделать для запросов от Только для IE 7.
В нашем приложении мы сделали следующее. (а репозиторий документов на основе tomcat)
String userAgent = request.getHeader ("User-Agent"); if (userAgent.contains ("MSIE 7.0")) { filename = filename.replace ("", "% 20"); } response.addHeader ("Размещение содержимого", "вложение; имя файла = \" "+ имя файла +" \ "");
Обычно и% 20, и + являются допустимыми способами кодирования пробела. Очевидно, что метод UrlEncode должен выбрать один из вариантов ... если бы он выбрал другой способ, кто-то еще спросил бы, почему UrlEncode (UrlDecode ("+")) вернул «% 20» ...
Вы всегда можете его закодировать, а затем просто замените прямую строку на «+» на «% 20». Я думаю , что сработает ...
Я подумал, что лучшим вариантом будет UrlEncode для имени файла
Это неправильный способ помещать внеполосные символы в параметр заголовка, такой как Content-Disposition-filename, и работает (иногда) только в IE из-за ошибки. На самом деле это извечная проблема: нет правильного пути .
Если вам нужно вставить специальные символы в загруженное имя файла, вы не сможете сделать это надежно с Content-Disposition-filename. Вместо этого опустите параметр 'filename' в заголовке Content-Disposition-attachment и оставьте имя файла, которое вы хотите, в конечной части URL-адреса. В отсутствие параметра имени файла браузер будет брать его из пути URL, где кодирование URL является правильным способом обработки специальных символов.