Unicode Normalizer - Fix String Comparison Bugs
Normalize text with NFC, NFD, NFKC, or NFKD before comparison, storage, and search.
- Aucune limite de longueur
- Sans inscription
- Gratuit pour toujours
- Votre texte ne quitte jamais votre navigateur
The Four Normalization Forms
Unicode allows the same character to be written more than one way, and normalization is the process of choosing a single canonical form. NFC, the most common form, composes sequences into their precomposed characters; NFD does the reverse, decomposing characters into base letter plus combining marks.
The two K forms add compatibility mappings on top: NFKC and NFKD also fold presentation variants — ligatures, circled letters, and half-width forms — into their plain equivalents, which changes appearance in exchange for consistency. That makes the K forms powerful for searching and dangerous for anything where the visual distinction carries meaning.
The four forms exist because no single one fits every job: NFC preserves the text as people expect to see it, NFD makes byte-level editing of accents easier, and the K forms are for matching and indexing where presentation must not hide equality.
Why Identical Text Fails in Code
The classic bug is two strings that look identical and compare unequal. A precomposed é is one character; an e followed by a combining acute accent is two. They render the same on screen, but their byte sequences differ, so a hash, a lookup, or a database unique constraint treats them as different values.
The bug enters through the front door: one string was typed on a Mac keyboard, another was pasted from a web form, a third came from an API — each source silently chose its own representation. The data looks clean and behaves as if corrupted.
Normalization fixes it by forcing every string through the same form before comparison, storage, or search. Normalize at the boundary — when data enters the system — and the equality bugs stop at the door instead of surfacing months later in production.
Questions fréquentes
Which normalization form should I use for a database?
NFC is the common default for storing and comparing ordinary text, because it keeps text in the precomposed form most users and most systems expect while still making canonically equivalent strings compare equal. Reach for NFKC when the data includes presentation variants — ligatures, circled or full-width letters — that should match their plain equivalents in search. Avoid the K forms for storage when the visual distinction matters, since compatibility normalization deliberately discards it, and be consistent: the form chosen for storage should be the form applied at every write and every read.
Votre texte ne quitte jamais votre navigateur
Chaque outil fonctionne localement sur votre appareil. Rien de ce que vous collez n’est envoyé, stocké ou suivi.