Понятно, удобочитаемые имена - полезно. Но для чего? Как по мне - то
чтоб видеть что в файле через любой файловый менеджер.
Да, именно для этого. И чтобы, не скачивая книгу, по её имени понять, что это за книга.
согласен. Ну дык и оставить только єту цель. Потому как чем проще задача - тем больше вероятность ее решения.
Кстати, придумали также спец. метафайл, содержащий только дескрипторы fb2, назвали его fbd. Предлагаю сразу и туда.
Пока не вижу смысла. Зачем "сразу и туда"? Во-первых, это в принципе не нужно, а во-вторых - всегда потом нетрудно будет сделать. Но вообще метаданные будут записываться одновременно - с формированием "говорящего" имени файла.
когда делать - другой вопрос, главное чтобы можно было. Главный резон - уже есть каталогизаторы, что понимают этот формат. Например,
http://home-lib.net. Если есть набор таких файлов рядом с книгами. остается натравить его на каталог с файлами - а дальше все будет сделано само.
А именно - зачем извлекать метаинформацию из имени, если это можно сделать из спец.полей файла или из спец.файла для метаинформации (fbd)? Туда же все уже запихнуто вместе с формированием имени. Причем, без всяких преобразований и искажений.
Смысл есть. А что, если кто-нибудь не захочет пользоваться метаданными - по не важно какой причине? Например, просто не знает, что такое метаданные - и никак не может это понять. Или же не имеет специализированный софт для работы с PDF и DjVu-метаданными. Пример: кто-то захочет на веб-сервере реализовать именование файлов (по новому стандарту). Станет ли он заморачиваться ещё и реализацией поддержки PDF и DjVu-метаданных? Наверняка нет. Ведь метаданные в PDF и DjVu имеют строго предопределёный формат (т.е. набор полей). Абы какие метаданные (FB2-метаданные) в PDF или DjVu вставлять не положено.
Так что отказываться от обратимости имени файла в метаданные (естественно, частичной) не хотелось бы.
по порядку. Если кто-то не захочет пользоваться метаданными - пусть не пользуется, никто не заставляет, но вот подменять понятия - в данном случае "метаданные" подменять именем файла не надо никогда, потому как это неправильно в принципе.
Если кто-то не знает, что такое метаданные, то пусть выучит что это, а не изобретает велосипед. Потому как потом хаоса будет больше и порядок в нем наводить гораздо труднее, нежели изначально его не плодить. Во-вторых, метаданными имеет смысл пользоваться только для создания базы. А если понимание дошло до того, что база - нужна, то и понятие "метаданные" уже не будет открытием.
Ну и одно замечание что пихать в имя файла. как по мне - что что
угодно, т.е. это должен определять юзер, главное - чтоб имя файла без
проблем поддерживалось ВСЕМИ файловыми системами. Ессно, на
современном уровне:).
Тут у меня пока нет своего чёткого мнения. А зачем юзеру пихать в имя файла что попало (всё, что ему захочется)? Тогда автоматический разбор имени файла не получится. Пусть взамен юзер пихает "что попало" в метаданные - а не в имя файла. Тогда проблем никаких. Там места много, и полей данных достаточно.
Например, у меня есть электронная читалка и я хочу рассортировать книги в одном каталоге, но чтоб видно было к какой серии (том, издание) они относились. Здесь в имени надо ставить сначала серию, потом - автора. Для другой читалки требования могут быть другими.
Но один элемент - обязательно. Это ИСБН.
А вот это как раз не обязательно - по той простой причине, что не у каждой книги он есть вообще. "Не обязательно" - но "крайне желательно", я так полагаю.
ессно, если ИСБН есть. А на нет - и суда нет:) Тем более, что ИСБН не читаем, и будет дополнением к имени где есть нормальное название. Ну а нету ИСБН у книги - и не будет этого куска.
Ну и, если дополнение к исходной задаче в виде убрать требование
обратимости имени будет принято, тогда можно продолжать.
Ну а если нет - то я пас. Потому как в этом случае я считаю что задача
нерешаемая.
Убирать не хотелось бы. А почему именно нерешаемая? Из-за того, что тогда нельзя будет помещать в имя файла произвольную информацию?
1.основная причина этого - в разной природе данных.
Имена файлов - короткие - до 255 символов
сюда входят также путь до корневого каталога библиотеки, а это - величина переменная для каждого юзера
2.кодировка-транслитерация. Вобчем, нет ни одного стандарта, где бы описывалась транслитерация ВСЕХ символов. Потому что сейчас транслитерация как таковая уже не очень актуальна. Так, ошметки старых технологий. Все новое и в юникоде прекрасно живет без всякой транслитерации. Т.е. здесь придется городить некий гибрид, трудоемкость создания которогону очччень большая, а смысл?
3.разделение полей в имени. Нормально это только тегами можно сделать, у тебя это токены, но они тоже занимают место, и это все - из тех же 255 символов. А если ты хочешь в имя запихнуть много полей, то у тебя получится, что от трети до половины длины имени уйдет на сами токены. А они ж нужны не для того, чтоб видеть, т.е. для главной задачи, а только для разбора. Т.е. причина - в смешении двух задач в кучу. И в том, что эти задачи - противоречивы.
4.опыт. Работал много на почве создания база данных из имен файлов. Типа, занимался как раз той обратной задачей - извлекал метаданные. И не видел ни одной системы именования, чтобы она позволяла однозначно решить задачу. В лучшем случае будет потеря метаинформации, в худшем- обрезание и смешение разных типов.
Но возможен и компромисс: предусмотреть в конце файла опциональный раздел с произвольной информацией (где юзер будет иметь полную свободу). Этот раздел не будет парситься автоматическим каталогизатором - при разборе книг - ну да и ладно, автоматическому парсеру вполне хватит имеющихся жёстко предопределённых полей.
каталогизация - это совершенно другая задача. ПРичем уже во многих отношениях решенная - см. тот же хокм-либ. Такох прог еще с десяток найти можно. У всех у них основная проблема - где брать метаинформацию, все решают по разному, ну дык и пусть берут ее с фбд файлов. А курочить имена они до сих пор не научилсь. Так почему ты думаешь, что научатся в будущем?
Ну а предусмотреть "опционально" - ну дык и я говорю, что имя изначально должно строиться как юзер захотел. Типа, в ИНИ файле описал шаблон - получил опциональность.
Просмотр сообщений
Давайте уж лучше ему разработаем "шаблон по умолчанию" - с которого я и начал данный топик.