免責事項: URL 短縮サービスの作成方法を尋ねているわけではありません ( base-62 でエンコードされた文字列を使用するHEREにある「全単射関数」の回答を既に実装しています)。代わりに、この実装を拡張して、生成された文字列を難読化し、両方になるようにしたいと考えています。
A) 簡単に推測できないシーケンス、および
B) まだ全単射。
base-62 文字セットは簡単にランダム化できますが、問題は、他の基数の他の数値と同じように増加することです。たとえば、考えられる漸進的進行の 1 つは次のようなものです。{aX9fgE, aX9fg3, aX9fgf, aX9fgR, … ,}
要件A)に関しては満足している難読化手法を思いつきましたが、それがB)を満たすかどうかは部分的にしか確信が持てません。アイデアは次のとおりです。
インクリメンタル アプローチで確実に変更されるのは、「1 の位」だけです (実用上の理由から、10 進数の用語を使用します)。前に示した進行例では、それは{E, 3, f, R, …}. したがって、base-62 セットの各文字に固有のオフセット番号 (たとえば、「ゼロ文字」からの距離) がある場合、「1 の位」文字のオフセットを残りの文字列に適用できます。
たとえば、ベース 5 の文字セット{A, f, 9, p, Z, 3}(0 から 5 までの昇順) を想定してみましょう。それぞれに、それぞれ 0 から 5 の一意のオフセットがあります。カウントは次のよう{A, f, 9, p, Z, 3, fA, ff, f9, fp, …}になります。したがって、アルゴリズムは、 の値が与えられると、 andfZ3pを見て、p+3 のオフセットを持ち、文字列を次のように並べ替えますZf9p(基数 5 のセットが循環配列であると仮定します)。次の増分番号は でfZ3Z、Zのオフセットが +4 の場合、アルゴリズムは を返します39pZ。これらの並べ替えられた結果は、実際のbase-62 でエンコードされた文字列を見ることのない「一意の URL」としてユーザーに渡されます。
このアプローチは確かに元に戻せます。最後の文字を見て、負のオフセットで同じ順列を実行します。そして、この理由から、それはまだ全単射でなければならないと考えています。しかし、これが必ずしも正しいかどうかはわかりませんか？私が考慮していないエッジ/コーナーケースはありますか?
編集:私の意図は、パターンのセキュリティよりも短縮URLの長さに重きを置いています。暗号化機能、ブロック暗号などを含む多くのソリューションがあることを認識しています。しかし、私はA)を達成するための最善の方法を尋ねているのではなく、「私のオフセットアプローチはB)を満たすか」ということを強調したいと思います。
あなたが見つけることができる任意の穴をいただければ幸いです。