【Calibre】電子書籍 保存・管理・変換・編集ソフト part1
■ このスレッドは過去ログ倉庫に格納されています
https://calibre-ebook.com/
Wikipedia https://ja.wikipedia.org/wiki/Calibre
Calibreとはフリー・アンド・オープンソースの電子書籍ソフトウェアであり、
電子書籍を保存や管理を行うことが可能で、多数のフォーマットに対応している。
またDRMのかかった電子書籍を他のフォーマットへ変換でき、
数種類の主な電子ブックリーダーと同期することができる。
使い方説明サイト
http://gihyo.jp/lifestyle/serial/01/calibre
Calibreについて語りましょう >>665
そういうわけなのでLinuxでやってる
bashとawkとpythonとphpがごちゃまぜで、とても他人に見せられるようなものではないが >>665
windowsだと相性悪いよね
今のwin10ならWSL使うべきだろうけど昔作ったので自分はcygwin使ってる プログラム書ける人材が複数いそうなのに全く改善が進まない不思議 >>662
デフォルト設定がepub2なんだよなあ
おかげで全部変換し直し >>670
ある程度自分でなんとかできる人間ならコードはほぼオープンなので
俺環上等で組み上げることは可能なんだけど
前出の通り文字コードの問題があるのと元がpythonでexe化しにくいのとで
そのあたりの素地のない人でも簡単に使えるような汎用物に仕上げるのが難しい スクリプト配布して終わりにならないのがね
最低限pythonの実行環境を自分で構築できる人で無いと動かないと文句言われそう
そしてその手の方が圧倒的に多い 同じようなことを考えてるか、過去に考えた人がそこそこいるってことだろう
うちはLinuxでwineも絡むのでさらに面倒くさい >>674
話を理解してくれそうな人がいるからね
草生やすだけには言うだけ無駄だから そういうことだな
「配布してくれ」以外の反応があると話しやすい 4人くらいいそうだな
複数人がスレ見てるってのが証明されたし今後は遠慮せず改良を進めてくれ まずは>>663が考えたスクリプトを公開してその改良から始めようぜ >>670
自分が使えればいいだけってなら他人の意見はいらないし、サポートの手間とかソースの流用やDRMの事でもめたりしそうで公開するメリットなくてデメリットばかりだからじゃね
フォーラムとかで自分が雛型作ってソース見てもらい要望やアドバイスもらって完成したようなもんだと公開しないと不義理だと思うが、雛型時点で作者が満足してたら公開なんぞせんのでは? >>663だが公開する気はない
これから作る人に助言というか、「自分はこうやった」って伝えるくらいはやるかな 以上、自分は満足してるのでCalibreのバージョンアップに協力する気はないという皆さんでしたー 以上、自分は満足してるのでCalibreのバージョンアップに協力する気はないという皆さんでしたー もらえないからとひがみ根性は見苦しいねぇ
>>395のplugin上げたのはオレだよ
他の人もできる範囲でアドバイスとかしてる思う Calibreのバージョンアップに協力?
なんのこっちゃ いや、なぜこの文脈で「Calibreのバージョンアップ」なのか本気でわからんな
日本語不自由な人だったか >>690
日本語ファイル名のまま追加したいということ?
出来ればいいんだけどな >>689
コードどころかレスの内容の意味も分からん状態の人だと
calibre外でゴショゴショやってるってこと自体気づかないんだろう
こういう所からも求められてるものと自分専用スクリプトの隔たりを感じるよね
まあでも中途まで書いて放置してる身としてはきちんと仕上げられた人達は
qiitaあたりで解説記事書いてくれると嬉しい
エンドユーザー向けじゃなくて全然いいので 会話の内容が訳分からん奴はCalibreのプラグインでしこしこ変換してろって事よな
俺のように >>693
そういうことです。
誰かプラグイン作って デカイこと言われてもそれに対応するほどの実力がないってこと >>696
ライブラリのファイル名はcalibre本体の管理がそうなってる以上
プラグインではどうにもならんよ
エクスポート時に日本語ファイル名で出力する事はできるが ここの連中の対応でepub3の今後が決まるとか酷すぎだろ 「元ファイル(azw,epub)が登録してあるフォルダに
日本語ファイル名に変換し直したファイルのコピーを作る」
なら出来るかもしれない
俺は出来ないが。 固定レイアウトのazw→zipの変換でhtmlとか要らないんだけどなぁ
ビュアーで読むから連番のjpegを抜いてzipに固めてくれるだけでいいのに…
プラグインとかでもそういうの見つからないし需要ないのかな >>701
同意
コミックは画像だけのzipの方がいい CLIのみでDRM解除するには、DeDRMプラグインの中の
DeDRM_Windows_Application/DeDRM_App/DeDRM_lib/lib
にあるscriptinterface.pyがキモ
この中にあるメソッド
def decryptk4mobi(infile, outdir, rscpath):
を呼び出せばDRM解除できる
infile: 入力ファイル
outdir: 出力ディレクトリ
rscpath: 鍵ファイル(*.k4i)が格納されたディレクトリ
鍵ファイルがあればどのマシンでも解除可能
Linuxの場合はpython, python-crypto, python-lzmaが必要
lzmaは実際には使われないのでlib/ion.py内でimportしてるとこを
コメントアウトすれば不要になる
という話が通じる人は参考にしてください 余計な情報のないフラットなzipにするには
KindleUnpackなり、calibreで変換(ebook-convert)した後でunzipして加工してzipに戻せばいい
Unpackの場合なぜか画像ファイル名の連番が1から始まらないのでそこを揃えたいときはちょっと面倒 >>704
結局、ひとつずつepubを解凍していって
取り出したjpgをzip化することになるのかな? >>705
解凍せずにzip操作もできたとは思うが
ファイル追加削除はともかくリネームや階層移動はできたかどうか
そこに悩むくらいなら解凍した方が早い
シェルにすれば大した手間でもないし zip内jpg以外削除はUnifyZipでやってる
フォルダごと投げりゃいいから楽よ
コマンドライン用exeだからcalibreやlinux cli上のpythonとの連携はできないのがネックだが >>701
バッチファイル2,3行書けばjpgだけ取り出せるゾ
低知能ド文系の僕でもそうしてるゾ >>695
自分が使ってるソフトの不満点や要望はそのソフトの作者に言うのが筋だし、それが相手にされなかったら自分でなんとかするって世界だからなぁ
作者へコンタクトとるのすらめんどくさいから誰かやってくれってのは頼まれた相手もいい気はしないわな >>663
・DeDRMプラグインのpythonライブラリをちょっと弄ってCLIでDRM解除
教えて欲しいのですが、どこをいじりましたか?
WSL+debian+python2.7でtopazextract.pyがTopaz_Cipherのインポートでエラー
ざっと見てコメントアウトして動かしてます
こうした方が良い、ここも必要というアドバイスがあったらぜひお願いします >>713
>>703
WSLは詳しくないのでpython-cryptが入るのか、ディレクトリ指定をどうするのか等はわかりかねます 念のため、>>663は「Calibreでやれないことをできるようにするもの」じゃないよ
Calibre CLI + DeDRMプラグインでやれてたことをCalibreなしでもやれるようにしただけ >>714
ありがとう
こちらはk4mobidedrm.pyをダイレクトに呼び出してるので状況が違うようですね
もう少し読んでみます >>716
うちは
DeDRM_Windows_Application/DeDRM_App/DeDRM_lib
に以下の内容のdedrm.pyを作り、
python dedrm.py "入力.azw" "出力ディレクトリ" "鍵ファイルのあるディレクトリ"
で解除できている。
エラー判定もしない雑な作りで、コピペなのでインデントとか乱れたらごめん
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys
import os, os.path
sys.path.append(os.path.join(sys.path[0],"lib"))
import sys, os
import codecs
from argv_utils import add_cp65001_codec, set_utf8_default_encoding, unicode_argv
add_cp65001_codec()
set_utf8_default_encoding()
from scriptinterface import decryptepub, decryptpdb, decryptpdf, decryptk4mobi
def main(argv=unicode_argv()):
decryptk4mobi(argv[1], argv[2], argv[3])
return 0
if __name__ == '__main__':
sys.exit(main()) >>710
連番jpeg抜くだけならバッチファイル書く必要すらないような calibreで選択した本(複数選択可)からjpgだけ抜き出して
zip化するプラグインがあれば理想だろうね
こういうプラグインって何故かありそうで無いね >>719
シェルスクリプトで作ったよ
それほど難しいものでもない >>698
本の情報は日本語でもあるみたいだしそっから撮ってきてファイル名にすることできないの? >>721
Calibreの外でならどうにでもなるけど
Calibre自身に日本語ファイル名で管理させるのは無理って話では
シンボリックリンク張るとか無理しないとどうやってもファイルが複数になる 世界には、koboちゃんみたいに日本語ファイル名でクラッシュするlinuxベース環境で動いてるcalibreもあるのかもしれんよ 知らなかった
koboって日本語ファイル名でクラッシュするんだ
自分はepubにして全部kinoppyに入れてる >>721
情報取得からのリネームはできるだろうけど
calibre libraryフォルダ内を勝手にリネームしてしまったら
calibre本体がそのファイルを管理できなくなるからアウト
単純に日本語ファイル名で吐き出すだけなら設定変えるだけでcalibre本体で可能だよ
特別なプラグインいらない 本のタイトルに含まれる「(〇〇コミックス)」等を取り除いたり、
数値を半角に揃えたりする処理(正規化と呼んでいる)を自動化してるので貼ってみる。
ついでにシリーズと巻数を自動で取得できるようにしてある。
うちではこの巻数と発行日を利用してシリーズ毎の新刊予想レポートを出してる。
https://pastebin.com/WRyhjs4j
使い方: ./getTitle.sh "変換前タイトル"
・bashとawkが必要、awkはmawkでなくgawkが要るかもしれないが忘れた
・標準エラー出力に正規化中の経過ログを出力する。不要なら 2>/dev/null とかで捨てればいい
・標準出力にカンマ区切りで下記3項目を出力する
[1] 正規化済タイトル
[2] シリーズ名
[3] 巻数 ※巻数を含まない場合は0
使用例(たまたまKindleストアのトップに載ってたもの)
./getTitle.sh "1日外出録ハンチョウ(7) (ヤングマガジンコミックス)"
↓(出力)
1日外出録ハンチョウ 7,1日外出録ハンチョウ,7
注意事項
・半角カンマはピリオドに返還されるなど、正規化ロジックは俺環用なので必要に応じて修正すべし
・「ゴルゴ13」のように区切りがない部分に含まれる数値は巻数と見做さないので誤判定もある
・当たり前だが自己責任で epub2は本文中で使っているタグだけがcssに記載されているのに対して、
epub3は、装飾に使えそうなタグが事前に全てcssに記載してある
書籍ごとに別のものを用意する必要はなく、全ての電子書籍に同じcssを使えばいい
「電書協 EPUB 3 制作ガイド」
http://ebpaj.jp/counsel/guide
ここに日本での電子書籍作成の標準テンプレートがある
book-template.epub が小説用
fixedlayout-template.epub がマンガ用
自作epubの取り込むことが可能な電子書籍販売会社のアプリは、たぶんこの標準テンプレートで作られたepubがエラーなく表示できるように作成してる
海外のepubビューア開発者もepub3完全対応の参考にするといいと思う
英語のDLファイルも用意してあるが、中に入っているcssはタグの用途が日本語で説明されているので、翻訳が必要 マンガはzipのほうがいいと思うので置いておくとして小説について
表示エラーをなくすためには、DRM解除したepubを「電書協 EPUB 3 制作ガイド」の標準テンプレートに入っているcssの記載に沿った形に修正すればいい
具体的に言うと、cssを入れ替えて、本文中にあるタグを標準css内の記載に合わせる
標準css自体は書き換える必要はない
各社のcssを開いてみると「電書協 EPUB 3 制作ガイド」で配布しているcssプラス独自cssっていうところが結構多いので、その場合だと修正は大変ではないんだけど
小学館みたいに全て独自のところもあってそういうのは修正がかなり面倒 kindleunpackを使わずCalibreでazwをepubに変換した時に、うまくビューアで表示されない問題の原因は、出来上がったepubのcssがepub2用なのと内部構造が指定と違うから
書籍編集で変換前のazwからcssを抜き出して移植する
これはあくまで独自cssの場合を考慮した応急処置
標準cssを使用して自動的に変換できるようになるといいと思う
epubをSigilで開いて保存し直したら読めるようになった、というような報告があったが、
Sigilはepubの内部構造をあるべき形に配置しなおしてくれる機能がある
でもちょっと不満があって、epubの内部構造について調べてもらえばわかるけど、
できればnavi.xhtmlの位置だけtextフォルダに移動しないようにしてほしい
決してエラーではないんだけど原則で指定された位置と違うので気持ち悪い
(DRM解除したepubをwinrarで開いた時と、Sigilで開いた時とでnavi.xhtmlの位置が変わる)
navi.xhtmlの位置がtextフォルダ内に移動してしまうことで、以前古いversionのiBooksで目次機能が使えないというエラーが出た
これはiBooks側のエラーで現在は対応済み 中公文庫の小説でopfがCalibreばかりだったの見たときの絶望感
cssも酷かった記憶 古いepubだとひとつのxhtmlにつきひとつのcssなんてものあるんだよねえ
xhtmlが24個あればcssも24個
cssの意味がない 電書協のテンプレはいらないcssめたくそ書いてるしimportとかしてるから読み込み重くなるんだよな >>732
Sigilに使ってないcssを消す機能がある
重いと思うならそれで消せばいいんじゃね >>734
未使用のスタイルシートクラスを削除のことかな?
amazonじゃなくてkoboだけどかなりの量を削除してくれるのは良いけど表示が崩れちゃったのがあった >>735
いらないのが大量に書かれてて重いって言うんならしょうがないんじゃね
あとは自分でなんとかすればいい DRM解除しただけだと多分日本の小説の8割9割は電書協のcss使ってるんだが
重いって文句をいう奴はどんなcss使ってるんだか興味あるな
公開してみろよ Sigilの改良から始めてそれをCalibreに搭載する
Sigilにテンプレートとして標準cssを組み込む
今まで文字装飾に使っていたタグとcssの記載を合わせる
epub2時代はナビゲーション目次がtoc.ncxだったからhtmlファイルをtextフォルダに集める仕様になってるんじゃないかな
epub3はナビゲーション目次がxhtmlなんでtextフォルダに移動してしまう
textフォルダに置いて本文中の目次用シートと兼用で使うこともできるけど原則はtoc.ncxと同じ位置
兼用させると目次ページで文字装飾が使えないので、日本では兼用してない
もしやる気があるならやってみてください Sigilの公式が対応したね
Sigil-0.9.18から一気にSigil-0.9.991 (pre Sigil-1.0)
皆さんはエラー報告等のフィードバックを >>742
何に対応したの?
Release pageだとbug fixだけでよくわからなかった >>741
>epub3はナビゲーション目次がxhtmlなんでtextフォルダに移動してしまう
kindleunpackの話ならmobi_nav.pyとmobi_opf.pyをちょっと修正すれば
nav.xhtmlをtoc.ncxと同じフォルダに書き出すことができるよ
出力バスをk8textからk8oebpsに
entry= の<a href=にtext/追加
opfのhrefから"'+ 削除
kindleunpack master 0.82での話 DRM解除したepubをepubcheckにかけて、出たエラーをSigilで修正しようとするとSigilが強制的に移動させる
Sigilの開発はCalibreのチームが引き継いでやってるからCalibreの改良にもつながると思うよ そろそろVer4.4に移行しても問題なさそうですか? DeDRMのWindows Applicationをexe化するpy2exeのスクリプトです
そろそろPython2も終わりなのにDeDRMがあるから移行できない人に
DeDRMAPP2EXE.zip
https://www.axfc.net/u/4012533
DLパスワード DeDRM これで本読むときにページ送りってどうやるの?
マウスのホイール回してもカーソルキー押してみてもpageup/down押しても
章単位で飛ぶから次のページを読むことができないんだけど calibreのビューアは使えないからepubのビューアはkinoppyでも使え ビューアでkinoppy使い出すと見開きページ表示に不満が出てopfの修正したくなる
そして読書位置保存したくてライブラリ管理もさせたくなる
そうすると<dc:title、<dc:publisher、<dc:creatorが一貫してないのに愕然としopfの修正したくなる
と悪循環が始まる そしてxmlパーサに手を出し
namespaceにハマる >>754
これで得意げなのがね…
日本終わってるだろ 見開きって漫画?
zipにしてmangameeyaじゃないの? >>758
ラノベ
左右別画像ファイルなのは順番がズレて連結して表示されないことがある
左右連結画像ファイルは片ページに(小さく)表示されるのが多い
あと表示には関係ないがresの画像と差し替えないと左右で画像サイズが違うなんてのもあった >>752
右端をクリックだろ。右綴には対応してないから、右端クリックで次のページ、
左端クリックで前のページ、スクロールホイールで章移動。
4.4 Viewerで日本語縦書きがやっと安定して読めるようになった感じだが、
PDF変換は相変わらずうまくいかない。 >>759
自分でスキャンしなおせばいいんじゃね?と、白々しく言ってみる。 先日からhttps://narou.nyanpass.jp/がずっと止まっているので
AozoraEpub3で既存のものを作り直しています。
カクヨコムにも対応されていればAozoraEpub3に完全移行できるのですが
なかなか難しいですね。 >>762
自分はGitHubのNarou.rbに乗り換えた
カクヨコムにも対応 >>763
確かに結構便利な感じですね。
最終的には出力したEPUBファイルから、変換&表紙&挿絵挿入済みの既存分に
更新分のテキストと目次ファイルをCaribre上で既存の作成分に付加して更新しているので
カクヨムにも対応していることもあり年末の休暇を使って導入してみようと思います。
情報有り難うございます。助かりました。 kindleunpackでepub化したときの画像ファイル名をcalibreでepub化したときと同じ名前に出来ないんですか?
unpackだとresファイルとの置き換えが面倒
calibreのだと他で書かれてるように見開の画像たりするし ■ このスレッドは過去ログ倉庫に格納されています