У нас был международный клиент, спросивший о поведении Safari
Content-Disposition: attachment; filename=<customer file name>.pdf
Мы не тестировали международное использование наших функций записи в PDF, и они увидели, что Safari ведет себя странно для них.Это началось с мини-одиссеи, которую я сегодня рассмотрел.
В частности, когда у клиента был настроен Safari на Mac, настроенный для английского языка, наш pdf с японским именем сохранился очень хорошо (со стандартным поведением Asp.Net / IIS, сериализуя это поле как raw utf-8).Но когда они настроили свой браузер на японский язык, имя файла появилось в виде каждого сериализованного символа utf-8, рассматриваемого как Ascii.
Некоторое быстрое прибегание к гуглу получило кучу ссылок на Rfc5987 и Rfc8187 и множество постов здесьи в других местах о том, как они реализуются в отношении Content-Disposition: filename = ...
Проблема в том, что многие из этих постов относятся к 2007-2015 гг.
Я начал много пробоватьиз этих предложений по реализации Rfc5987 / 8187 для последней сборки Chrome, последней сборки Firefox, IE 11 и Edge (у меня нет Mac с удобной Safari) и вот что я нашел:
- IE11и Edge распознает, если filename = закодировано в url, и расшифрует его.Другие браузеры не будут.
- IE11, Edge и Safari на Mac (настроены на английском языке) примут имя файла = raw utf-8 и будут правильно обрабатывать его с японским именем
- Safari (с настройками на японском), а Firefox и Chrome примут имя файла = raw utf-8 в виде строки символов ascii
- Не один браузер Я реализовал любой из Rfc5987 / 8187.Не является функцией.
Я пытался
- filename = [версия в кодировке URL] .pdf;
- filename * = utf-8 '' [urlкодированная версия] .pdf (также UTF-8, когда не работает нижний регистр)
- filename = [как raw, так и url-кодированный] .pdf;имя файла * = utf-8 '' [закодированный url] .pdf
Только значения имени файла * были полностью проигнорированы во всех браузерах, которые у меня были под рукой.имя файла = ...;filename * = запустил; filename * = ... в результирующее имя файла.
Короче говоря, ни один браузер из 4 не реализовал ни одного бита Rfc 8187.
Но я 'мы видели ссылки на ядро Asp.Net (которое мы в настоящее время не используем), имеющее член FileNameStar в своей объектной модели ContentDispositionHeader, поэтому я думаю, что что-то там должно реализовывать Rfc 8187.
Но всепосты, которые я видел, исчезли примерно в 2015 году, и ни одна из вещей, которые я нахожу в них, кажется, не работает в доступных мне браузерах.
Есть ли у кого-нибудь более актуальные идеи о том, как получить браузеры?обрабатывать международные наборы символов в Content-Disposition: имя_файла = значения?
Я имею в виду, что пока единственные проблемы, о которых сообщают люди, связаны с Firefox и Safari, настроенными на что-то , а не американский английский;просто делать то, что естественно, кажется, работает во многих ситуациях.
Но было бы неплохо знать, как сделать это "правильно".
РЕДАКТИРОВАТЬ: примеры вывода, которые я пробовал
Content-Disposition: attachment; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf
Ни один браузер не прочитал это правильно.Все просто подставили «загрузить» в качестве имени.
Content-Disposition: attachment; filename=Fred.pdf; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf
Все протестированные браузеры создали файл с именем «Fred.pdf; имя файла * = utf-8''blahblahblah»
Content-Disposition: attachment; filename="Fred.pdf"; filename*=utf-8''%e6%8e%a1%e7%94%a8%e3%81%ab%e9%96%a2%e3%81%99%e3%82%8b%e5%90%84%e7%a8%ae%e6%9b%b8%e9%a1%9e.pdf
То же, что и в примере выше.
Также попробуйте все вышеперечисленное с UTF-8 вместо utf-8.
Спасибо