Who performs unicode normalization and when?

Question

According to JavaScript - The Definitive guide,

JavaScript assumes that the source code it is interpreting has already been normalized and makes no attempt to normalize identifiers, strings, or regular expressions itself.

The Unicode standard defines the preferred encoding for all characters and specifies a normalization procedure to convert text to a canonical form suitable for comparisons.

If JS does not normalize Unicode then who does it and when?

If JavaScript does not normalize Unicode, then how is

"café" === "caf\u00e9"   // => true

and why is

"café" === "cafe\u0301"   // => false

Since both (\u00e9 and e\u0301) are Unicode ways to form é.

Answer 1

You are confusing unicode normalization and string escaping.

"café"

…is the string made of characters with code points 0x63, 0x61, 0x66, 0xe9.

You can get the exact same string by using the escaped representation

"caf\u00e9"
// or even
"\u0063\u0061\u0066\u00e9"
// or why not
"\u0063\u0061fé"

When reading such string, javascript un-escapes the string. That is, it replaces the escape sequence by the matching characters. It is the exact same process that replaces "\n" with a new line.

Now, your second example is actually another string since it is not normalized. It is a string made of characters 0x63, 0x61, 0x66, 0x65, 0x301. As no normalization happens, it is not the same string.

Now try with the same string, using that sequence, which you cannot type with your keyboard, but that I copy-paste here for you: "café". Test it now:

> a = "café"     // this one is copy-pasted with the combining acute
> b = "café"     // this one is typed using the "é" key on my keyboard
> a === "cafe\u0301"
<- true
> b === "cafe\u0301"
<- false
> a === "caf\u00e9"
<- false
> b === "caf\u00e9"
<- true
> a === b
<- false
// Now just making sure...
> a.length
<- 5
> b.length
<- 4

The fact that "café" and "café" are rendered the same does not make them the same string. JavaScript compares the strings, finds that 0x63, 0x61, 0x66, 0xe9 is not the same as 0x63, 0x61, 0x66, 0x65, 0x301 and returns false.