Алгоритм преобразования имени пути в уникальный номер

Загляните в Хеш-функции. Обязательно учитывайте нечувствительность к регистру большинства имен файлов Windows при выполнении хеширования.

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

Здесь, в Stackoverflow, есть много вопросов, касающихся хэш-функций. Для начала просто найдите «хеш-функция». Это может быть полезным вопросом SO для вашего случая: Что такое эффективная функция хеширования строк, которая дает 32-битное целое число с низкой частотой конфликтов?.

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

Идеальное хеширование

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

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

Если это в Unix, вы можете просто получить его номер inode. ls -i показывает это в командной строке. Команда stat () позволяет вам получить его из программы.

Мягкие ссылки будут отображаться как один и тот же файл, а жесткие ссылки - как другой файл. Это может быть или не быть поведением, которое вы хотите.

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

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

Допустим, мы берем 32 000 путей символов в качестве лимита, упомянутого в одном из других комментариев. Если у нас есть 256 разных символов для использования с путями, мы получим:

Python 2.5.1 (r251:54863, May 18 2007, 16:56:43)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 32000L**256L
20815864389328798163850480654728171077230524494533409610638224700807216119346720596024478883464648369684843227908562015582767132496646929816279813211354641525848259018778440691546366699323167100945918841095379622423387354295096957733925002768876520583464697770622321657076833170056511209332449663781837603694136444406281042053396870977465916057756101739472373801429441421111406337458176000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L
>>>

Обратите внимание, как Python это прекрасно представляет? Да, вероятно, есть способ лучше, но это не значит, что это невозможно.

Обновлено: rjack указал, что на самом деле это 256 ^ 32000, а не наоборот. Python по-прежнему отлично справляется с этим. Производительность может оставлять желать лучшего, но говорить, что это невозможно математически, неправильно.

Как насчет чего-то вроде этого: Используйте хэш (String-> n бит) для каждого уровня каталога. Выделение 20 бит для каждого из 10 уровней каталогов явно не будет масштабироваться, но, возможно, уровень телескопирования битов, в предположении, что самый низкий уровень каталога будет наиболее заполненным -

например если у вас (от root) / A / B / C / D / E / F, вывести какое-то n-битное число, где

биты n / 2 - n хэшей F

биты n / 4 - n / 2 бит хэшей E

n / 8 - n / 4-битные хэши D

и т. д. и т. д.

Jimmy Said

there are more possible pathnames than integers, therefore you can't have true uniqueness. You could settle for something like an MD5 hash.

Я не думаю, что существует больше возможных имен путей, чем целых чисел. В качестве конструкции для создания уникального числа из имени пути мы можем преобразовать каждую букву в (двузначное) число (то есть от 10-25,26 =., Затем другие специальные символы, а 27 - это / - предполагается, что там меньше 89 различных символов, иначе мы можем перейти к трехзначной кодировке)

home/nlucaroni/documents/cv.pdf
1724221427232130121027242318271324122827123136251315

Это формирует взаимное соответствие (хотя, если вы считаете только действительные имена путей, тогда сюръективное свойство не работает, но обычно никто не заботится об этом хранении) - придумайте путь, в котором не целое число.

Это число явно не подходит для 64_bit unsigned int (max - 18446744073709551615), поэтому это непрактично, но мой ответ не об этом.

Вы можете прочитать здесь Лучший способ определить, являются ли два пути ссылки на один и тот же файл в C#, как можно однозначно идентифицировать путь. Вам нужно три числа (dwVolumeSerialNumber, nFileIndexHigh и nFileIndexLow), возможно, вы можете объединить эти три числа в новое число с в три раза большим количеством бит. См. Также здесь: Какие ваши любимые методы расширения для C#? (codeplex.com/extensionoverflow).