kvГлавный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net.
Ещё раз повторюсь: форматы PDF и DjVu поддерживают строго предопределённый формат метаданных - т.е. фиксированный набор полей (с предопределёнными именами). И никакой иной формат метаданных (из FB2) применять для форматов PDF и DjVu недопустимо.
Если есть набор таких файлов рядом с книгами. остается натравить его на каталог с файлами - а дальше все будет сделано само.
Набор файлов рядом с книгами - это вообще некрасивое решение. Для этого существуют метаданные.
Например, у меня есть электронная читалка и я хочу рассортировать книги в одном каталоге, но чтоб видно было к какой серии (том, издание) они относились. Здесь в имени надо ставить сначала серию, потом - автора. Для другой читалки требования могут быть другими.
А это уже совсем другой вопрос - не имеющий к рассматриваемому никакого отношения. Пусть это будет головной болью конкретного юзера - а не нашей. Нужна ему некая иная схема именования - так это его проблемы - при чём здесь мы? Нас волнует только то, как упорядочить книги в больших онлайн-библиотеках - И ВСЁ.
Я-то подразумеваю, что мы тут создаём формат именования файлов для больших онлайн-библиотек (и для хранения на DVD их в скаченном виде). А пользователь у себя на компьютере потом пусть переименовывает файлы так, как ему хочется, и как ему вздумается. Естественно, универсальная система именования на все случаи жизни невозможна.
Я же взял за основу программу Name Creator
http://www.djvu-soft.narod.ru/soft/namecreator.htm - она существует уже много лет, и как известно, вполне успешно применяется.
1.основная причина этого - в разной природе данных.
Имена файлов - короткие - до 255 символов
сюда входят также путь до корневого каталога библиотеки, а это - величина переменная для каждого юзера
Ну Name Creator делает ещё более длинные имена файлов - чем мною предлагаемые - и ничего, хватает, видимо 255 символов.
2.кодировка-транслитерация. Вобчем, нет ни одного стандарта, где бы описывалась транслитерация ВСЕХ символов. Потому что сейчас транслитерация как таковая уже не очень актуальна. Так, ошметки старых технологий. Все новое и в юникоде прекрасно живет без всякой транслитерации. Т.е. здесь придется городить некий гибрид, трудоемкость создания которогону очччень большая, а смысл?
Смысл большой - ПРОСТОТА. Мне программно в тысячу раз проще работать на ASCII-коде - чем на Юникоде. И не везде Юникод-имена поддерживаются (Windows 98, например). Большинство книг в PDF и DjVu имеют названия на популярных языках - для которых предусмотрена транслитерация. Если же для каких-то символов не предусмотрена транслитерация - всё равно можно как-то выкрутиться. И Name Creator работает на ASCII-коде - и правильно делает. Я против Юникода. Это дело далёкого будущего - когда ASCII умрёт естественной смертью.
И Юникод не одинаково хорошо везде поддерживается, да и разный он (UTF8, UTF16, с BOM и без него, и т.п.). А сколько гемора бывает при переводе из Юникода во что-то иное? Нет, Юникод - ИМХО сложная и неподходящая сущность пока что, порождающая кучу проблем. Ничего, вполне перебьёмся кодами ASCII - с вполне достаточной точностью (для наших целей).
4.опыт. Работал много на почве создания база данных из имен файлов. Типа, занимался как раз той обратной задачей - извлекал метаданные. И не видел ни одной системы именования, чтобы она позволяла однозначно решить задачу. В лучшем случае будет потеря метаинформации, в худшем- обрезание и смешение разных типов.
Можно подробнее? Желательны какие-то примеры - а то голословно непонятно.
Я опираюсь на опыт работы программы Name Creator. Она давно и успешно работает - я лишь предлагаю её модернизировать.
ессно, если ИСБН есть. А на нет - и суда нет:) Тем более, что ИСБН не читаем, и будет дополнением к имени где есть нормальное название. Ну а нету ИСБН у книги - и не будет этого куска.
Да, я тоже так думаю. А если нет ISBN, но есть, скажем, УДК - то писать UDK ... (по желанию).
каталогизация - это совершенно другая задача. ПРичем уже во многих отношениях решенная - см. тот же хокм-либ. Такох прог еще с десяток найти можно. У всех у них основная проблема - где брать метаинформацию, все решают по разному, ну дык и пусть берут ее с фбд файлов. А курочить имена они до сих пор не научилсь. Так почему ты думаешь, что научатся в будущем?
Но я пока не вижу причин, почему бы нельзя было делать каталогизацию, "куроча имя файлов". Я пока не вижу притиворечия между 2 задачами "сделать говорящее имя файла" и "сделать автоматический разбор имени файла для автоматической каталогизации".
Так почему ты думаешь, что научатся в будущем?
А почему нет? Объясните, пожалуйста. Вот пример имени файла:
Avtor A. A., Vtoroj B.B., Tretij V.V.__Nazvanie_225s_RU_1995_Izdatelstvo_2izd_ISBN 0000000000_Q4.djvu
Смотрите - здесь решены сразу обе задачи.
Задача 1 (Человеко-информативное имя):
По имени файла видна (человеку - не скачивая с сайта книгу) вся основная информация о книге - кто автор, какое название, и т.п.
Задача 2 (Поддержка автоматической каталогизации):
Такое имя файла легко разбивается машинным способом на токены - Автор, Название, Год, Издание, и т.п. Это очень удобно для автоматической генерации HTML-списков имеющихся у юзера книг. Вот юзер, допустим, накачал с Интернета в произвольном порядке таких файлов, и свалил их все в одну папку. А потом запускает некий каталогизатор - и тот юзеру на полном автомате генерирует HTML-список книг - разбивая его на столбцы "Автор", "Название", и т.п. Причём попутно генерируются гиперлинки - кликнув на которые, можно будет открыть PDF или DjVu в просмотрщике.
Разве это не удобно и такой функционал будет лишним? Это же полностью автоматизирует каталогизацию накаченного из Сети (т.е. только PDF- и DjVu-книг).
Вы хотите сказать, что такая схема автоматической каталогизации будет зато негибкой (а слишком строго предопределённой) - и другим юзерам захочется как-то иначе каталогизировать - а потому, дескать, это "задача нерешаемая"?
Да, это негибкая схема каталогизации. Но a что может быть взамен? Да ничего - взамен может быть только вариант с полным отсутствием поддержки автоматической каталогизации. Но будет ли от этого лучше - если вообще отказаться от поддержки автоматической каталогизации? Думаю, нет. Пусть лучше будет хоть плохая - чем вообще никакая.
Главный резон - уже есть каталогизаторы, что понимают этот формат. Например, http://home-lib.net.
Это не довод. Ну и что, что "они уже есть"? А если там, к примеру, не то, что нам нужно? Хотя что там такое - я не знаю - попробую тот сайт почитать.
3.разделение полей в имени. Нормально это только тегами можно сделать, у тебя это токены, но они тоже занимают место, и это все - из тех же 255 символов. А если ты хочешь в имя запихнуть много полей, то у тебя получится, что от трети до половины длины имени уйдет на сами токены.
А с Name Creator всё делается сейчас ничуть не лучше. Там хоть не подчёркивания - так зато пробелы взамен (без пробелов нельзя - они для человеко-понятности нужны).
А если ты хочешь в имя запихнуть много полей, то у тебя получится,
А почему я должен этого хотеть? Мне это НЕ НАДО. Надо лишь довольно ограниченный стандартный набор токенов привести в имени - и ДОСТАТОЧНО. Ради чего ещё что-то пхать в имя файла? Не вижу смысла.