On this page
Keep raw names beside comparison keys
Store the raw path or name exactly as received, then record each derived key with the policy that produced it. A normalized key is useful for comparison, but it is not a replacement for the raw representation. Keep separators, leading markers, dot segments, percent sequences, case, and bytes visible as separate fields. If the source only exposes a decoded string, mark raw-byte evidence unavailable.
The same text can be a filesystem path, an archive member name, a URI reference, or a display label. RFC 3986 defines URI syntax and components RFC Editor, (opens in a new tab), but a URI path is not automatically a host filesystem path. Name the namespace before applying a normalization rule.
| Identity field | Record | Stop when |
|---|---|---|
| raw name | exact string or byte reference | Only a rendered label remains |
| namespace | filesystem, archive, URI, or display | Namespace is inferred |
| separator | slash, backslash, or literal character | Separators were replaced silently |
| dot segments | raw and resolved form | Resolution changes scope |
| case policy | sensitive, insensitive, or unknown | Platform default is assumed |
| derived key | policy, form, and output | Key replaces the raw name |
Choose a Unicode normalization form
Unicode permits canonically equivalent strings to have different code-point sequences. UAX #15 defines normalization forms and explains why a chosen normalized representation can make equivalent strings comparable Unicode Consortium, (opens in a new tab). Record the form, Unicode version if relevant, and whether normalization applies to the whole path or only a component. Do not normalize opaque identifiers without an owner-approved policy.
A normalization collision is not evidence that the files are identical. Two distinct raw names may produce one comparison key, while a system may preserve both or reject the collision. Keep a collision table with raw values redacted or represented by stable evidence ids.
| Policy | Question | Collision risk |
|---|---|---|
| NFC or NFD | Which canonical form is required? | Equivalent names may collapse |
| NFKC or NFKD | Are compatibility characters allowed to merge? | Meaningful distinctions may change |
| path component | Normalize each component or full path? | Separator or slash behavior differs |
| Unicode version | Which normalization tables apply? | Runtime versions differ |
| opaque identifier | Is normalization forbidden? | Key identity can change |
| collision action | reject, disambiguate, or retain both? | One key silently overwrites |
Separate URI encoding from filesystem rules
Percent encoding is a URI representation rule, not a universal filesystem decoding instruction. Dot segments such as dot and dot-dot can change a URI reference or a path resolution result, while a literal file name may intentionally contain those characters. Record whether a key is decoded, resolved, or merely compared as text. Never call a normalized string safe for extraction without a separate containment review.
Case folding and separator conversion are platform policies. A case-insensitive comparison can make two raw names collide; converting a backslash to a slash can change a literal name or an escape convention. Link to the archive member path guide when archive extraction is in scope, and preserve the raw archive member separately.
Namespace questions
- Is this value a URI reference, a local path, an archive member, or display text?
- Does percent decoding happen once, never, or under a declared rule?
- Are dot segments resolved for comparison or retained as literal characters?
- Is case folding locale-independent and versioned?
- Can a derived key collide, and what is the explicit disposition?
Use a collision fixture before matching files
The fixture below uses two visibly similar names and separate namespace examples. It is a text ledger, not a path resolver. Record the raw identifiers, the normalization form, the derived key, and the collision action. Add a percent-encoded URI example and a literal archive member to ensure the worksheet does not merge namespaces.
Do not include customer names, real directory paths, hostnames, or private archive members in a public example. A synthetic accent, separator, and dot-segment case is enough to test whether raw names survive the comparison.
| Synthetic finding | Disposition | Next evidence |
|---|---|---|
| A and B share NFC key | collision | Retain both raw ids or reject |
| Dot segment changes resolved path | policy-dependent | Record raw and resolved forms |
| Percent encoding is undecided | hold | Choose URI decoding rule |
| Case fold creates one key | collision | Apply owner disposition |
| Namespace differs | do not merge | Compare only within namespace |
Synthetic path identity ledger
raw A: cafe\u0301.txt | namespace: filesystem | key NFC: café.txt
raw B: café.txt | namespace: filesystem | key NFC: café.txt
raw C: /a/../b.txt | namespace: URI reference | resolved key: /b.txt
raw D: a%2Fb.txt | namespace: URI reference | decode: policy required
disposition: collision A/B retained; C/D not compared as filesystem namesReport matching without identity overclaim
Say “derived keys collide under NFC” or “raw values match after the declared case policy.” Do not say that normalized names prove identical files. A content hash, file size, archive context, and capture boundary answer different identity questions and should be recorded separately when needed.
Keep normalization evidence distinct from path traversal or extraction safety. A normalized path may still be outside an intended root, and a safe containment check does not establish that the file is the expected business artifact. Record unknown platform behavior explicitly.
| Finding | Disposition | Do not infer |
|---|---|---|
| Raw names match exactly in one namespace | bounded match | Files have identical bytes |
| Keys collide after normalization | hold or disambiguate | One file can overwrite the other |
| URI and filesystem forms differ | separate namespaces | Decoded URI is a local path |
| Dot segments unresolved | hold path comparison | Resolved scope is safe |
| Case policy unavailable | measurement limitation | Names are distinct |
Close with a qualified preparation step
Once raw names, namespace, Unicode form, separators, dot segments, case policy, derived keys, and collisions are recorded, keep the packet at identity evidence level. Use the data provenance log for copies and transformations and the data card for scope. Do not upload a private directory or archive merely to test normalization.
For a supported non-health collection, with authority to describe the artifact names and a controlled handling boundary, the qualified appraisal path may be a next preparation step. It does not resolve paths, compare files, create a quote, match a buyer, issue a legal opinion, or grant a license. A normalized key is not proof of ownership, permission, or identical content.
Takeaways
- Preserve raw names and derived keys as separate evidence.
- Name the namespace before applying URI, filesystem, or archive rules.
- Record Unicode form, version, case, separators, and dot-segment policy.
- Treat normalization collisions as an explicit disposition.
- Keep identity matching separate from extraction safety, rights, and content hashes.