Finding the character you cannot see
Two strings that look identical on screen can be different bytes, and the difference is invisible: a non-breaking space instead of a space, a zero-width joiner left behind by a copy from Word, a right-to-left override, or the same accented letter written as one code point in one string and two in the other. Comparisons fail, keys do not match, and nothing in the text looks wrong.
This inspector lists every code point with its category and flags the ones that matter: invisible characters, bidirectional overrides — which can make the displayed order differ from the real order — and text that is not in NFC form. Combining marks are the quiet one: "ğ" can be a single code point or "g" plus a combining breve, and only one of those equals what is in your database.
It can also normalise to NFC or strip the invisible characters, replacing space-class ones with a plain space rather than deleting them, so word boundaries survive.
Why does my string comparison fail when the text looks the same?
- Most often NFC versus NFD. Text copied from macOS is frequently decomposed; text from Windows is usually composed. Normalise both sides before comparing, and store one form consistently.
Are bidirectional overrides dangerous?
- They can be. In source code they let the displayed order of a line differ from the order the compiler reads — the Trojan Source class of attack. Seeing them flagged in a code review is the point.