Как использовать javax.mail.inte rnet .MimeBodyPart.setFileName, чтобы сохранить все символы? - PullRequest
Новая
       82

Как использовать javax.mail.inte rnet .MimeBodyPart.setFileName, чтобы сохранить все символы?

1 голос
/ 01 апреля 2020

Мне нужно создавать письма с использованием javax.mail версии 1.6.2, и я хотел бы как можно больше придерживаться высокоуровневых методов и хотел бы не заниматься кодировкой, свертыванием символов и всем необходимым для получения действительной почты. в конце.

Одна проблема, с которой я сейчас сталкиваюсь, - это имена файлов, потому что по умолчанию javax.mail.internet.MimeBodyPart.setFileName, кажется, кодирует любое заданное имя так, что мой почтовый клиент показывает его не так, как ожидалось. Рассмотрим следующее имя, переадресованное при вызове setFileName без какой-либо пользовательской кодировки или еще: 

meter_cnt_some_month_summary äöüßÄÖÜ.xml

Результат выглядит следующим образом в сгенерированной почте: 

Content-Type: application/xml; charset=UTF-8; 
    name*=UTF-8''meter_cnt_some_month_summary%20%C3%A4%C3%B6%C3%BC%C3%9F%C3%84%C3%96%C3%9C.xml
Content-Disposition: attachment; 
    filename*=UTF-8''meter_cnt_some_month_summary%20%C3%A4%C3%B6%C3%BC%C3%9F%C3%84%C3%96%C3%9C.xml

Пока это выглядит Хорошо, сначала мой почтовый клиент отображает _ как пробел:

Screenshot of mail client

И мой почтовый клиент, похоже, прав в этом решении согласно RF C 2047 :

(2) 8-битное шестнадцатеричное значение 20 (например, ISO-8859-1 SPACE) может быть представлено как "_" (подчеркивание, ASCII 95.). [...] Обратите внимание, что «_» всегда представляет шестнадцатеричное число 20, даже если символ ПРОБЕЛ занимает другую позицию кода в используемом наборе символов.

Поддержка RFC 2047 был недавно добавлен в пакет и может быть отключен путем установки специального системного свойства в FALSE. Но это не решает проблему, потому что это приводит только к UTF-8-байтам в заголовке, которые клиент не может использовать. 

System.setProperty("mail.mime.encodeparameters", Boolean.FALSE.toString())

Content-Type: application/xml; charset=UTF-8; 
    name="meter_cnt_some_month_summary äöüßÄÖÜ.xml"
Content-Disposition: attachment; 
    filename="meter_cnt_some_month_summary äöüßÄÖÜ.xml"

Screenshot of mail client

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

name = MimeUtility.encodeText(name, "UTF-8", "Q");

Content-Type: application/xml; charset=UTF-8; 
    name="=?UTF-8?Q?meter=5Fcnt=5Fsome=5Fmonth?=
 =?UTF-8?Q?=5Fsummary_=C3=A4=C3=B6=C3=BC=C3=9F=C3=84=C3=96=C3=9C.xml?="
Content-Disposition: attachment; 
    filename="=?UTF-8?Q?meter=5Fcnt=5Fsome=5Fmonth?=
 =?UTF-8?Q?=5Fsummary_=C3=A4=C3=B6=C3=BC=C3=9F=C3=84=C3=96=C3=9C.xml?="

Screenshot of mail client

Итак, RFC 2047 способен передавать имена файлов, содержащие подчеркивания вообще?

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

Или я что-то делаю не так, и мне также нужно указать другое имя файла?

Пытался заменить _ сам, например, =5F, но это не сработало. Поэтому единственное решение, которое я должен иметь возможность передавать имена файлов 1: 1, - это обходной путь, описанный выше. Что, по моему мнению, не должно быть необходимым или, по крайней мере, поведение по умолчанию, если RFC 2047 действительно так ограничено.

Или что мне здесь не хватает?

...