0

私が取り組んでいるサイトは、tinyurl や bit.ly などのサードパーティに依存するのではなく、独自の短縮 URL を生成したいと考えています。

明らかに、新しい URL がサイトに追加されるたびに数え続け、それを使用して短い URL を生成することができます。しかし、これを機能させるだけでも大変な作業のように思えるので、可能であればそれを避けようとしています。

短い URL を必要とするものはすべて Web サーバー上の実際の物理ファイルであるため、現在の解決策は、それらの inode 番号を使用することです。これは、すぐに使用でき、一意であることが保証されているために既に生成されているためです。

function short_name($file) {
   $ino = @fileinode($file);
   $s = base_convert($ino, 10, 36);
   return $s;
}

これはうまくいくようです。質問は、短縮 URL をさらに短くするにはどうすればよいですか?

これが使用されているシステムでは、新しく追加されたファイルの inode は、上記の関数が 7 文字の長さの文字列を返す範囲内にあります。

inode のビットの一部 (半分?) を安全に破棄できますか? もしそうなら、それは上位ビットですか、それとも下位ビットですか？

ファイル名に crc32 を使用することを考えましたが、実際には短い名前が inode を使用するよりも長くなります。

このようなものに衝突のリスクはありますか? 「$referencefile」の正しい値を選択することで、1 桁まで下げることができました。

function short_name($file) {
   $ino = @fileinode($file);
   // arbitrarily selected pre-existing file,
   // as all newer files will have higher inodes
   $ino = $ino - @fileinode($referencefile);
   $s = base_convert($ino, 10, 36);
   return $s;
}
4

3 に答える 3

13

これが良い考えかどうかはわかりません。サーバーを変更したり、ディスクを変更したり、再フォーマットしたりする必要がある場合、ファイルの inode 番号はおそらく変更されます...そして、すべての短い URL が壊れたり失われたりします!

なんらかの理由で、ファイルをディスクの別のパーティションに移動する必要がある場合も同様です。


別のアイデアは、あなたが提案したように、crc/md5/ファイル名の一部を計算し、いくつかのアルゴリズムを使用してそれを「短縮」することです。

これに関するいくつかの記事を次に示します。

于 2009-08-24T17:07:22.877 に答える
2

そこでのファイルシステムのかなり賢い使用。i ノード ID が一意であることが保証されている場合は、一意の番号を生成する簡単な方法です。マシンが異なれば inode 番号も異なることは明らかなので、これが NFS 上で一貫して機能するかどうか疑問に思います。次に、そこで作成したファイルのリンク情報をシリアル化します。

URL を少し短くするには、大文字と小文字の区別を考慮して、安全なエンコーディングの 1 つを実行します (base62 については、10 [0-9] + 26 (az) + 26 (AZ)、Ivs lvsのような「競合する」文字のいくつかを削除すると、それ以下になります1...そこにはたくさんの例/ライブラリがあります)。

あなたが言ったように、オフセットを使用してIDを「ホーム」にすることもできます。また、一時ファイル/ログ ファイルなどの作成によってキースペースが消費されないようにする方法を理解する必要があります。

于 2009-08-24T17:17:40.983 に答える
0

Sean Inman のLessnをご覧ください。まだ試していませんが、これは自己ホスト型の独自の URL ロール ソリューションです。

于 2009-08-24T17:14:31.037 に答える