2017-01-24 16 views
1

我正在處理某些字符串被哈希的項目。爲了確保我總能得到正確的結果,我希望在對它們進行哈希處理之前將它們歸一化。 ...而且還有Unicode規範包。到現在爲止還挺好。go lang版本能夠正常化的字符串

我不想存儲規範化的表單,已經存儲了原始數據 - 我假設客戶喜歡它。我希望多年後,如果我被要求計算散列到相同的字符串我得到相同的結果。現在,如果標準提高了,或者使用最新版本的庫修復了一個錯誤,將會產生不同的結果。我不在乎以前的結果是不是完美的 - 我只是想要同一個。

我的問題是:什麼可能是強制執行一致性的好方法 - 避免我自己的執行。

回答

0

難道你不能只存儲文本的散列?這樣,您甚至不需要在需要時對它們進行標準化和計算。

如果您不能或不想:您不必使用最新版本的規範化軟件包。您可以選擇當前的最新版本(或您選擇的任何提交),並將其放入供應商文件夾中。所以你可以在幾年後使用這個「固定」版本。有關銷售詳情,請參閱Package version management in Go 1.5。試想一下:如果norm包被修改(例如一個bug被修復)併產生一個不同的輸出(標準化文本),那麼如果沒有代碼就可以得到「舊」輸出產生舊的輸出?只有擁有舊版本的norm包。

另一方面,你說你需要計算哈希來驗證數據沒有被篡改。如果是這樣,我沒有看到規範化的目的。如果原始文本被改變(例如它被「編輯」,但沒有真正改變,只是以標準化形式重新保存),那麼你可以散列文本而不進行規範化,這可以被視爲「篡改」。

+0

我確實保留了哈希值,但是我需要重新計算哈希值作爲數據未被篡改的驗證形式。我意識到供應商模式,但我仍想繼續前進,我只希望能夠爲舊數據調用舊版本。也許我要求太多。 – gsf

+0

@icze。是的,我需要最初計算正常形式的代碼。這是我的問題 - 有什麼可以成爲這樣的戰略。顯然永遠留在同一個版本將確保我對這個特定的目標有相同的結果。但這只是我需要考慮的一小部分,向前推進往往被迫從其他因素,我相信我承擔不起。 – gsf

+0

爲什麼我需要規範化是一個非常有效的點。我也在跟自己辯論。由於我工作的項目有很多方面 - 規範化到位將保證語義上相同的對象始終會產生相同的散列(至少對於相同版本的軟件)。沒有這樣的保證可能會或可能不會在系統的其他方面造成侷限性,我寧願在我忽視其他領域併發症的潛在風險之前探索我必須確保的選項1-1。 – gsf