Filename equality is a diagnostic clue, not permission to rename

Two filenames can look the same on a screen while containing different Unicode code points. That is useful evidence when investigating a cross-system path problem, but it is not enough to decide which file to rename or delete.

This is an original Netzhi technical note, prepared with Codex assistance. The examples below are deliberately constructed strings, not observations from somebody else's machine.

Start with a tiny example

The first name below contains one precomposed é. The second uses an e followed by a combining acute accent. They display similarly, but Python sees different original strings:

python
import unicodedata

a = "caf\u00e9.txt"
b = "cafe\u0301.txt"

def describe(label, value):
    print(label, repr(value))
    print("code points:", len(value))
    print(" ".join(f"U+{ord(ch):04X}" for ch in value))

describe("A", a)
describe("B", b)
print("raw equality:", a == b)
print("NFC equality:", unicodedata.normalize("NFC", a)
      == unicodedata.normalize("NFC", b))

For these exact fixtures, the lengths are eight and nine code points. Raw equality is false; NFC equality is true. The code works on the two literal strings only. It does not open a directory, inspect your files, contact a server, or change a filename.

Python documents the normalization forms in its unicodedata reference. NFC is a Unicode normalization operation, not a universal rule for how every filesystem or remote service resolves a path.

Keep three questions separate

  1. What string did the client receive? Preserve the original value and its representation in a private diagnostic note. Avoid retyping it from a screenshot: that may silently remove the distinction you are investigating.
  2. What does the remote interface actually accept? A shell, a file-transfer method and a local file dialog can interpret the same text differently. Record the interface and the exact operation, rather than treating one successful lookup as proof about all the others.
  3. What object would a change affect? Before renaming anything, inspect the actual directory in an appropriate trusted tool and make a backup. String equivalence alone cannot establish that two paths name the same object.

A second pair worth checking

An ordinary space and a non-breaking space can also look deceptively similar. Try constructing "report 1.txt" and "report\u00a01.txt" with the same describe function. The space positions show U+0020 and U+00A0 respectively. Do not assume NFC will erase this difference: canonical normalization is not a general whitespace-cleanup command.

When testing a real problem, prefer a harmless synthetic filename with the same relevant character pattern. Full paths can expose usernames, server names and private project names. Keep the unredacted evidence locally; share the smallest reproducible example that preserves the issue.

Write a useful conclusion

“The two input strings differ, and this constructed pair becomes equal after NFC” is a defensible result. “The remote system is broken” is a much larger claim that the string comparison has not established.

For a wider troubleshooting sequence, Netzhi has Chinese notes on Emacs, Windows and TRAMP path problems. Use the code-point check as one small part of that investigation, alongside the connection method, shell and exact error.

Prepared by Netzhi. No private paths, account details or remote files were used in this note.