Reverse a string three ways at once

Because the reversal cut characters in half. Anything above U+FFFF — every emoji, every musical symbol, most historic scripts — is stored as two UTF-16 units that are only meaningful in that order, called a surrogate pair. Reversing unit by unit puts the second half first, and each orphaned half is not a valid character at all, so the font draws the replacement mark instead. The third panel above shows this happening deliberately, and the first shows the same string reversed without it.

Use the first one, by visible character, unless you have a specific reason not to. It is the only reading that matches what a person sees, so it is right for display text, for puzzles and for anything a user will read back. The code point reading is defensible for fixed-width analysis where combining marks are known to be absent. The UTF-16 reading is almost never what anyone wants and survives only because it is the shortest to type — it is the reversal that produces the bug reports.

Not if you reverse it properly: the same characters come back in the opposite order, so all three counts above are identical before and after. A careless reversal can change the byte length, though. Split a surrogate pair and the orphaned halves cannot be encoded in UTF-8 at all; encoders substitute the replacement character, which costs three bytes each, so a four-byte emoji comes out as six bytes of nothing useful. That is the mechanism behind reversal bugs that only show up after the text is saved to a file or sent over a network.

Because splitting on an empty string cuts at every UTF-16 unit rather than at every character. JavaScript strings were designed in 1995 around a 16-bit character set that everyone expected to be enough, and the language kept that model when Unicode outgrew it — so the length property, indexing and split all count storage slots rather than characters. On plain English text a slot and a character are the same thing, which is why the one-liner passes every test written in ASCII and fails the first time somebody types an emoji.

They do under the naive reversals, and this is the failure that hides best because nothing renders as a broken box. A combining accent attaches to whatever character precedes it, so in a decomposed string the é in café is stored as e followed by the accent. Reverse the pieces and the accent now trails the f, giving f́ac and a bare e at the end. Normalising to NFC first hides the problem for the couple of hundred letters that have a precomposed form, but it cannot help Vietnamese or Thai, where stacked marks routinely have no single-code-point equivalent. Grouping by visible character does.

You get the characters in the opposite logical order, which is probably not what you saw on screen. Right-to-left text is stored in reading order and laid out backwards by the browser's bidirectional algorithm at display time, so reversing the stored order and then letting the browser reverse it again for display can leave a line looking oddly familiar while being genuinely reversed underneath. Mixed text is worse: an English phrase inside an Arabic sentence has its own direction, and reversal shuffles the boundaries between the two runs.

It compares the string with its own visible-character reversal, after normalising to NFC so that a typed é and an e with a separate accent count as the same letter. Two switches control the rest: ignoring capitals, and ignoring every character that is neither a letter nor a digit, which is what turns "A man, a plan, a canal: Panama" into a palindrome. Left strict, the same phrase is not one — punctuation and spaces are characters too, and a palindrome test that silently drops them is answering a different question from the one you asked.