有没有人有过生成文件名包含非ascii国际语言字符的文件的经验?
这样做很容易实现,还是充满了危险?
这个功能是否适用于日语/中文网络用户?
文件扩展名是否也应该是国际语言字符?
信息:我们目前在我们的网站上支持多语言,但我们的文件名始终是ASCII.我们在.NET框架上使用ASP.NET.这将用于国际用户可以为文件选择通用格式和名称的情况.
这个功能是否适用于日语/中文网络用户?
是.
这样做很容易实现,还是充满了危险?
有问题.如果您直接提供文件,或者在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"
我们如何将这些字符编码为filename参数?如果我们可以将其转储到UTF-8中,那将是很好的.这将适用于某些浏览器.但不是IE,它使用系统代码页来解码来自HTTP头的字符.在Windows上,系统代码页可能是西方用户的cp1252(Latin-1),或者日语的cp932(Shift-JIS),或者完全不同的东西,但它永远不会是UTF-8,你无法猜到它是什么将在发送标题之前.
单调乏味:标准说应该发生什么?嗯,事实并非如此.HTTP标准RFC2616表示HTTP标头中的字节是ISO-8859-1,这不允许我们使用日语.接着说,RFC2047规则可以将非Latin-1字符嵌入到标题中,但RFC2047明确否认其编码字可以适合带引号的字符串.通常在RFC822系列标头中,您将使用RFC2231规则将Unicode字符嵌入到Content-Disposition(RFC2183)标头的参数中,而RFC2616确实遵循RFC2183来定义该标头.但HTTP实际上并不是RFC822系列协议,并且其头部语法无论如何都与822系列不完全兼容.总之,标准是一个血腥的混乱,没有人知道该怎么做,当然不是浏览器制造商谁也不关注它.天啊,他们甚至不能得到'filename ="..."'''的'引用字符串'格式,不管字符编码.
因此,如果要在名称中使用非ASCII字符动态地提供文件,那么诀窍是避免发送'filename'参数,而是将所需的文件名转储到URL的尾部.
文件扩展名是否也应该是国际语言字符?
原则上是,文件扩展名只是文件名的一部分,可以包含任何字符.
在Windows上的实践中我知道没有使用过非ASCII文件扩展名的应用程序.
在东亚用户的系统上要注意的最后一件事是:你会发现他们有时会输入奇怪的,非ASCII版本的拉丁字符.这些被称为全宽和半宽形式,旨在允许亚洲人输入拉丁字符,这些字符与其表意(汉语等)字符所使用的方格相对.
这在自由文本中非常好,但对于您希望解析为拉丁文本或数字的字段,接收意外的'42'整数或'.txt'文件扩展名可能会让您失望.要将这些"兼容性字符"转换为普通拉丁语,请在对它们执行任何操作之前将字符串规范化为"Unicode Normal Form NFKC".