vitus_wagner (
vitus_wagner) wrote2017-01-22 11:32 am
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Entry tags:
Навел порядок в своей библиотеке.
Превратил жуткую свалку fb2 и epub-файлов, в которой мог разобраться только FBReader, да и то не сразу, в более-менее структуруированное хранилище,
вида перваябуква/автор/название
Была еще идея насоздавать симлинков для книг с более чем одним автором, но решил пока не связываться.
Большую часть работы проделал вот такой скрипт:
Скрипт, конечно наколеночный и кривой. Поддержки epub пока нет, хотя смысл там примерно
Ну и еще файл сканируется дважды. Но я решил что проще это делать дважды, чем
разгребаться с эскейпингом средствами xslt.
О, кстати придумал как обойтись без искейпинга. Вывод xmlstarlet который пишет автора на первой строчке, а title во второй, перенаправляем в
P.S. А если для фотографий аналогичный скрипт сделать? Чтобы валить их все в кучу, чуть ли не rsync-ом, а скрипт пусть потом разгребает по датам и местам.
вида перваябуква/автор/название
Была еще идея насоздавать симлинков для книг с более чем одним автором, но решил пока не связываться.
Большую часть работы проделал вот такой скрипт:
for i in *.fb2.zip; do author="`unzip -p $i "*.fb2"| xmlstarlet sel \ -t -m "//_:title-info/_:author[1]" \ -v _:last-name -o "_" -v _:first-name -n `" title="`unzip -p $i "*.fb2"| xmlstarlet sel -t \ -v "//_:title-info/_:book-title" | tr ' ' '_'`" dir=`echo "$author"|sed 's!^\(.\)!\1/\1!'` echo "$i => $dir/${title}.fb2.zip" [ -d "$dir" ] || mkdir -p "$dir" mv $i "$dir/${title}.fb2.zip" done
Скрипт, конечно наколеночный и кривой. Поддержки epub пока нет, хотя смысл там примерно
unzip -p $epub_file content.opf | xmlstarlet sel -N dc=http://purl.org/dc/elements/1.1/ \ -t -v '//dc:creator[1]' -n -v //dc:title -n.
Ну и еще файл сканируется дважды. Но я решил что проще это делать дважды, чем
разгребаться с эскейпингом средствами xslt.
О, кстати придумал как обойтись без искейпинга. Вывод xmlstarlet который пишет автора на первой строчке, а title во второй, перенаправляем в
(read author read title # do what we need with author and title ). В результате внутри xmlstarlet нужно заэскейпить только ньюлайны.
P.S. А если для фотографий аналогичный скрипт сделать? Чтобы валить их все в кучу, чуть ли не rsync-ом, а скрипт пусть потом разгребает по датам и местам.
no subject
no subject
Кстати, над идеей резать лишние эксиф-тэги тоже надо подумать. Проблема в том что у меня оригиналы фотографий публично доступны.
no subject
no subject
Питоновский скрипт, порождающий разгребалку для bash-а:
На выходе, соответственно, получается что-то вроде:
no subject
Интерес-то представляет добывание метаинформации из файлов, а вовсе не создание директорий и перемещение файлов.
Проблема с 650 авторами на букву "Б" у меня пока не стоит, поскольку я в итоге отказался от идеи работать с полным архивом флибусты, тем более на телефоне, и у меня имеется кусочек гигабайта в полтора. Но зато там книги из разных источников - и из Амазона, и из O'Reilly, и из англоязычных торрентов (что вынуждает при каталогизировании поддерживать epub).
no subject
Теоретически, можно дополнить поиском fb2 и других фоматов в архивах по дереву с извлечением метаданных и переименованием исходных файлов. Можно даже в базу всё это хозяйство втянуть для сокращения числа проходов.
Но лень :)
Я обычно книги упорядочиваю по мере поступления (давняя привычка класть сразу на правильное место), а в случае стягивания целиковых библиотек подход с "подразбиением" по нескольким первым буквам работает неплохо.
no subject
no subject
Кстати очень много сэкономить в размере скрипта и выиграть в его удобочитаемости можно было бы, если бы не реализоваывать работу с датами и копирование файлов самому, а воспользоваться готовыми модулями из стандартной библиотеки python.
no subject
В далёком 2009-м году мне было настолько лень читать документацию к готовым модулям, что проще уж реализовать всё самому.
А указывать ссылку на pypi я тогда считал неправильным и сейчас тоже так считаю. Ссылка на pypi подразумевает наличие интернета, которого может и не быть. Или модуля на pypi тоже может не быть по каким-то причинам. Может, со временем я и поменяю своё мнение по этому поводу, но покамест наличие пакетов в репозиториях, роликов на ютубе и картинок на хостингах не гарантируется. :-(
no subject
Народ для доступа средствами файловой системы к подмножествам набора файлов, выбранным по различным критериям метаданных, пилит штуку под названием tagsistant. На мой вкус вещь странная, и я не придумал, где мне было бы удобно её использовать, но оцениваю шанс что вам понравится в 30%
Как минимум можно будет видеть одну и ту же книгу в директориях .../store/Автор1 и .../store/Автор2 можно будет без ручного создания симлинков, если прикрутить к tagsistant извлечение из fb2 файлов метаданных (AFAIK, пока поддерживает только аудиофайлы и изображения)
no subject
Почему вы считаете что "ручное" создание симлинков, в смысле с помощью наколенного скрипта, который делает то что нужно, и не делает более ничего, хуже, чем использование какой-то левой хрени?
На мой взгляд, для создания конструкции симлинков любой сложности шелла и coreutils вполне достаточно.
Я всем рекомендую уже с 2001 года - выучите, что могут те средства, которые стоят у вас в системе, и выяснится, что в 90% случаев решить задачу с помощью этих средств будет проще, чем искать и ставить что-то новое.
Собственно данный пост был как раз про то, как использовать xmlstarlet для того, чтобы извлекать метаинформацию из электронных книг. Для того, чтобы потом это стандартными средствами обрабатывать.
no subject
Средствами tagsistant это делалось бы примерно так:
ls "$TAGSISTANT_ROOT/Автор1/-/Автор2/@/"
tagsistant даёт куда больше гибкости. Цена за эту гибкость - установка и изучение странной херни. Мне эта цена показалась существенно выше выгоды, я не использую. После вашего ответа я почти уверился, что вам тоже не захочется.
Но некоторое восхищение людьми, которые пытаются упихнуть неупихуемое в стандартные интерфейсы всё же у меня есть.
no subject
Иерархия каталогов в хранилище не является способом ответить на все возможные запросы. Она является способом быстро получить доступ к объекту по ключу + способом ответить на наиболее
частые запросы
А так нам ничто не мешает рядом с архивом текстов накрутить какие угодно базы данных, которые в качестве ответа на запрос будут выдавать список файлов в архиве. Хоть полнотесктовым поиском, хоть с ассоциативным на естественном языке хоть с дополнительной индексацией текста.
Например, я полагаю что сильно не помешал бы поиск по персонажам "В каких книгах упоминается Уильям Дампир", а также по географическим локациям и временным периодам "хочу все, что имеется про Индию XVIII-начала XIX веков". Причем там будет хитрая работа с темпоральной алгеброй. А возможно, что и с битемопральной. Потому что интересно знать не только "период, который описывается", но и "период, когда написано" - от этого очень много зависит в плане достоверности и предвзятости автора.
no subject
no subject
no subject
Натолкнулись в своё время, когда пробовали каталог для семейной библиотеки написать. Особо это с переводными книгами заметно (того же Желязны как не переводили).
Вот как бы такое автоматизировать...
no subject
no subject
Речь идёт же о персональном хламовнике надо домашнем сервер. Какой тут краудсорс?
no subject
"Если ты это у себя поправил, зааплоадь исправленное туда, откуда взял".
В тех случаях когда существуют однозначные критерии "ошибки" и "исправления" это даже сработает.
no subject
Для той же флибусты это не вариант, IMHO.
no subject
Угу. Можно. Но смысл? Только умножение сущностей. Одно дело, когда это в на флибусте. И другое, когда в личной библиотеке, где скрипт прошёлся и наплодил авторов из одного, потому что разное количество пробелов между именем и фамилией, или символ не из той раскладки затесался.
Вот как раз думаю над тем, как сделать автоматическое сведение и исправление. По сути -- поиск похожего в авторах/названиях. Или вводить поле "оригинальное имя автора на его родном языке" и сортировать по нему.
no subject
С оригинальным именем автора на его родном языке тоже могут быть сложности. Поскольку во многих культурах понятие имени может существенно отличаться. И вообще Игорь Можейко и Кир Булычев это четыре автора или два?
no subject
Иначе - действительно базу данных делать, чтоб выяснить, что "это не муж и жена, а три разных человека". Потому что ещё и однофамильцы и полные тёзки встречаются.
no subject