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