Нужно в имени файла хранить некую бизнес информацию - строку. оказалось, что эта информация может содержать всякие хитрые символы, например "/". Это пока не точно, но надо придумывать workaround на всякий случай.

Есть идея использовать Base64.

Как я понял эта кодировка позволяет кодировать бинарные данные при помощи 64 символов:
- Большие и маленькие символы латинского алфавита
- '+' и '/'





Для урлов используется немного другой набор символов: вместо '+' и '/' используется '-' и '_'




На ntfs длина имени файла ограничена 255 символами(я так понимаю, что расширение сюда входит) и хотелось бы гарантий того, что мы не вылезем за пределы.


По поводу безопасности использования base64 для имён файлов нагуглил следующий топик

https://stackoverflow.com/a/3945743/2674303 Modified Base64 (when /,= and + are replaced) is safe to create names but does not guarantee reverse transformation due to case insensitivity of many file systems and urls.

Base64 is case sensitive, so it will not guarantee 1-to-1 mapping in cases of case insensitive file systems (all Windows files systems, ignoring POSIX subsystem cases). Most urls also case insensitive preventing 1-to-1 mapping.

Объясните мне пожалуйста про что тут идёт речь?
Я не понимаю как тот факт, что ОС не чувствительна к регистру, а Base64 чувствителен мешает в этом случае.



Второй вопрос про длину - я не понимаю как она считается.
нагуглил по этому вопросу Base64 length calculation? :

тут есть какая-то формула:

4*(n/3)

но я не понял как её применять.
автор"14A/".getBytes() = [49, 52, 65, 47]
Получается, что один символ это один байт.

14A/ - 8*4 = 32 бита.


но (Base64.getEncoder().encodeToString("1234".getBytes()) => MTIzNA==

и это получается 8 символов.

(Base64.getEncoder().encodeToString("12345".getBytes()) => MTIzNDU=

тоже 8 символов.

(Base64.getEncoder().encodeToString("123456".getBytes()) => MTIzNDU2

тоже 8 символов

(Base64.getEncoder().encodeToString("1234567".getBytes()) => MTIzNDU2Nw==

а это уже 12 символов

Объясните как это работает, плиз

Blazkowicz,


BlazkowiczКаких ещё гарантий? Откуда нам знать сколько информации вы собрались хранить.

Пока мне тоже не понятно, но надо понимать, чтобы предостеречь когда будут обсуждения применимости данного решения.
Судя по всему как считать длину я понял:

4 * ceil(n/3)

Таким образом можно сказать, что имя файла должно быть не более, чем 189 символов.

Если оставить на расширение 7 символов скажем, то остаётся 182

Blazkowicz,


BlazkowiczЗапишешь один файл. Захочешь записать другой, а ОС тебе фигушки крутит. Потому что с её точки зрения имена одинаковые, а Base64 строки - разные. Нужно ещё уникальный ID добавлять.
Ну, и некоторые инструменты могут вдруг имя привести к одному регистру. Хотя, такое редкость.


В моём случае я слушаю sftp папку.

Из неё надо достать файл, по названию определить идентификатор "продукта". Выяснилось, что идентификатор может содержать /. Поэтому есть идея кидать в папку файл с заэнкоженным именем файла, а потом при разборе уже декодить. Что тоже так себе потому, что юзер должен будет это как-то сделать.
После разбора файл через POST отправляется во внешнюю систему.


Получается это уже будет ответственность внешней системы, что файл прилетел с тем же именем.

Basil A. SidorovquestionerНужно в имени файла хранить некую бизнес информацию - строку. оказалось, что эта информация может содержать всякие хитрые символы, например "/". Это пока не точно, но надо придумывать workaround на всякий случай.

Есть идея использовать Base64.Плохая идея - далеко не все файловые системы регистрочувствительны.
NTFS, например, "case preserve, but case insensitive".
Идея хранить "странные вещи" в имени - плохая идея, но уж если очень хочется, то максимум - base36.
А какая разница ?

почему не Base32 например?

Basil A. Sidorovquestionerпропущено...
А какая разница ?Принципиальная.почему не Base32 например?Потому, что кто-то не обращает внимания на словосочетание "как максимум"?

Если будет меньше символов, то длина, очевидно, должна драматично вырасти.

В чем принципиальная разница?

BlazkowiczquestionerА какая разница? почему не Base32 например?
Чем больше символов в алфавите кодировки, тем меньше будет избыточность.
36, соответственно, оптимальнее чем 32. Но, если у вас там UTF-8 совместимый текст, то я бы не парился с кодировками а делал бы URL encoding.

Да, так наверное тоже подойдёт.

А что плохого в избыточности?

Я пока понял только то, что чем меньше символов в кодировке, тем более длинная строка нудна для кодирования при прочих равных условиях

NixicНе все сообщения внимательно прочитал, но, подумалось.
А вот зачем хранить какую-то инфу в имени файла, когда в нём можно хранить лишь уникальный сгенерированный урл/айди или что-то подобное, а затем или в бд или в другом источнике брать уже те данные, которые прикреплены к этому урлу/айди.
Потому что при хранении в Base64 всё равно всё не получается сохранить и приходится читать и перекодировать, т.е. всё равно куда-то сначала эту инфу отдавать на обработку.
Да, соглашусь, что чтение из имени и перекодировка быстрее, чем работа с бд или каким-то локальным архивом, тем не менее, как идея - отказаться от этой(автора) идеи )))

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

BlazkowiczNixic,

Можно просто файл рядом положить оригинальное имя+специальное расширение. И писать в него что угодно какой угодно длины.

Идея в том, чтобы юзер кинул файлы на сфтп и забыл про них.

Если идти путём, который Вы предлагаете, то придётся как-то гарантировать, что сначала считается оригинальный файл и только потом метаданные. Также этот путь ведет к ошибкам. Что будет если юзер забыл кинуть метаданные. Или сначала кинул метаданные а файл забыл?

maytonquestioner, мне как-то понадобилось в имена zip-архива складывать нестандартные символы (точки, двоеточия и звездочки).

Я делал их замену на $xxxx где xxxx-код символа в Unicode. И сам символ $ также был заэкранирован.
Все работает хорошо только при чтении таких архивов нужно делать обратную операцию.

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

Выглядит как почти полный аналог UrlEncoder

Nixicquestionerпропущено...


Идея в том, чтобы юзер кинул файлы на сфтп и забыл про них.

Если идти путём, который Вы предлагаете, то придётся как-то гарантировать, что сначала считается оригинальный файл и только потом метаданные. Также этот путь ведет к ошибкам. Что будет если юзер забыл кинуть метаданные. Или сначала кинул метаданные а файл забыл?
Почему это должен делать юзер? Это(файл или еще что-то) делается (генерируется) в процессе загрузки файла.
Вы можете считать сначала имя файла, затем найти по нему файл с метаданными, считать их и решить, нужно ли читать файл с данными.
п.с. Ни разу не сталкивался: а что нельзя считать имя файла без подгрузки всего содержимого файла? 99.9% что можно, надо просто погуглить :)

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

В любом случае этот путь не очень удобен пользователю потому, что он может что-то забыть