Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。1万件3ユニティで各アセットを管理するのにハッシュ値を適用しようと考えています。ファイル名まで含んだフルパスに対してString.GetHashCode()からハッシュ値を得ようとしております。ユニークになるとの記述はないため、このまま使用していいものかわからずにいます。https://msdn.microsoft.com/ja-jp/library/system.string.gethashcode(v=vs.80).aspx知見をお持ちの方いらっしゃいましたら教えてください。Unityなので.Net2.0まで使用可能です。Unityバージョンは5.0.1f1【追記】やりたいこととしては下記スクールストライクガールズのPDFの74ページ目にある仕組みを作ることです。下記構造体のリストでファイルパスとオフセット位置とファイルサイズを管理するというファイルシステムを構築するためにファイルパスを可逆なものにしたいと思っています。指定パスをハッシュ化して、構造体のリスト内を検索してヒットした位置のバイナリをロードするといった仕組みを構築するつもりです。個の銅バッジここにある様に、MD5等でハッシュ文字列を生成すべきです。10:48MD5の場合、1つのファイルパスにつき文字列で32バイト必要なのでできれば数値型を用いて容量を削りたいです。13:20念のため、「出力値が絶対に衝突しない(ユニークな)、汎用のハッシュ関数」という物は存在しませんよ。0:291可逆と言っておられる意味が分かりません。可逆とは元のソースを圧縮し、その圧縮物のみから元のソースが取り出せる事を言います。ハッシュは、ある情報群を取り出す際のキーに使われます。して格納するか、データベースに格納する事になるのかなと思いますが、そのキーこそが一意になるべき値なので、元の文字列と可逆になる必要はありませんね。キーはRDBMSに生成して貰えばいいのですから。様に自分でハッシュ文字列を生成する必要があるのならば、一意になるべき条件をすべて文字列化して特異な文字列をセパレータとして結合し、ハッシュ文字列を生成するのが一般的です。2:032通常、ハッシュ関数は一方向性関数の一種です。出力値Out=Hash(In)から入力値Inを復元することは不可能、つまり原理的には非可逆な変換です。異なる文字列から同じハッシュコード値を返すことが、メソッド仕様上ありえます。String.GetHashCodeメソッドのような「ハッシュ関数」は、一般に以下のような性質をもちます。同じ入力データに対しては、必ず同じハッシュコード値を返す。異なる入力データに対しては、できる限り異なるハッシュコード値を返すよう設計される。異なる入力データに対して、偶然に同じハッシュコード値を返すことはあり得る。(衝突)2つの入力データの差異が小さくても、出力されるハッシュコード値はなるべく分散するように設計される。得られたハッシュコード値から、元の入力データを復元することはできない。(一方向)またString.GetHashCodeメソッド固有の問題として、「動作環境が異なる場合、同じ入力データに対して、同じハッシュコード値を算出する保証がない」と明記されています。このメソッド(のデフォルト動作)は、プログラム動作中でのみ利用するハッシュ値専用であり、ファイルシステムのような永続化されるデータ管理に用いるべきではありません。指定パスをハッシュ化して、構造体のリスト内を検索してヒットした位置のバイナリをロードするといった仕組みを構築するつもりです。目指しているものは、ハッシュテーブル実装のように聞こえます。この場合でも、ハッシュ値の衝突は必ず考慮しなければなりません。汎用性を考慮して独自実装を進めると、オリジナルファイルシステムの劣化版が出来上がる恐れもあります。どこかで前提条件を割り切るなど、制約を設けることを検討された方が良いと思います。個の銅バッジ異なる文字列からも同じハッシュ値が作られる可能性があり、動作環境が異なる場合は保証されないとなると、この方法を用いることは危険だなので止めようと思います。|6int型であるGetHashCode()は2^32通りの値しかありません。これ以上の件数(例えば5文字の文字列の全組み合わせ)のハッシュ値をすべて計算すれば必ず衝突が発生します。コード値は存在しません。コードを返す場合があります。バイト数が少なくて一意な値を取得できる方法を詳細に調査してみます。いうプログラムなのか分かりませんが、一意性を求めるより同一ハッシュに対して複数件の値を持たせられるような構造にした方が良いと思いますよ。13:50質問に追記しました。ファイルパスが一意であればUI担当者がどこから指定ファイルをロードしたいと思っても、必ず望んだファイルが手に入ると思っているのですが、そもそもハッシュ値に対する私の理解が足りないような気がしてます。|2スクールストライクガールズのPDFの74ページ目の仕組みはアセット名からハッシュ値を作るよりもアセット名に順にIDを振っていき、アセット名を利用する部分をIDで置換していく方が的確な気がします。リソースを統合し、ID情報からランダムアクセス可能にするというのがまず最初の目的になるでしょう。"UIから指定パスのアセットをロードしたいというイベントが発生した時に、指定パスをハッシュ化する"までやってしまうなら、Dictionaryを利用してアセット名をidに変換する方がシンプルかつ見通しも良いと思います。第2段階として、変換を0にしてDictionary型を排除することができるか検討する形になると思います。アセット名のハードコーディングの削除を目指します。個の銅バッジ確かにあえてハッシュ化するより、keyとなるIDを作った方が安全ですね。無駄な変換や後々のアセットの追加や更新・削除に柔軟に対応する方法を模索してみます。|1他の方が言われているとおり、int型は、2^32通りのパターンしか表現できないので、衝突が発生します。短い文字列であっても、衝突の可能性は、あり得ます。MD5など他のハッシュアルゴリズムを使用した場合にも完全に回避できません。衝突を回避する方法として、GetHashCodeと併用して、Equalsによる判定を行います。Dictionaryの内部実装は、GetHashCodeで簡易的な判定を行ったあと、Equalsメソッドを呼び出し、オブジェクトの内容が一致するか判定を行っています。Dictionaryのような型を使用した場合、ハッシュと併用として内容の一致判定まで行うので、衝突について気にする必要は、ありません。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。