Как мне отформатировать имена пользователей загруженных картинок?

Question

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

В настоящее время мое соглашение об именах файлов:

{pictureId}_{userId}_{salt}_{variant}.{fileExt}

, где salt - токен, сгенерированный на стороне сервера (не знаю, почему я решил поместить это здесь, возможно, в целях безопасности, я не знаю), а variant - это что-то вроде t, где это означает эскиз. Так это будет выглядеть примерно так:

12332_22_hb8324jk_t.jpg

Пожалуйста, сообщите, спасибо.

Answer 1

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

Однажды я работал над проектом с большим объемом изображений. Мы решили записать подпуть в нашей базе данных в дополнение к имени файла каждого файла. Наши имена папок выглядели так:

a/e/2/f/9
3/3/2/b/7

По сути, мы создали папки глубиной 5 с одним шестнадцатеричным значением в качестве имени папки. Глубина была, вероятно, чрезмерной, но эффективной. Полагаю, это могло привести к тому, что мы достигли ограничения на количество папок на томе (не уверен, что такой предел существует).

Я бы также рассмотрел возможность хранения диска в дополнение к пути (при условии, что у вас есть куча дисков для хранения). Таким образом, вы можете перемещать изображения и затем обновлять базу данных (при условии, что она у вас есть) как часть перемещения.

Answer 2

Моя стоимость 2 пенса; В этой проблеме есть некоторый конфликт между масштабируемостью и безопасностью.

1. Если у вас есть реальные проблемы с безопасностью, тогда вам вообще не следует полагаться на имя файла целевого изображения: это просто защита путем обфусцификации - кто-то может просто угадать имя в конце концов. [Даже с вашей солидной идеей, которая усложняет]

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

2. Относительно масштабируемости: я бы посоветовал вам на самом деле присваивать изображениям порядковые номера и хранить их в «корзинах», скажем, по 500 изображений в каждом. По мере заполнения корзины создайте новую. Сохраните информацию о бине (min-image-id, max-image id) в одной таблице БД, а номера изображений - в другой: вы можете сравнительно дешево найти, в каком бине находится конкретное изображение, по его идентификатору. Это довольно распространенное решение для хранения большого количества документов / изображений.

Затем вы можете сопоставить свои URL-адреса с идентификатором bin + image: но затем, чтобы избежать проблемы, отмеченной Джейсоном Уильямсом (последовательная нумерация, облегчающая поиск), вам действительно следует обратиться к безопасности отдельно, как в пункте 1.

Answer 3

Вы можете рассмотреть вопрос о замене подчеркивания (например, минусами). (Подчеркивания используются в качестве символов подстановки в SQL, так что вы можете столкнуться с проблемами в один прекрасный день при сравнении LIKE). (И, конечно, подчеркивания - это просто зло: -)

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

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

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

Answer 4

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

-Pictures
  -UserID1
    -PictureID1~^~Variant.jpg
    -PictureID2~^~Variant.jpg
  -UserID2
    -PictureID1~^~Variant.jpg
    -PictureID2~^~Variant.jpg

Картинки - просто корневой каталог для следующего.

UserID - это идентификатор пользователя базы данных.

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

~ ^ ~ - Это просто разделитель. Вы можете использовать один символ или последовательность символов X. Мне нравятся три символа, так как они легко обрабатываются с помощью функции split и легко различимы в имени файла.

Иногда мне нравится добавлять размер изображения в файл с именем .256.jpg или .1024.jpg.

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

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