解決此類問題的標準方法是為每張圖片創建 UUID（通用唯一標識符）。通常，這是一個隨機的128位標識符，您可以將其分配給每張圖片，而不必擔心通過對命名空間的蠻力攻擊來枚舉圖片。

例如。 NET，您可以將 GUID結構用於這種目的。 自Windows 2000（ source）以來， Guid.NewGuid 生成隨機（版本4）UUID。 （古代版本生成了版本1 UUID，其中顯示了生成日期，但並沒有採取任何措施來保護您免受“發票編號”問題的影響。）

我只會使用圖片哈希。有人弄清楚您使用的哈希是什麼問題？如果我認為“ URL的這一部分看起來像sha1”，請下載文件，並且它具有那個 sha1，我是對的。但這並不能使我打破您的“貓的安全性”。即使嘗試破壞散列來找出圖片是可以治療的，但嘗試這樣做而不是簡單地下載圖片也沒有意義。

僅生成圖像數據的加密安全哈希並將其用作標識符。

這有兩個副作用：

• 人們可以判斷圖像是否要求提供帶有該哈希的圖像已存在於您的服務中。
• 人們無法上傳重複的圖像。

這兩種效果本質上都不錯。他們甚至可能派上用場。但是，如果您想避免它們，則可以使用來自安全隨機數生成器的偽隨機數對每個圖像散列加鹽。

衝突不必擔心。借助SHA256之類的哈希函數，天生的隨機碰撞的可能性是如此之小，當您找到一個時，就會很感動。

標準方法是簡單地使用加密安全的偽隨機數生成器（CSPRNG）隨機生成您的URL。

不需要任何哈希等操作-只需使用普通的舊隨機數即可。它們也不必是GUID（除非出於某種原因，除非您的數據庫比簡單數字更好地處理GUID）。大概您的站點已經記住了每個URL可以訪問的圖像，因此只需對其進行修改以處理隨機URL而不是順序URL。

一個128位隨機數應該足夠長。

在處理新圖像時，請記住檢查重複的URL。

根據我在問題，評論和其他答案中所讀的內容，一切都在為每張圖片尋找唯一的標識符，這是無法猜測的，也無法提供有關圖片數量的信息，並且易於在圖片中處理。

然後，為什麼不只使用插入時間戳（自1970年以來的毫秒數）呢？如果兩個人有可能在同一毫秒內插入一張貓的圖片，則可以將其與對應於該毫秒內插入次數的序列號連接起來。

這樣一來，只有有人積極地搜索您的最後一張照片會發現有人最後一次添加照片，前提是您讓這樣的混蛋做出看起來像日常的dos攻擊。

同時，您無需擔心衝突或數據庫支持。

替代解決方案：

將元數據添加到圖像標識符。示例：

philipp_20151213_00002.jpg -用戶Philipp在2015年12月13日發布的第二張圖片。

我洩漏了該元數據，但它只是用戶可以使用的數據

這不會告訴觀察者您的服務上總共發布了多少圖像，僅與特定用戶在特定日期的活動有關。如果您也想隱藏它，則可以使用偽隨機數而不是連續數。當一個用戶一天內上傳大量圖像時，碰撞仍然可能發生，但是它們很少見，您只需生成一個新的隨機數，直到沒有被拍攝的隨機數，就可以處理它們。

這是一種方法。在服務器範圍內保留8字節的CSPRNG。然後為每個新圖像生成另一個8字節的CSPRNG。將此CSPRNG與整個服務器範圍的CSPRNG哈希在一起（md5很好）。然後，將哈希的最後8個字節與圖像ID（在數據庫中從0開始自動遞增）進行異或。客戶端將收到圖像的唯一8字節CSPRNG的Base64編碼以及8字節XOR結果。這將是公共映像ID。

當服務器接收到公共映像ID時，它將對公共ID的前8個字節以及服務器範圍內的8字節CSPRNG進行哈希處理。然後，它將獲取哈希的最後8個字節，並將其與公共ID的最後8個字節進行XOR運算。結果將是可以從數據庫中索引的專用內部ID。

更新（說明）：

首先，預先定義一個隨機全局變量CSPRNG將用於所有ID計算（8字節或64位，具有18,446,744,073,709,551,616可能的組合）。

  serverCSPRNG = CSPRNG（8） 

對於從privateID（8個字節）創建一個新的公共ID（16個字節），請執行以下操作：

  newCSPRNG = CSPRNG（8）hashEnding = last8Bytes（md5（newCSPRNG + serverCSPRNG））publicID = newCSPRNG + XOR（hashEnding，privateID） 

用於從publicID派生privateID：

  hashEnding = last8Bytes（md5（first5Bytes（publicID）+ serverCSPRNG） ）privateID = XOR（hashEnding，last8Bytes（publicID）） 

為了獲得更高的安全性，可以對publicID的最後8個字節進行XOR二級全局（僅靜態服務器）CSPRNG為了完全保護它免受暴力攻擊（因為它實施了安全模型一次性租金）。

