アップロードされた画像名やセッションIDなどの一意の文字列生成の実装をいくつかやめたようですが、それらの多くはSHA1などのハッシュを使用しています。
私はこのようなカスタムメソッドを使用することの正当性に疑問を投げかけているのではなく、むしろその理由に疑問を投げかけています。一意の文字列が必要な場合は、次のように言います。
_>>> import uuid
>>> uuid.uuid4()
UUID('07033084-5cfd-4812-90a4-e4d24ffb6e3d')
_
そして、私はそれで終わりました。 uuidを読む前はあまり信頼していなかったので、次のようにしました。
_>>> import uuid
>>> s = set()
>>> for i in range(5000000): # That's 5 million!
>>> s.add(str(uuid.uuid4()))
...
...
>>> len(s)
5000000
_
リピーターは1人ではありません(オッズが1.108e + 50のようなものであることを考えると、今は期待していませんが、実際に動作しているのを見るのは快適です)。 2つのuuid4()
sを組み合わせて文字列を作成するだけで、オッズを半分にすることもできます。
それで、なぜ人々はランダム()や他のユニークな文字列などに時間を費やすのですか? uuidに関して重要なセキュリティ問題またはその他がありますか?
ハッシュを使用してリソースを一意に識別すると、オブジェクトから「一意の」参照を生成できます。たとえば、GitはSHAハッシュを使用して、単一のコミットの正確なチェンジセットを表す一意のハッシュを作成します。ハッシュは決定論的であるため、毎回同じファイルに対して同じハッシュを取得します。 。
世界中の2人が同じリポジトリに個別に同じ変更を加えることができ、Gitは彼らが同じ変更を行ったことを知っています。 UUID v1、v2、およびv4は、ファイルまたはファイルの内容とは関係がないため、これをサポートできません。
まあ、時々あなたは衝突が欲しいです。誰かが同じ正確な画像を2回アップロードした場合、新しい名前で別のコピーを作成するのではなく、複製であることを伝えたいと思うかもしれません。
考えられる理由の1つは、一意の文字列を人間が読める形式にすることです。 UUIDは読みにくいだけです。
uuidは長く、意味がありません(たとえば、uuidで注文すると、意味のない結果が得られます)。
また、長すぎるため、URLに入れたり、何らかの形や形式でユーザーに公開したりしたくありません。
また、他の種類のUUIDも適切である可能性があることに注意してください。たとえば、識別子を注文可能にする場合、UUID1は部分的にタイムスタンプに基づいています。それは本当にあなたのアプリケーション要件についてです...
他の答えに加えて、ハッシュは不変であるべきものに本当に適しています。名前は一意であり、いつでも付けられているものの整合性をチェックするために使用できます。