Ожидается ли эта функциональность от пользователей веб-сайтов, говорящих на японском / китайском?
Да.
Делать это легко, или это чревато опасностью?
Есть проблемы. Если вы обслуживаете файлы напрямую или у вас есть имя файла в URL-адресе (например: http://www.example.com/files/こんにちは.txt -> http://www.example.com/files/%E3%81%93%E3%82%93%E3%81%AB%E3%81%A1%E3%81%AF.txt),, вы в целом в порядке.
Но если вы обслуживаете файлы с именем файла, сгенерированным сценарием, у вас могут возникнуть проблемы. Вопрос с заголовком:
Content-Disposition: attachment;filename="こんにちは.txt"
Как мы кодируем эти символы в параметре имени файла? Ну, было бы неплохо, если бы мы просто добавили его в UTF-8. И это будет работать в некоторых браузерах. Но не IE, который использует системную кодовую страницу для декодирования символов из заголовков HTTP. В Windows системной кодовой страницей может быть cp1252 (Latin-1) для западных пользователей или cp932 (Shift-JIS) для японского, или что-то еще полностью, но это никогда не будет UTF-8, и вы не можете точно догадаться, что это будет заблаговременно до отправки заголовка.
Утомительно: что должно произойти в стандарте? Ну, это не совсем так. Стандарт HTTP, RFC2616, говорит, что байты в заголовках HTTP соответствуют ISO-8859-1, что не позволяет нам использовать японский язык. Далее говорится, что нелатинские символы 1 могут быть встроены в заголовок по правилам RFC2047, но RFC2047 явно отрицает, что его закодированные слова могут помещаться в строку в кавычках. Обычно в заголовках семейства RFC822 вы используете правила RFC2231 для встраивания символов Юникода в параметр заголовка Content-Disposition (RFC2183), а RFC2616 откладывает обращение к RFC2183 для определения этого заголовка. Но HTTP на самом деле не является протоколом семейства RFC822, и его синтаксис заголовка все равно не полностью совместим с семейством 822. Таким образом, стандарт представляет собой кровавую неразбериху, и никто не знает, что делать, конечно, не производители браузеров, которые вообще не обращают на это внимания. Черт, они даже не могут получить правильный формат ‘filename =" ... "в формате" кавычка ", не говоря уже о кодировке символов.
Таким образом, если вы хотите динамически обрабатывать файл с не-ASCII-символами в имени, уловка заключается в том, чтобы не посылать параметр «filename» и вместо этого выводить имя файла, которое вы хотите, в завершающей части URL.
Должны ли расширения файлов также быть символами международного языка?
В принципе, да, расширения файлов являются лишь частью имени файла и могут содержать любой символ.
На практике в Windows я не знаю ни одного приложения, которое когда-либо использовало расширение не-ASCII.
И последнее, на что нужно обратить внимание в системах для восточноазиатских пользователей: вы обнаружите, что они иногда печатают странные, не ASCII-версии латинских символов. Они известны как формы полной ширины и полуширины и предназначены для того, чтобы азиаты могли вводить латинские символы, которые совпадают с квадратной сеткой, используемой их идеографическими символами (хань и т. Д.).
Это все очень хорошо в свободном тексте, но для полей, которые вы собираетесь анализировать как латинский текст или числа, получение неожиданного расширения ‘inte’ integer или ‘．ｔｘｔ может сбить вас с толку. Чтобы преобразовать эти «символы совместимости» в обычную латиницу, нормализуйте строки в «Unicode Normal Form NFKC», прежде чем что-либо делать с ними.