Check Unicode representation before changing a name

If two names look identical but an exact comparison says they differ, inspect their Unicode representation before deleting accents or retyping the values. The visible word may have more than one canonically equivalent representation.

For example, the final accented letter in Café can be U+00E9, or U+0065 followed by the combining acute accent U+0301. Those versions have four and five code points respectively. Unicode normalization provides standard forms for comparing canonically equivalent text. Unicode normalization FAQ.

Confirm this is the mismatch you have

Keep the original values in a raw column. Copy one suspicious pair into a local diagnostic example; do not upload private names to an online text checker.

This JavaScript example constructs both spellings explicitly. It counts code points with the string iterator and creates separate NFC-normalized matching copies:

const rawA = "Caf\u00E9";
const rawB = "Cafe\u0301";
const keyA = rawA.normalize("NFC");
const keyB = rawB.normalize("NFC");

console.log([...rawA].length, [...rawB].length); // 4 5
console.log(rawA === rawB);                    // false
console.log(keyA === keyB);                    // true
console.log([...rawB].length);                 // 5: original retained

JavaScript’s normalize("NFC") returns a normalized string; NFC uses canonical decomposition followed by canonical composition. It does not require overwriting the raw variable. MDN: String.normalize.

If your pair is still different after NFC, this example has not diagnosed the cause. Check the actual code points rather than assuming every similar-looking pair is canonically equivalent. For boundary spaces, use the separate whitespace-cleanup guide.

Repair a matching copy, not the source record

Create a field such as name_match_nfc and document the transformation. Retain the source value for display or audit as appropriate to the dataset. Normalize both sides of a proposed comparison with the same rule; processing one file alone can leave the mismatch unresolved.

Count changed values and review newly matching pairs before using them in a join. Do not automatically delete rows that now share a matching value. Two separate people or businesses can have the same name, including exactly the same original spelling.

Keep canonical normalization separate from other cleanup

NFC is not an instruction to remove accents, change case or discard punctuation. Do not add those transformations to identifiers unless their specification permits it. Compatibility forms such as NFKC make additional equivalences; Unicode distinguishes compatibility normalization from canonical normalization. Choose a form deliberately rather than treating every normalization option as interchangeable. Unicode normalization FAQ.

A normalized name match is evidence about the text representation, not proof of entity identity. Prefer the dataset’s documented stable identifier when joining records. If you must match on names, review the relationship and any collisions before proceeding; the CSV join guide explains why repeated keys can multiply rows.

Finish by retaining the raw field, naming the matching rule and rerunning the unmatched and duplicate-key checks. Publish only the intended public fields. A lower unmatched count is useful only when the new matches connect the right records.