Ищем хороший 64-битный хеш для путей к файлам в UTF16

Криптографически безопасные хэши могут быть не очень эффективными с точки зрения скорости, но существуют реализации, доступные практически для любого языка программирования.
Возможность их использования для вашего приложения зависит от того, насколько вы зависите от скорости, которую эталонный тест даст вам подходящую ответ на это.

Вы можете использовать подстроку такого хэша, например MD5 на вашем пути, ранее преобразованный в нижний регистр, так что хеш фактически нечувствителен к регистру (требуется, чтобы вы использовали метод для нижнего регистра, который знает, как преобразовать все нестандартные символы UTF-16, которые могут встречаться в файловой системе ).

Криптографически безопасные хэши имеют преимущество довольно равномерного распределения независимо от того, какую часть подстроки вы выберете, потому что они спроектированы так, чтобы быть непредсказуемыми, то есть каждая часть хэша в идеале зависит от всех хешированных данных, как и любая другая их часть.

Я бы просто использовал что-нибудь прямолинейное. Я не знаю, какой язык вы используете, поэтому это псевдокод:

ui64 res = 10000019;
for(i = 0; i < len; i += 2)
{
  ui64 merge = ucase(path[i]) * 65536 + ucase(path[i + 1]);
  res = res * 8191 + merge; // unchecked arithmetic
}
return res;

Я предполагаю, что path[i + 1] безопасно на том основании, что если len нечетно, то в последнем случае он безопасно прочитает U + 0000.

Я бы не стал использовать тот факт, что есть пробелы, вызванные пробелами в UTF-16, строчными и заглавными символами, а также символами, недопустимыми для путей, потому что они не распределены таким образом, чтобы использовать об этом факте можно было бы быстро использовать. Уменьшение на 32 (все символы ниже U + 0032 недопустимы в именах путей) было бы не слишком дорого, но и не слишком улучшило бы хеширование.

Даже если вам не нужен криптографический хеш, вы все равно можете его использовать, а поскольку ваша проблема не в безопасности, то «сломанный» криптографический хеш вполне подойдет. Я предлагаю MD4, что довольно быстро. На моем ПК (система Core2 с частотой 2,4 ГГц, использующая одно ядро) MD4 хэширует более 700 МБ / с, и даже для небольших входных данных (менее 50 байт) он может обрабатывать около 8 миллионов сообщений в секунду. Вы можете найти более быстрые некриптографические хэши, но для того, чтобы ощутить заметную разницу, уже требуется довольно специфическая ситуация.

Для конкретных свойств, которые вам нужны, вам понадобятся:

1. Для «нормализации» символов так, чтобы прописные буквы преобразовывались в строчные (для нечувствительности к регистру). Обратите внимание, что, вообще говоря, нечувствительность к регистру в мире Unicode - непростая задача. Из того, что вы объясняете, я понимаю, что вам нужна только такая же нечувствительность к регистру, которую Windows использует для доступа к файлам (я думаю, что это только ASCII, поэтому преобразование верхнего регистра-> нижнего регистра выполняется просто ).

2. Чтобы усечь вывод MD4. MD4 выдает 128 бит; просто используйте первые 64 бита. Это будет настолько разбросано, насколько вы можете пожелать.

Реализации MD4 доступны в некоторых местах, в том числе прямо в RFC 1320, ссылка на который приведена выше. Вы также можете найти реализации MD4 с открытым исходным кодом на C и Java в sphlib.

Вы можете просто создать общую библиотеку на C # и использовать класс FileInfo для получения полного пути к каталогу или файлу. Затем используйте .GetHashCode () в пути, например:

Hash = fullPath.GetHashCode();

or

int getHashCode(string uri) 
{
   if (uri == null) throw new ArgumentNullException(nameof(uri));

   FileInfo fileInfo = new FileInfo(uri);
   return fileInfo.FullName.GetHashCode();
}

Хотя это всего лишь 32-битный код, вы дублируете его или добавляете другой HashCode на основе некоторых других характеристик файла.