我对文件名进行编码,并将其作为/rest/get?name=Filename.txt这样的URL的一部分发送。在JS中,链接的构造非常简单
url = '/rest/get?name=' + window.encodeURIComponent(file.name);它适用于简单的情况,但是对于硬核测试,我使用了一个名为
你好abcABCæøåÆØÅäöüïëêîâéíáóúýñ½§!#¤%&()=`@£$€{[]}+´¨^~'-_,;.txt在URI编码之后,我希望得到一个链接
/rest/get?name=%E4%BD%A0%E5%A5%BDabcABC%C3%A6%C3%B8%C3%A5%C3%86%C3%98%C3%85%C3%A4%C3%B6%C3%BC%C3%AF%C3%AB%C3%AA%C3%AE%C3%A2%C3%A9%C3%AD%C3%A1%C3%B3%C3%BA%C3%BD%C3%B1%C2%BD%C2%A7%3F%3FabcABC%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD!%23%C2%A4%25%26()%3D%60%40%C2%A3%24%E2%82%AC%7B%5B%5D%7D%2B%C2%B4%C2%A8%5E~%27-_%2C%3B.txt我明白了。构建的链接在IE和Chrome的最新版本中运行良好,但在Firefox中失败。经过一些调查,我发现在火狐中,encodeURIcomponent的工作方式不同。以下是Firefox的实际结果:
/rest/get?name=%3F%3FabcABC%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD!%23%EF%BF%BD%25%26%28%29%3D%60%40%EF%BF%BD%24%3F{[]}%2B%EF%BF%BD%EF%BF%BD^~%27-_%2C%3B.txt视觉比较(左侧是Chrome链接,右边是Firefox链接):

我还试着复制并粘贴有效链接(用Chrome构建)到Firefox,它工作正常。
为什么我会得到不同的结果?
I̶s̶i i̶t̶̶a̶̶b̶u̶g̶̶w̶i̶t̶h̶̶̶h̶̶i̶n̶̶F̶r̶e̶r s o̶x
火狐是否在encodeURIComponent()中使用不同的编码?
UPD. --我发现了类似的问题(encodeURIComponent behaves differently in browsers for China as location搜索和encodeURIComponent difference with browsers and ä-ö-å characters ),两者都没有答案。
UPD.2进一步研究表明,以下字符的编码方式不同,并在服务器上导致“文件未找到”异常:
发布于 2016-02-10 05:03:49
我想您的问题不是encodeURIComponent()方法。它是任何构造file.name的编码。扩展你的问题。如何初始化file.name?这些炭是从哪里来的?
发布于 2016-02-12 19:22:52
encodeURIComponent()是一个本机函数,因此火狐显然使用了一些不同的实现。
如果您陷入困境,那么只需交付您自己的encodeURIComponent()的javascript实现,那么您将在不同的浏览器上获得相同的结果。下面是一个如何获得开源副本的链接:
https://stackoverflow.com/questions/35202567
复制相似问题