Different behaviour of encodeURIComponent() in Firefox only

Question

I encode a filename and send it as a part of URL like /rest/get?name=Filename.txt. In JS link construction is as simple as

url = '/rest/get?name=' + window.encodeURIComponent(file.name);

It works good for simple cases but for hardcore testing I use a file named

你好abcABCæøåÆØÅäöüïëêîâéíáóúýñ½§!#¤%&()=`@£$€{[]}+´¨^~'-_,;.txt

After URI encoding I expect to get a link

/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

And I get it. The constructed link works ok in the latest versions of IE and Chrome but fails in Firefox. After some investigation I've found that in Firefox encodeURIcomponent works differently. Here's actual result in 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

Visual comparison (Chrome link is on the left and Firefox link is on the right):

I've also tried to copy and paste the valid link (constructed in Chrome) to Firefox and it works ok.

Why do I get different results?
I̶s̶ ̶i̶t̶ ̶a̶ ̶b̶u̶g̶ ̶w̶i̶t̶h̶ ̶̶e̶n̶c̶o̶d̶e̶U̶R̶I̶c̶o̶m̶p̶o̶n̶e̶n̶t̶(̶)̶̶ ̶i̶n̶ ̶F̶i̶r̶e̶f̶o̶x̶?̶
Does Firefox use a different encoding in encodeURIComponent()?

UPD. I've found similar questions (encodeURIComponent behaves differently in browsers for China as location [搜索] and encodeURIComponent difference with browsers and ä-ö-å characters [äöå]), both without an answer.

UPD.2 Further investigation has shown that the following characters are encoded differently and causing 'File not found' exception on server:

• 你好
• æøåÆØÅäöüïëêîâéíáóúýñ
• ½§¤
• £€

Punjabi

I'm going to guess that it is either that the FireFox font map is different, or that whatever FF uses for a JavaScript interpreter is out of whack. – Puzzler

%3F is ?, so looks like it's not understanding the unicode correctly. – Horatia

@JamesThorpe yes, you're right. But as you can see the other part of URL is encoded differently either and if I remove 你好 from the beginning it still fails. – Punjabi

Have you tried using the .escape() and .unescape() functions for URI encoding? jsfiddle.net/vx4e9mb7 – Besmirch

@naXa Updated fiddle: jsfiddle.net/vx4e9mb7/1 – Besmirch

escape() is deprecated as of JavaScript 1.5 (w3schools.com/jsref/jsref_escape.asp) – Romine

Answer 1

I suppose your problem is not the encodeURIComponent() method. It's the encoding of whatever constructs file.name. Extend your question. How is file.name initialized? Where do the chars come from?

Romine

A list of files with their names is received from server. – Punjabi

so, can you make sure (using JS debugger), that file.name, just before passed to encodeURIComponent(), contains proper chars (and not question marks)? – Romine

@naXa Indeed, try encodeURIComponent("你好") in the devtools console, it returns "%E4%BD%A0%E5%A5%BD", just as you expect. – Puttergill

Answer 2

encodeURIComponent() is a native function so Firefox is obviously using some different implementation under the covers.

If you are stuck, then just deliver your own javascript implementation of encodeURIComponent(), then you'll get the same results across browsers. Here's a link how to get an open source copy of that:

encodeURIComponent algorithm source code

Euchologion