Международные символы в имени файла в форм-данных mutipart

Question

Я использую компоненты Apache HTTP (4.1-alpha2) для загрузки файлов в Dropbox. Это делается с использованием данных многочастной формы. Как правильно кодировать имена файлов в многочастной форме, содержащей международные (не ascii) символы?

Если я использую там стандартный API, сервер возвращает HTTP-статус Forbidden. Если я изменяю код загрузки, чтобы имя файла кодировалось:

MultipartEntity entity = new MultipartEntity(HttpMultipartMode.BROWSER_COMPATIBLE);
FileBody bin = new FileBody(file_obj, URLEncoder.encode(file_obj.getName(), HTTP.UTF_8), HTTP.UTF_8, HTTP.OCTET_STREAM_TYPE );
entity.addPart("file", bin);            
req.setEntity(entity);

Файл загружен, но я получаю имя файла, которое все еще закодировано. Например. % D1% 82% D0% B5% D1% 81% D1% 82.txt * * +1006

Answer 1

Чтобы решить эту проблему специально для сервера dropbox, мне пришлось закодировать имя файла в utf8.Чтобы сделать это, я должен был объявить мою составную сущность следующим образом:

MultipartEntity entity = new MultipartEntity(HttpMultipartMode.BROWSER_COMPATIBLE, null, Charset.forName(HTTP.UTF_8));

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

Для тех, кто интересуется, что стандарты должны сказать по этому поводу, я немного ознакомился с RFC.Если стандарт строго соблюдается, то все заголовки должны быть закодированы в 7 бит, что сделает кодирование имени файла utf8 недопустимым.Однако RFC2388 () заявляет:

Можно также указать исходное имя локального файла, либо в качестве параметра «filename», либо в заголовке «content-disposition: form-data», либо вв случае нескольких файлов, в заголовке «content-disposition: file» подпункта.Отправляющее приложение МОЖЕТ предоставить имя файла;если имя файла операционной системы отправителя отсутствует в US-ASCII, имя файла может быть приблизительно или закодировано с использованием метода RFC 2231.

Во многих публикациях упоминается использование либо rfc2231, либо rfc2047 длязаголовки кодирования в не-US-ASCII в 7 бит.Однако rfc2047 явно указывает в разделе 5.3 кодированные слова, НЕ ДОЛЖНЫ использоваться в поле Content-Disposition.Это оставило бы только rfc2231, однако это расширение и нельзя полагаться на реализацию на всех серверах.Реальность такова, что большинство основных браузеров отправляют символы не-US-ASCII в UTF-8 (отсюда режим HttpMultipartMode.BROWSER_COMPATIBLE в HTTP-клиенте Apache), и поэтому большинство веб-серверов будут поддерживать это.Следует также отметить, что если вы используете HttpMultipartMode.STRICT для составного объекта, библиотека фактически заменит не-ASCII знак вопроса (?) В имени файла. S

Answer 2

Я бы подумал, что реализация FileBody будет нести ответственность за применение соответствующих правил из самого RFC 2047 . Имя файла будет тогда закодировано как =?UTF-8?Q?=D1=82=D0=B5=D1=81=D1=82.txt?= или что-то очень похожее.

Answer 3

Быстрое исправление:

new String(multipartFile.getOriginalFilename().getBytes ("iso-8859-1"), "UTF-8");