제가 작업하고있는 사이트는 tinyurl이나 bit.ly와 같은 제 3 자에 의존하기보다는 단축 URL을 생성하려고합니다.URL 단축 : 짧은 이름으로 inode 사용?
분명히 사이트에 추가 될 때 새 URL을 계속 계산하여 짧은 URL을 생성하는 데 사용할 수 있습니다. 그러나 나는 가능한 한 피하는 것을 시도하고있다. 왜냐하면이 한 가지를 작동시키는 것이 많은 일처럼 보인다.
짧은 URL이 필요한 것은 웹 서버의 모든 실제 파일입니다. 현재의 해결책은 사용 준비가 완료되어 고유성이 보장 된 inode 번호를 사용하는 것입니다.
function short_name($file) {
$ino = @fileinode($file);
$s = base_convert($ino, 10, 36);
return $s;
}
이것은 작동하는 것 같습니다. 문제는 짧은 URL을 더 짧게 만들려면 어떻게해야합니까?
이 파일이 사용되는 시스템에서 새로 추가 된 파일의 inode는 위의 함수가 7 자 길이의 문자열을 반환하도록하는 범위 내에 있습니다.
아이 노드의 비트 중 일부 (1/2)를 안전하게 버릴 수 있습니까? 그렇다면 상위 비트 또는 하위 비트 여야합니까?
파일 이름의 crc32를 사용한다고 생각했지만 실제로는 짧은 이름이 inode를 사용하는 것보다 오래 사용됩니다.
이와 같은 것이 충돌 위험이 있습니까? "$ referencefile"의 올바른 값을 선택하여 한 자리 숫자로 줄일 수있었습니다. 당신이 그것을 서버를 변경하거나 디스크를 변경/포맷해야하는 경우, 파일의 아이 노드 번호는 대부분의 아마 ... 변경됩니다 그리고 당신의 짧은 URL은 파괴 될 것이다 : 이것은 좋은 생각이다
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;
}
좋은 지적. URI의 중요한 측면 중 하나는 그들이 결코 변경되어서는 안된다는 것입니다 - http://www.w3.org/Provider/Style/URI - 이것은 위반합니다. – ceejayoz
또 다른 위험은 사용자가 허용하지 않을 데이터에 대한 실수로 액세스를 허용하는 것입니다. 예를 들어, 사용자가 inode 17을 요청하고/etc/shadow (또는 1111을 요청하면/etc/shadow에 대한 링크가됩니다)라고 가정 해 봅시다. 파일이 예상되는 디렉토리에 있는지 확인하기 위해 추가 검사를 수행해야하며 완전히 사소하지 않을 수도 있습니다 ... – atk