Comparing text people actually typed

A user types " Ada " into a search box and nothing is found, because the stored value is "ada". You lower-case both and it works. Then a French user searches for a café and still finds nothing, even though the letters on both screens are identical.

That second one is not a bug in your code exactly — it is a fact about how text is stored. There is more than one way to write an accented letter, and two strings that LOOK the same can be different sequences of characters. This lesson is about knowing that, and about the one line of code that deals with it.

The general rule you are building towards: never compare raw user text with ===. Put both sides through the same clean-up first, and do it at the boundary where the text arrives, so the rest of your program only ever sees text in one agreed form.

`toLowerCase()` and `toUpperCase()` each return a new string in one case. They are the obvious first step for "did they type the same word", and they are the step everyone remembers.

The step people forget is trim. Whitespace at the ends is invisible on screen and fatal to ===, so a fair comparison needs both: `a.trim().toLowerCase() === b.trim().toLowerCase()`.

Lower-case rather than upper-case is the common convention, and either is fine as long as BOTH sides get the same treatment. What matters is that comparison is a decision you make once, in one function, rather than five slightly different attempts scattered through the code.

You have been told that `.length` is the number of characters. That was a simplification, and here is the honest version: it is the number of 16-bit units used to store the text. For English text those are the same number, which is why the simplification survives so long.

For characters outside that range — emoji, many scripts, some symbols — one character takes TWO units. So the grinning-face emoji, written in code as "\u{1F600}", has a .length of 2 while being unmistakably one character. Split a string in the middle of a pair and you get half a character, which displays as a meaningless box.

The practical fix is to stop using positions when the text might not be plain English. `[...text]` — the spread syntax from module 4 — steps through text by whole character rather than by storage unit, so `[...text].length` counts what a person would count, and `[...text][3]` gives you a whole character.

`codePointAt(i)` gives the full numeric value of the character starting at position i, where `charCodeAt(i)` gives only the 16-bit unit — for the emoji that is 128512 versus 55357, and the second number is not any character at all. You will rarely need either, but seeing them once explains what is going on underneath.

Unicode allows an accented letter to be written two ways: as one combined character (an e-with-acute, written in code as \u00e9), or as a plain e followed by a separate combining accent mark (\u0301). Both display identically. Neither is wrong. Which one you get depends on the keyboard, operating system and application the text came from — Apple systems have historically favoured the second, most others the first.

To JavaScript these are simply different strings — different lengths, and === says false. That is the café bug in one sentence.

`normalize()` fixes it. It rewrites text into a single agreed form, and calling it with no arguments gives you NFC, the composed form, which is the sensible default. Put both sides of a comparison through it and the two spellings become the same string.

You do not need to understand the four normalisation forms to use this. Learn the habit — `text.trim().normalize().toLowerCase()` at the boundary — and read the details the day you have a reason to.

Case conversion is not reversible, and not every language has one letter per letter. The German sharp s, written in code as \u00df, upper-cases to the two letters SS — so "Stra\u00dfe".toUpperCase() has SEVEN characters where the original had six. Lower-case SS again and you get "ss", not the letter you started with.

The consequence is concrete: comparing "Stra\u00dfe" and "STRASSE" with toLowerCase() on both sides gives false. To a German reader those are the same word. To toLowerCase they are not, and no amount of trimming or normalising changes that.

There is a proper answer — full case folding, which Unicode defines for exactly this — and JavaScript does not expose it directly. There are also language-specific rules (Turkish handles the letter i differently), which is what `toLocaleLowerCase()` is for.

The honest position for now: trim, normalize and lower-case handles the overwhelming majority of real comparisons, and you should know that it is a very good approximation rather than a law. When you are matching names or identifiers across languages for real, that is the day to reach for a library that implements case folding properly.

Write one small function — call it `normaliseForComparison` — that does trim, normalize and lower-case, and use it everywhere text is compared, stored as a key, or de-duplicated.

Two things follow. Your comparison rule lives in one place, so improving it later is one edit rather than a search. And every value in the middle of your program is already in a known form, so you stop wondering at each step whether this particular string has been cleaned yet.

Keep the original text too. The clean version is for comparing and looking up; the version the user typed is what you show back to them. Throwing away their capitalisation because you needed to compare it is a small rudeness that users notice.

Fair comparison of typed text is trim, then normalize, then lower-case — on both sides, in one shared function, at the boundary.

.length counts storage units, not characters: an emoji counts 2. Use [...text] to step through whole characters. And know that lower-casing is a very good approximation to equality, not a guarantee.