Base84はファイル名に場所を占めるべきだ

TurboCryptファイル暗号化ツールは、当初Unixシステム向けに設計されていました。そして、ファイル名を暗号化し、結果の暗号文をBase91でエンコードしていました。なぜBase91なのか？それは暗号化されたファイル名に最適で、UnixおよびmacOSで有効なファイルとして保存できる文字列を生成するからです。「しかし、私のファイルシステムは任意のファイル名を保存できる！」それは一部のファイルシステムでは真実かもしれませんが、ライブラリやアプリケーションを考慮に入れていません。例えば、macOSのFinderはこれを全く気に入らないでしょう。そのため、Base91は暗号化されたファイル名およびディレクトリ名にはうまく機能していました。その後、人々はWindowsサポートを求めました。Unixファイルシステムで安全なアルファベットのいくつかの文字が禁止されています。そのため、TurboCryptはBase84に切り替えています。驚くべきことに、どこにも定義されておらず、（明らかに）使用されていないにもかかわらず、ポータブルなファイルシステム安全な名前としてエンコードされるべきものすべてに最適です。なぜBase84なのか？スペースを除いた94個の印刷可能なASCII文字があります。しかし、Windowsのルールはこれらのうち9文字（< > : " / \ | ? *）を除外します。これにより85文字が残ります。しかし、ドットで終わる名前は、Windowsシェルや通常のファイルAPIでは信頼性がありません。ドットも削除すると、84文字になり、ファイル名のコンポーネントのどこにでも現れることができます。Microsoftはこれらの制限を文書化しています。しかし、Windowsは先頭のドットを許可します：.gitignoreは問題ありません。しかし、ドットをドロップすることは、Unixでの隠し名や、.および...という特別な名前も回避します。エンコード順のアルファベットは次のとおりです：ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!#$%&'()+,-;=@[]^_`{}~ 各文字は、通常のLinux、macOS、およびWindowsファイルシステムでファイル名として受け入れられます。 ビットのパッキング zig-base84はBase84の実装です。これは5文字のグループを出力します。5はスイートスポットです：84⁵ = 4,182,119,424、これは2³²にわずか2.6%不足しています。これにより、グループが約95%の確率で32ビットを保持するのに十分なスペースが残ります（一様にランダムな入力の場合）、それ以外の場合は31ビットです。エンコーダーは次の31ビットを見ます。それらの値が84⁵ - 2³¹より小さい場合、32ビット目のスペースがあります。そうでなければ、それはその31ビットのみを消費します。いずれにしても、値は5つのBase-84数字に収まります。ランダムな入力では、これは約31.95ビット/グループ、または1文字あたり6.39ビットです。出力はバイナリ入力よりも約25.2%大きくなります。ほぼBase85です。これらの拡張率は、最後の部分的なグループを無視します。平均値はランダムな入力を想定しています： エンコーディング 平均拡張率 最悪ケース拡張率 Base64 33.3% 33.3% Base84 25.2% 29.0% 0xffで満たされた入力は、すべての完全なグループが31ビットのみを消費するように強制します。それが最悪のケースです：約29%の拡張率です。ほとんどのファイルシステムは、名前を255バイトに制限します。アルファベットはASCIIなので、これは255文字です。5は255を正確に割り切るので、最大長のファイル名でさえ、部分的なグループに失われるビットなしで、完全なグループのみを保持します。Base84は、パディングされていないBase64の191バイトと比較して、197バイトの入力スペースを保証します。 Unix専用名 Unixファイル名は、Windowsが拒否するほとんどの句読点を含めることができます。NULと/はファイル名内で禁止されています。Linuxパス名ドキュメントには、ルールとファイルシステム固有の制限が記載されています。zig-base91のファイルシステムバリアントは、標準のBase91アルファベットのスラッシュをアポストロフィに置き換えます。ランダムな入力では1文字あたり約6.51ビットをパックし、約23%の拡張率になります。Unix専用名の場合は、そのバリアントを使用してください。標準のBase91にはまだ/が含まれており、両方のアルファベットにはWindowsが拒否する文字が含まれています。 予約名と大文字/小文字 Windowsは、大文字/小文字を問わず、CON、NUL、COM1などのデバイス名を予約しています。5文字のパッキングには便利な副作用があります：標準アルファベットでは、エンコーダーは短い入力であっても予約デバイス名を綴ることができません。3文字の出力は常にAからJで終わります。これにより、大文字/小文字を問わず、CON、PRN、AUX、NULが除外されます。4文字の出力は常に大文字またはa、b、cで終わります。数字で終わることはできないため、COM1からCOM9およびLPT1からLPT9も不可能です。Windowsが予約している上付き文字の数字はアルファベットに含まれていません。また、アルファベットにはドットがないため、予約名に拡張子が続くことも不可能です。これらの名前を回避するために、パディングや特別な処理は必要ありません。