Paths
Files.com preserves the spelling of file and folder paths while comparing them using shared case and Unicode rules. Use the SDK comparison helpers when matching paths locally.
Capitalization
Files.com uses case-insensitive path matching based on its fixed Unicode comparison map.
For example, the following paths have the same comparison key:
| Path Variant | Comparison Key |
|---|---|
Documents/Reports/Q1.pdf | documents/reports/q1.pdf |
documents/reports/q1.PDF | documents/reports/q1.pdf |
DOCUMENTS/REPORTS/Q1.PDF | documents/reports/q1.pdf |
This behavior applies across:
- API requests
- Folder and file lookup operations
- Automations and workflows
See also: Case Sensitivity Documentation
The path_util.is_same function in the Files.com SDK is designed to help you determine if two paths on
your native file system would be considered the same on Files.com. This is particularly important
when handling errors related to duplicate file names and when developing tools for folder
synchronization.
Slashes
Use / between folder and file names, without leading or trailing slashes. SDK normalization helpers convert backslashes to /, remove duplicate separators, and discard exact . and .. components. Discarding .. leaves the preceding folder name intact.
| Input | Normalized path |
|---|---|
folder/subfolder/file.txt | folder/subfolder/file.txt |
/folder/subfolder/file.txt | folder/subfolder/file.txt |
folder/subfolder/file.txt/ | folder/subfolder/file.txt |
//folder//file.txt | folder/file.txt |
folder/../file.txt | folder/file.txt |
Unicode and Path Comparison
Files.com compares paths using a fixed mapping shared by the server and SDKs. It treats case and many accent differences as equivalent: Résumé.txt and resume.txt identify the same file, as do q followed by a combining acute accent and q. The mapping also handles other equivalences, such as Hiragana and Katakana. Lowercasing or applying a standard Unicode normalization form alone does not reproduce these rules.
SDK comparison helpers normalize path separators and dot segments, then apply the bundled versioned comparison map. The shared examples give exact comparison results for integrations that implement their own matching. The map uses hexadecimal Unicode scalar values as keys: a missing entry preserves the character, an empty replacement removes it, and other replacements may contain several characters. Apply each replacement once without normalizing or lowercasing the result again.
Use comparison results only for matching. Send the original path spelling in API requests and preserve it for display and local filenames; comparison results can have a different spelling or length.
Trailing whitespace is significant for comparison. report.txt and report.txt are different file paths, and SDK helpers preserve spaces, tabs, and newlines. Folder names cannot end in whitespace. See Unicode Normalization for the complete path rules.