Skip to main content

normalized_path/
lib.rs

1//! Opinionated cross-platform, optionally case-insensitive path normalization.
2//!
3//! This crate provides [`PathElementCS`] (case-sensitive), [`PathElementCI`]
4//! (case-insensitive), and [`PathElement`] (runtime-selected) -- types that take a
5//! raw path element name, validate it, normalize it to a canonical form, and compute
6//! an OS-compatible presentation form.
7//!
8//! # Design goals and non-goals
9//!
10//! **Goals:**
11//!
12//! - The normalization procedure is identical on every platform -- the same input
13//!   always produces the same normalized bytes regardless of the host OS.
14//! - If any supported OS considers two names equivalent (e.g. NFC vs NFD on macOS),
15//!   they must normalize to the same value.
16//! - The normalized form is always in NFC (Unicode Normalization Form C), the
17//!   most widely used and compact canonical form.
18//! - Normalization is idempotent: normalizing an already-normalized name always
19//!   produces the same name unchanged.
20//! - The OS-compatible form of a name, when normalized again, produces the same
21//!   normalized value as the original input (round-trip stability).
22//! - Every valid name is representable on every supported OS.  Characters that
23//!   would be rejected or silently altered (Windows forbidden characters, C0 controls)
24//!   are mapped to visually similar safe alternatives.
25//! - If the OS automatically transforms a name (e.g. NFC↔NFD conversion,
26//!   truncation at null bytes), normalizing the transformed name produces the
27//!   same result as normalizing the original.
28//! - In case-insensitive mode, names differing only in case normalize identically,
29//!   including edge cases from Turkish/Azerbaijani and Lithuanian casing rules
30//!   (see step 9 below).
31//!
32//! **Non-goals:**
33//!
34//! - Not every name that a particular OS accepts is considered valid.  Non-UTF-8
35//!   byte sequences, names that normalize to empty (e.g. whitespace-only), and
36//!   names that normalize to `.` or `..` (e.g. `" .. "`) are always rejected.
37//! - A name taken directly from the OS may produce a different OS-compatible form
38//!   after normalization.  For example, a file named `" hello.txt"` (leading space)
39//!   will have the space trimmed, so its OS-compatible form is `"hello.txt"`.
40//! - The OS-compatible form is not guaranteed to be accepted by the OS.  For
41//!   example, it may exceed the OS's path element length limit, or on Apple
42//!   platforms the filesystem may require names in Unicode Stream-Safe Text Format
43//!   which the OS-compatible form does not enforce.
44//! - Windows 8.3 short file names (e.g. `PROGRA~1`) are not handled.
45//! - Visually similar names are not necessarily considered equal.  For example,
46//!   a regular space (U+0020) and a non-breaking space (U+00A0) produce different
47//!   normalized forms despite looking identical, and the ligature `fi` (U+FB01) is
48//!   distinct from the two-character sequence `fi`.
49//! - Fullwidth and ASCII variants of the same character (e.g. `A` vs `A`) are
50//!   deliberately normalized to the same form.  Users who need to distinguish
51//!   them cannot use this crate.
52//! - In case-insensitive mode, Turkish İ (U+0130), dotless ı (U+0131), and
53//!   ASCII I/i are all deliberately normalized to the same form.  Users who
54//!   need to distinguish them cannot use case-insensitive mode.
55//! - Names containing unassigned Unicode code points are rejected.  This makes it
56//!   much more likely that normalization results for accepted names remain stable
57//!   when upgrading to a future Unicode version (see [Unicode version](#unicode-version)).
58//! - Path separators and multi-component paths are not handled.  This crate
59//!   operates on a single path element (one name between separators).  Support
60//!   for full paths may be added in a future version.
61//! - Android versions before 6 (API level 23) are not supported.  Earlier
62//!   versions used Java Modified UTF-8 for filesystem paths, encoding
63//!   supplementary characters as CESU-8 surrogate pairs.
64//!
65//! # Normalization pipeline
66//!
67//! Every path element name goes through the following steps during construction:
68//!
69//! 0. **Byte decoding** (only for `from_bytes`/`from_os_str`) --
70//!    [`String::from_utf8_lossy()`] is applied, replacing invalid byte sequences
71//!    with U+FFFD.  Invalid bytes can be encountered on Unix filesystems, which
72//!    allow arbitrary bytes except `/` and `\0` in names, and on Windows, where
73//!    filenames are WTF-16 and may contain unpaired surrogates.
74//!
75//! 1. **NFD decomposition** -- canonical decomposition to reorder combining marks.
76//!    This is needed because macOS stores filenames in a form close to NFD, so an
77//!    NFD input and an NFC input must produce the same result.  Decomposing first
78//!    ensures combining marks are in canonical order before subsequent steps.
79//!
80//! 2. **Whitespace trimming** -- strips leading and trailing characters with the Unicode
81//!    `White_Space` property, plus the BOM (U+FEFF) and Control Pictures that correspond
82//!    to whitespace control characters (U+2409--U+240D: HT, LF, VT, FF, CR).
83//!    Many applications strip leading/trailing whitespace silently, and macOS
84//!    automatically strips leading BOMs.  Control Pictures are
85//!    included because they are the mapped form of whitespace control characters
86//!    (see step 4), so trimming must be consistent before and after mapping.
87//!
88//! 3. **Fullwidth-to-ASCII mapping** -- maps fullwidth forms (U+FF01--U+FF5E) to their
89//!    ASCII equivalents (U+0021--U+007E).  The Windows OS-compatibility step (see below)
90//!    maps certain ASCII characters to fullwidth to avoid Windows restrictions.  This
91//!    step ensures that the OS-compatible form normalizes back to the same value.
92//!
93//! 4. **Control character mapping** -- maps C0 controls (U+0001--U+001F) and DEL (U+007F)
94//!    to their Unicode Control Picture equivalents (U+2401--U+241F, U+2421).  Control
95//!    characters are invisible, can break terminals and tools, and some OSes reject
96//!    or silently drop them.  Mapping to visible Control Pictures preserves the
97//!    information while making the name safe.  (Null bytes are excluded — see step 5.)
98//!
99//! 5. **Validation** -- rejects empty strings, `.`, `..`, names containing `/`,
100//!    names containing null bytes (`\0`), and names containing unassigned Unicode
101//!    characters.  The first group is universally special on all OSes and cannot be
102//!    used as regular names.  Unassigned characters are rejected to ensure
103//!    normalization stability across Unicode versions (see
104//!    [Unicode stability policies](#unicode-stability-policies)).
105//!
106//! 6. **NFC composition** -- canonical composition to produce the shortest equivalent
107//!    form.
108//!
109//! In **case-insensitive** mode, four additional steps are applied after the above:
110//!
111//! 7. **NFD decomposition** (again, on the NFC result).  Steps 7, 8, and 10
112//!    implement the Unicode canonical caseless matching algorithm (Definition D145):
113//!    *"A string X is a canonical caseless match for a string Y if and only if:
114//!    NFD(toCasefold(NFD(X))) = NFD(toCasefold(NFD(Y)))"*.  Step 9 extends this
115//!    with a post-case-fold fixup for Turkish/Azerbaijani and Lithuanian casing.
116//!
117//! 8. **Unicode `toCasefold()`** -- locale-independent full case folding.
118//!
119//! 9. **Post-case-fold fixup** -- maps U+0131 (ı) to ASCII i, and strips
120//!    U+0307 COMBINING DOT ABOVE after any `Soft_Dotted`
121//!    character (e.g. i, j, Cyrillic і/ј), blocked by intervening starters or
122//!    CCC=230 Above combiners (matching the Unicode `After_Soft_Dotted` condition).
123//!    This neutralizes casing inconsistencies that `toCasefold()` alone misses:
124//!    - **Dotless ı (U+0131):** `toCasefold()` treats ı as distinct from i
125//!      (ı folds to itself), yet `toUppercase(ı)` = I even without locale
126//!      tailoring, and I folds back to i -- creating a collision.
127//!    - **Lithuanian casing rules:** when lowercasing I/J/Į with additional accents above,
128//!      Lithuanian rules insert U+0307 to retain the visual dot (e.g.
129//!      `lt_lowercase("J\u{0301}")` = `j\u{0307}\u{0301}`).  Conversely,
130//!      Lithuanian upper/titlecase removes U+0307 after soft-dotted characters
131//!      (e.g. `lt_uppercase("j\u{0307}")` = `J`).  Stripping U+0307 after
132//!      soft-dotted characters ensures stability under both directions.
133//!
134//! 10. **NFC composition** (final) -- recompose after case folding to produce the
135//!     canonical NFC output.
136//!
137//! # OS compatibility mapping
138//!
139//! Each `PathElementGeneric` also computes an **OS-compatible** form suitable for
140//! use as an actual path element name on the host operating system. It is derived
141//! from the case-sensitive normalized form, by applying the following additional
142//! steps:
143//!
144//! - **Windows**: the characters and patterns listed in the Windows
145//!   [naming conventions](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions)
146//!   are handled by mapping them to visually similar fullwidth Unicode equivalents:
147//!   forbidden characters (`< > : " \ | ? *`), the final trailing dot, and the first
148//!   character of reserved device names (CON, PRN, AUX, NUL, COM0--COM9, LPT0--LPT9,
149//!   and their superscript-digit variants).
150//! - **Apple (macOS/iOS)**: converted using [`CFStringGetFileSystemRepresentation`](https://developer.apple.com/documentation/corefoundation/cfstringgetfilesystemrepresentation(_:_:_:))
151//!   as recommended by Apple's documentation (produces a representation similar to NFD).
152//! - **Other platforms**: the OS-compatible form is identical to the case-sensitive
153//!   normalized form.
154//!
155//! # Types
156//!
157//! The core type is [`PathElementGeneric<'a, S>`], parameterized by a case-sensitivity
158//! marker `S`:
159//!
160//! - [`PathElementCS`] = `PathElementGeneric<'a, CaseSensitive>` -- compile-time
161//!   case-sensitive path element.
162//! - [`PathElementCI`] = `PathElementGeneric<'a, CaseInsensitive>` -- compile-time
163//!   case-insensitive path element.
164//! - [`PathElement`] = `PathElementGeneric<'a, CaseSensitivity>` -- runtime-selected
165//!   case sensitivity via the [`CaseSensitivity`] enum.
166//!
167//! Use the typed aliases ([`PathElementCS`], [`PathElementCI`]) when the case sensitivity
168//! is known at compile time. These implement [`Hash`](core::hash::Hash), which the
169//! runtime-dynamic [`PathElement`] does not (since hashing elements with different
170//! sensitivities into the same map would violate hash/eq consistency).
171//!
172//! The zero-sized marker structs [`CaseSensitive`] and [`CaseInsensitive`] are used as
173//! type parameters, while the [`CaseSensitivity`] enum provides the same choice at runtime.
174//! All three types implement `Into<CaseSensitivity>`.
175//!
176//! # Examples
177//!
178//! ```
179//! # use normalized_path::{PathElementCS, PathElementCI};
180//! // NFD input (e + combining acute) composes to NFC (é), whitespace is trimmed
181//! let pe = PathElementCS::new("  cafe\u{0301}.txt  ")?;
182//! assert_eq!(pe.original(), "  cafe\u{0301}.txt  ");
183//! assert_eq!(pe.normalized(), "caf\u{00E9}.txt");
184//!
185//! // Case-insensitive: German ß case-folds to "ss"
186//! let pe = PathElementCI::new("Stra\u{00DF}e.txt")?;
187//! assert_eq!(pe.original(), "Stra\u{00DF}e.txt");
188//! assert_eq!(pe.normalized(), "strasse.txt");
189//! # Ok::<(), normalized_path::Error>(())
190//! ```
191//!
192//! The OS-compatible form adapts names for the host filesystem.  On Windows,
193//! forbidden characters and reserved device names are mapped to safe alternatives;
194//! on Apple, names are converted to a form close to NFD:
195//!
196//! ```
197//! # use normalized_path::PathElementCS;
198//! // A name with a Windows-forbidden character and an accented letter
199//! let pe = PathElementCS::new("caf\u{00E9} 10:30")?;
200//! assert_eq!(pe.normalized(), "caf\u{00E9} 10:30");
201//!
202//! #[cfg(target_os = "windows")]
203//! assert_eq!(pe.os_compatible(), "caf\u{00E9} 10\u{FF1A}30"); // : → fullwidth :
204//!
205//! #[cfg(target_vendor = "apple")]
206//! assert_eq!(pe.os_compatible(), "cafe\u{0301} 10:30"); // NFC → NFD
207//!
208//! #[cfg(not(any(target_os = "windows", target_vendor = "apple")))]
209//! assert_eq!(pe.os_compatible(), pe.normalized()); // unchanged
210//! # Ok::<(), normalized_path::Error>(())
211//! ```
212//!
213//! Equality is based on the normalized form, so different originals can compare equal:
214//!
215//! ```
216//! # use normalized_path::PathElementCS;
217//! // NFD (e + combining acute) and NFC (é) normalize to the same form
218//! let a = PathElementCS::new("cafe\u{0301}.txt")?;
219//! let b = PathElementCS::new("caf\u{00E9}.txt")?;
220//! assert_eq!(a, b);
221//! assert_ne!(a.original(), b.original());
222//! # Ok::<(), normalized_path::Error>(())
223//! ```
224//!
225//! The typed variants implement [`Hash`](core::hash::Hash), so they work in
226//! both hash-based and ordered collections:
227//!
228//! ```
229//! # use std::collections::{BTreeSet, HashSet};
230//! # use normalized_path::PathElementCI;
231//! // Turkish İ, dotless ı, ASCII I, and ASCII i all normalize to the same CI form
232//! let names = ["\u{0130}.txt", "\u{0131}.txt", "I.txt", "i.txt"];
233//! let set: HashSet<_> = names.iter().map(|n| PathElementCI::new(*n).unwrap()).collect();
234//! assert_eq!(set.len(), 1);
235//!
236//! let tree: BTreeSet<_> = names.iter().map(|n| PathElementCI::new(*n).unwrap()).collect();
237//! assert_eq!(tree.len(), 1);
238//! ```
239//!
240//! The runtime-dynamic [`PathElement`] works in ordered collections too, but
241//! comparing or ordering elements with **different** case sensitivities will panic:
242//!
243//! ```
244//! # use std::collections::BTreeSet;
245//! # use normalized_path::{PathElement, CaseSensitive, CaseInsensitive};
246//! // "ss", "SS", "sS", "Ss", sharp s (ß), capital sharp s (ẞ)
247//! let names = ["ss", "SS", "sS", "Ss", "\u{00DF}", "\u{1E9E}"];
248//!
249//! let cs: BTreeSet<_> = names.iter()
250//!     .map(|n| PathElement::new(*n, CaseSensitive).unwrap())
251//!     .collect();
252//! assert_eq!(cs.len(), 6); // case-sensitive: all distinct
253//!
254//! let ci: BTreeSet<_> = names.iter()
255//!     .map(|n| PathElement::new(*n, CaseInsensitive).unwrap())
256//!     .collect();
257//! assert_eq!(ci.len(), 1); // case-insensitive: all normalize to "ss"
258//! ```
259//!
260//! # Unicode version
261//!
262//! All Unicode operations (NFC, NFD, case folding, property lookups) use
263//! **Unicode 17.0.0**. Updating to a newer Unicode version is not considered a
264//! semver-breaking change as long as the normalization pipeline produces identical
265//! results for all strings consisting of characters assigned in the previous version.
266//! If a new Unicode version were to change normalization results for previously
267//! assigned characters, that update would be a semver-breaking change.
268//!
269//! This is unlikely — though not formally guaranteed — due to the following
270//! [Character Encoding Stability Policies](https://www.unicode.org/policies/stability_policy.html):
271//! - If a string contains only characters from a given version of Unicode, and it
272//!   is put into a normalized form in accordance with that version of Unicode, then
273//!   the results will be identical to the results of putting that string into a
274//!   normalized form in accordance with any subsequent version of Unicode.
275//! - Once a character is assigned, its canonical combining class will not change.
276//! - Once a character is encoded, its properties may still be changed, but not in
277//!   such a way as to change the fundamental identity of the character.
278//! - For each string S containing only assigned characters in a given Unicode
279//!   version, `toCasefold(toNFKC(S))` under that version is identical to
280//!   `toCasefold(toNFKC(S))` under any later version of Unicode.
281//!
282//! # `no_std` support
283//!
284//! This crate supports `no_std` environments. Disable the default `std` feature:
285//!
286//! ```toml
287//! [dependencies]
288//! normalized-path = { version = "...", default-features = false }
289//! ```
290//!
291//! The `std` feature enables `from_os_str` constructors and
292//! `os_str`/`into_os_str` accessors. The `alloc` crate is always required.
293
294#![cfg_attr(not(feature = "std"), no_std)]
295#![cfg_attr(docsrs, feature(doc_cfg))]
296#![warn(clippy::all, clippy::pedantic)]
297
298extern crate alloc;
299
300mod case_sensitivity;
301mod error;
302mod normalize;
303mod os;
304mod path_element;
305mod unicode;
306mod utils;
307
308pub use case_sensitivity::{CaseInsensitive, CaseSensitive, CaseSensitivity};
309pub use error::{Error, ErrorKind, Result};
310pub use path_element::{PathElement, PathElementCI, PathElementCS, PathElementGeneric};
311
312#[cfg(any(feature = "__test", test))]
313pub mod test_helpers {
314    pub use crate::error::ResultKind;
315    pub use crate::normalize::{
316        fixup_case_fold, is_whitespace_like, map_control_chars, map_fullwidth,
317        normalize_ci_from_normalized_cs, normalize_cs, trim_whitespace_like, validate_path_element,
318    };
319    pub use crate::os::{
320        apple_compatible_from_normalized_cs, apple_compatible_from_normalized_cs_fallback,
321        is_reserved_on_windows, windows_compatible_from_normalized_cs,
322    };
323    pub use crate::unicode::{case_fold, is_starter, is_whitespace, nfc, nfd};
324}