如此處所述：哈希，UUID等具有“缺點”，即在數據庫中插入這些哈希/ uuid是PK且PK聚簇的記錄可能非常昂貴（定義昂貴...），因為它們通常不是順序的（除非使用了 NEWSEQUENTIALID 之類的特定功能，但是：請注意該頁面上的“重要”塊：“ 如果擔心隱私，請不要使用此功能。可以猜測下一個生成的GUID的值... “）。

除了這裡的建議，我還會考慮類似Twitter的（已停產）雪花之類的東西。我寫了一個類似的.Net庫（ IdGen）；它的自述文件提供了一些有關其工作原理的信息。優點是生成的ID仍（大部分）是順序的，不會佔用太多空間（64位vs.128位UUID /哈希），並且可以在（不協調的）分佈式環境中使用，在該環境中您有多個主機/進程在生成ID時不會引起衝突。而且儘管它們是順序的，但是它們並不會在一段時間內提供太多有關貓圖片數量（或更籠統地說，“已使用ID”的數量）的信息。

這聽起來像是哈希算法的工作，對嗎？

否，因為您觀察到必須擔心衝突。對我來說，這聽起來像是排列的工作，即分組密碼。這確實需要管理密鑰，這是不利的一面，但它允許您使用數據庫的自動增量功能，而不必擔心衝突。

棘手的部分是決定如何處理IV ，這裡您可以選擇。每次創建網址時，您都可以生成一個新的網址，因此，例如每張貓圖片2 ^ 128個不同的URL。您可以使IV按用戶或按會話進行，並作為用戶配置文件/會話狀態的一部分存儲在服務器端。您甚至可以將其設置為按用戶使用，但可以包含在URL中，因此您可以跟踪誰成功使圖片具有病毒性。

一種方法是使用 hashids。

Hashids是一個小型的開放源代碼庫，可從數字生成短的，唯一的，非順序的ID。

它將347之類的數字轉換為“ yr8”之類的字符串，或將[27，986]之類的數字數組轉換為“ 3kTMd”。

您還可以將這些ID解碼回去。這對於將多個參數捆綁為一個或簡單地將它們用作短UID很有用。

您的數據庫性能不受損害，因為您可以繼續在內部使用數字順序ID。同時，外部鍵是不透明的。

我對這個問題有低技術含量的解決方案。只需使用URL縮短服務，或編寫自己的URL縮短服務。

它提供以下內容：

1. 您的公共URL不會在社交媒體網站上公開。
2. 保證您的URL是隨機的和任意的。
3. 您可以自由更改資源命名的基礎實現，並且外部鏈接將繼續起作用。
4. 更容易共享 http://catpic.to/i34dhY 與 http://catpictures.com/some-guid-string 。
5. 唯一ID很容易索引/搜索。
ol>

如果您不想依賴第三方服務，則可以通過使用該語言實現雙向功能輕鬆滾動自己的服務您的選擇。

問題：

• 我們希望有一個連續的數字；否則，由於必須以隨機的順序更新索引的中間位置，因此向數據庫中添加記錄會變得昂貴。
• 我們不希望數字與已上傳的貓數相關。
li>
• 我們需要唯一的號碼，但只能在您的網站內。

因此：

• nextCat 是設置為第一個網站啟動時設置為0，則可能需要為64位。
• nextCat 已遞增 每次添加貓，並且 newCat 設置為 true 。
• nextCat 會遞增 代碼>由隨機計時器觸發，該計時器以比您預期添加貓更快的速率觸發。但是，如果 newCat 為 true ，則不會為此計時器觸發增量，並且將 newCat 設置為 false 。
• 每隻貓也都具有GUID，但永遠不需要根據其GUID來找到它。
• 貓的網址是something.com/cats/catNumber-catGuid
• 如果當請求了cat的catGuid錯誤時，則對與cat不相關的catNumber給出相同的響應。

（計時器為隨機執行一次，因此很難區分在定時器觸發之間是否添加了兩隻貓。）

一般最佳實踐：切勿在任何Web鏈接中公開PKEY。

在數據庫中-為了提高速度，您的PKEY必須是BIGINT。同樣在數據庫中，請考慮將此字段...（ public_filename ..如果不存在）添加到表中。 public_filename 字段必須是引導字符串。使用guid函數將文件上傳到服務器後，使用唯一的文件名重命名該文件，並使用該文件名填充 public_filename 。

public_filename 應該為

也用於Web鏈接，而不是PKEY。

我還建議保留一個 user_filename 字段，以支持來自上載器的所有取證搜索-如果允許的話。 user_filename 是用戶上傳的原始文件名。

切勿在任何Web鏈接中公開PKEY-始終使用某種形式的 public_filename 。使用數據庫查詢將 public_filename 取消引用到PKEY，然後從那裡可以找出要從服務器提供服務的文件。

另一種最佳做法-永遠不要覆蓋用戶文件自動上傳。用序列號（-001，-002）重命名 user_filename 字段。

很可能您會從同一用戶那裡獲得許多名為“ mycat”的文件。