2009-08-24 5 views
0

Сайт, над которым я работаю, хочет генерировать собственные сокращенные URL-адреса, а не полагаться на третью сторону, такую ​​как tinyurl или bit.ly.Укорачивание URL: использование inode как краткое имя?

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

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

function short_name($file) { 
    $ino = @fileinode($file); 
    $s = base_convert($ino, 10, 36); 
    return $s; 
} 

Это похоже на работу. Вопрос в том, что я могу сделать, чтобы короткий URL был короче?

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

Могу ли я безопасно выбрасывать некоторые (половину?) Бит inode? И если да, то должны ли это быть высокими бит или низкими битами?

Я думал об использовании crc32 имени файла, но это на самом деле делает мои короткие имена длиннее, чем использование inode.

Возможно, что-то подобное имеет риск столкновения? Я смог перейти к отдельным цифрам, выбрав правильное значение «$ referencefile».

function short_name($file) { 
    $ino = @fileinode($file); 
    // arbitrarily selected pre-existing file, 
    // as all newer files will have higher inodes 
    $ino = $ino - @fileinode($referencefile); 
    $s = base_convert($ino, 10, 36); 
    return $s; 
} 

ответ

13

Не уверены, что это хорошая идея: если вы должны изменить сервер или изменить диск/переформатировать, иноды количество файлов, скорее всего, изменится ... И весь ваш короткий URL будет нарушен/потерял !

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


Другая идея может заключаться в том, чтобы вычислить некоторый crc/md5/любой из имени файла, как вы предполагали, и использовать некоторый алгоритм для его «сокращения».

Вот несколько статей о том, что:

+2

Хорошая точка. Одним из ключевых аспектов URI является то, что они никогда не должны меняться - http://www.w3.org/Provider/Style/URI - и это нарушает его. – ceejayoz

+1

Другой риск непреднамеренно обеспечивал бы доступ к данным, которые вы не ожидаете. Например, предположим, что пользователь запрашивает inode 17, и это случается как/etc/shadow (или они запрашивают 1111, что является ссылкой на/etc/shadow). Вам нужно будет выполнить дополнительную проверку, чтобы убедиться, что файл находится в каталоге, в котором вы его ожидаете, и это может быть не совсем тривиально ... – atk

0

Заканчивать Lessn Шон Инман; Еще не играл с ним, но это самостоятельное размещение собственного решения для URL.

2

Довольно умное использование файловой системы там. Если вам гарантировано, что идентификаторы inode уникальны, это быстрый способ генерации уникальных номеров. Интересно, будет ли это работать последовательно над NFS, потому что очевидно, что разные машины будут иметь разные номера inode. Затем вы просто упорядочиваете информацию о ссылке в создаваемом вами файле.

Чтобы немного сократить URL-адреса, вы можете учитывать чувствительность к регистру и сделать одно из безопасных кодировок (вы получите около base62 из него - 10 [0-9] + 26 (az) + 26 (AZ) или меньше, если вы удалите некоторые из «конфликтных» писем, например I, против l против 1 ... есть много примеров/библиотек).

Вы также захотите «доставить» свои идентификаторы со смещением, как вы сказали. Вам также нужно выяснить, как сохранить файл temp file/log и т. Д. От съедания вашего ключевого пространства.