← Sun, Sep 13 digest

Base84 deserves a place in file names

read article ↗ hn thread ↗

summary

Base84 provides an optimal encoding scheme for encrypted filenames that must remain compatible across Unix, macOS, and Windows systems. By excluding characters forbidden by Windows and avoiding dots, it ensures portable filesystem safety without the overhead of Base64. The encoding maximizes storage efficiency while preventing the accidental creation of reserved Windows device names. This makes it a superior choice for software-generated opaque names used in remote storage.

key points

  1. Base84 uses a specific 84-character alphabet that removes Windows-forbidden characters and dots to ensure filenames work reliably across all major operating systems. This approach avoids hidden files on Unix and shell API issues on Windows.
  2. The encoding employs a five-character packing system that achieves approximately 25.2% expansion on random input, making it more space-efficient than Base64's 33.3% expansion. This allows more binary data to fit within the standard 255-byte filename limit.
  3. The structure of the Base84 alphabet and its packing logic inherently prevents the generation of reserved Windows device names like CON or LPT1. This eliminates the need for special padding or manual checks to avoid system-reserved keywords.

who should read it

Software engineers and developers building cross-platform encryption tools or systems that store binary data as filenames.

discussion skeptical

consensus

Commenters generally agree that using a wide range of special characters in filenames is a bad practice due to the risks of shell injection and command-line errors. The prevailing sentiment is that alphanumeric characters, underscores, and perhaps dashes are the only truly safe options. Many argue that the marginal efficiency gained by using a larger alphabet (like Base84) is not worth the increased risk of escaping errors and script failure.

top insight

The debate over case sensitivity reveals a critical conflict between Unix-like systems and Windows/macOS, where case-insensitive filesystems can cause silent failures during Git clones or build processes. This highlight that filenames are not just strings but are subject to the underlying OS's normalization rules, making case-preserving but insensitive systems a 'conceptual nightmare' in the Unicode era.

Generated by an LLM from the article and thread. Check the sources before relying on it.