winmergeという神ツール
バージョン管理ツールというのがある。
バージョン管理ツールというのは「テキスト」の変更履歴を管理するツールのこと。
今日時点だとネットではgitが決定版と言われていて、ほかにもCVSやsvnなんてのもある。
このあたりは、ひとつのプロジェクトをチームで動かしているようなケースでは必須のツールだろう。実際にFreeBSDやlinuxなどOSのソースコードはこの手のツールで管理運用されている。
ただ、個人で、ひとりの作業で使うにはどうだろう。
これからはgitだ、というんでインストールしてみたものの、個人でちまちまやってる分には大袈裟すぎて管理のための管理作業が発生して面倒なだけだった。仕事で他の人が管理しているツリーにメンバーとして参加、コミットしたりとか程度でがっつり使ったこともないし、実際のところはよくわかってない。
とはいえ、
「納品20210110.zip」
「納品20210110b.zip」
「納品20210110-修正1.zip」
「納品20210110-修正0115.zip」
ということもよくあって、変更履歴の管理はさすがに痛感しているので、納品後の修正や差し戻しがあったら(って、なんでやねん、という話だけど)ディレクトリごと別ディレクトリとしてコピーして作業するようにしている。
こういう時に、もう10年ぐらい重宝しているのが、winmergeという差分確認、マージ(差分擦り合せ)のためのツールだ。
https://winmerge.org/
これがなければ仕事にならないし、これのためにWINDOWSを使い続けている、といっても言いすぎじゃない。
神ツールとはまさにwinmergeのことを言う。
2つのファイルの差分をチェック
百聞は一見に如かず。
ふたつのファイルで違いのある箇所が左側のルーラーの黄色の部分。
メインの左右画面では違いのある箇所が赤く表示される。
差分、変更箇所がすぐに目視できる。差分のある箇所を個別にどちらかに合わせることもこの画面ですぐ、だ。編集されて上書き保存されたら元ファイルは拡張子が.bakになって保存される。
これはeasy_epubという電子書籍作成スクリプトのソースコード。
左側がオリジナルのリフローEPUB用、右側がハイブリッド対応版
無駄に機能追加したり、つぶしきれないバグフィックスをするたびに、別フォルダにコピーして修正。修正したらwinmergeで修正箇所、修正漏れの確認をして動作確認。動作が意図どおりじゃない時などもwinmergeのおかげで修正箇所の洗い出しが一発なので楽チン。
ディレクトリごとの比較
winmergeにファイルではなくてディレクトリを指定して読みこませると、ディレクトリ内で違いのあるファイルがこれまた一目瞭然。
違いのあるファイルが黄色くハイライトされている。
これはdoncha.netのサイトの一部。スクリプトやhtml、css、javascriptなどいろんなファイルがてんこ盛り。
webの場合、デザイン変更ひとつ取ってもhtml、構造の変更なのか、css、見た目のデザイン変更なのか、そのためにスクリプトやデータベースの変更は必要なのか、などなど、いろいろ絡んでくる。どのファイルを変更しなきゃいけないのか、実際どのファイルを変更したのか。
winmergeが一目で教えてくれる。
差分のあるファイルを選んでクリックすると２つのファイル比較となり編集更新ができる。
テキストの変更箇所、差分を教えてくれる、直感的で超絶便利なツールがこのwinmergeだ。
ということは。
プログラムとかエンジニアだけのものじゃなく、webのソースとかデザイナーだけのものじゃなく、テキストを扱うすべてのひとにとっての神ツールということだ。
小説書き、モノ書きのひとにとっても、語尾や用語を合わせる前後や、追加エピソードやセリフの確認とその比較に使える。
一太郎やワードはさらにモノ書きに特化した機能満載だから、それで間に合っているかもしれないけど、一太郎もワードも入っていないパソコンもあるしね。
gitやsvnのように更新、変更履歴を追うことはできないけど、winmergeさえあれば、個人でやる仕事については、万全磐石の安心感。
だがしかし、めちゃくちゃ残念なことにwinmergeはWINDOWS版しかない。macにもchromebookにも当然ない。
わたしの弁当箱macはすでに最新のOSアプデ対象外となっていて、今はただの鉄の箱だからいいとしても、去年末あたりから使い始めたchromebookで使えないのは致命的。このchromebook化したASUSのvivobookで委託のWEB運用、請負の電子書籍制作をやっていて、特に電子書籍の方はwinmergeでの作業がはいる。
原本、底本の元データと電子書籍化したEpubデータの差分チェックは欠かせない。
作成中にルビを取りこぼしたり、全角の空白を潰したりしてしまうこともあるし、修正依頼に対応したら修正の必要がない箇所に影響したり、などなど確認項目は多岐に渡る。
そのためだけに、WINDWOS機を起動してwinmergeで確認してたんだけど、さすがにどうにかせんといかんなあ、と必死のぱっちでぐーぐる先生。
「漢」ならdiffで頑張れ
とか言われてるんだけど、いくらなんでも無茶すぎ。そこでvimの出番となった。
エディタのvimがほぼ万能で、こいつもできないことを探すほうが難しいやつ。
vimdiffという差分チェックができるモード(？)がある。見た目もwinmergeとほぼ同じ、ていうか、vimdiffの方が先だろう。これで、ディレクトリ内のファイルの比較もできればなあ、と。
たぶん、いや、間違いなくvimだけでできると思うんだけど、わたしにそんなスキルも時間もないので、diffでディレクトリ比較した結果を適当に整形して読みこんで画面分割してやってみることにした。
winmergeほど便利じゃないんだけど、やりたいことはほぼこれでできることとなった。
ちなみにvimについては
https://knowledge.sakura.ad.jp/23018/
↑こちらのサイトがおすすめ。
しかしなあ。
21世紀にもなって、ラクをしようとするな、ツールなんか信用するな、というクズな仕事場もあって心の底から呆れるばかり。どうぞそのまま滅んでくださいとしか。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» 電子書籍(279) » web(158) » ガジェット(64) » パソコン(32) » ソフト・ツール(4) » vim(1)
スクレイピングをブロックされるの巻
ISBNをキーに本の情報（タイトル、著者、書影）を求めて三千里、だ。
あらすじその１
かれこれ15年以上、ずっと利用させてもらっていたAmazon（PA-API）の利用条件が変更となり、うちのように売上のほとんどないサイトだと利用するのが難しくなった。
状態を見ていると、使えたり使えなかったり、というかほとんど使えないんだけど、時々使えることがある、といった感じ。その条件がよくわからない。
あらすじその２
PA-APIがそんな状態なもんだから、Amazonの商品ページをスクレイピングしてのデータ取得に変更。すんなりデータが取れた、と思う間もなく（ほとんど7日以内）スクレイピングがAmazonにブロックされてしまった。
データが取れなくなったんで、取得するHTMLを眺めたら、自動アクセスしているようだけどAPIがあるからそちらを使いなさい、というコメントが入っていた。
そもそもアマゾンは規約でスクレイピングが禁止されてるので、やっちゃいかんのだ。
てことでamazonについては、ほぼ利用できなくなった。
（アフィリエイトタグ、リンクやアカウントには問題はない。データベースとしてAmazonが使えなくなったということ。念のため）
何度も書いてるように4月になったら国立国会図書館がAPIを公開するので乗り換えを検討。
ただ、どんなAPIなのかどんなデータが使えるのか、実際に公開されてから確認となる。
いま公開していて、ユーザーさんが利用してくれているサイトもあり、いままさにどうするのかということで、繋ぎでいいのでなんとかしなければならない。
AmazonのPA-APIが不定でたまにしか使えない（たまに使えるからかえって未練たらたらとなる）
Amazonに対するスクレイピングは規約も不可。
ということで、その場しのぎのでっちあげ、というわたしの得意技。
AmazonのAPIを使ってページを公開しているサイトをピックアップして、そちらをスクレイピングすることにした。
アマゾン本家ではなくAPIを利用しているコバンザメからデータを持ってくる便所バエ作戦だ。
本のデータを取得するためだけに、文字通り機械的にアクセスするわけだから、そのサイトにとっては何の利益にもならない、ただの無駄なアクセスとなる。amazonのようにインフラも強固巨大なサイトならともかく、規模的に小さなサイトだとちょっとした負荷も迷惑でしかない。
さすがに申し訳ない。
のべつ幕なしリクエストを投げるようなことを避けるために自鯖内で期間限定のキャッシュすることにした。
図式的には
・本の情報が欲しい時はまず自鯖のキャッシュを確認
・キャッシュされていればそれを利用
・キャッシュになければPA-APIを利用してデータ取得を試す
・PA-APIでデータ取得できればそれを利用。取得したデータをキャッシュ
・利用制限でデータ取得できなかったら他サイトをスクレイピング。
・スクレイピングでデータ取得できればそれを利用。取得したデータをキャッシュ
てことにした。
キャッシュするのは、ISBN・タイトル・著者の基本3点セット。さらにデータがあれば書影のURL。
本のタイトルや著者をキャッシュすることは問題ないはずだけど、書影（画像）についてはたぶん権利関係がらみで面倒くさいことがあるだろう。
画像をダウンロードして利用するなどもちろんアウト…というかただの犯罪行為。
公開されている書影のURLについては問題ないと思うけど、書影を公開しているサイトと書影（画像）の権利者とでどのような約束があるのか不明で、おそらくずっと同じURLで公開しない。もしかしたらアクセスのたびにURLが変わることも考えられる。なので自鯖でのキャッシュを期間限定とした。
今回のことでちょっと調べてみたら、スクレイピング行為がなにやらマーケティングだのなんだので使われていて、スクレイピングについてのスキルを持っているといろいろ重宝されて優位に立ち回れるとのこと。
いやいや、ちょっと待てよ、だ。
公開されているものとはいえ、他人の著作物から、自分の都合の良いデータだけ切り取ってもってくるのがスクレイピング。そしてそのデータは権利者の意図とは違う使い方をされるのがほとんどだろう。カタカナ言葉でなんかごまかそうとしているけど、単なるタダ乗り行為。
なんちゃら猛々しいんじゃねえのかとか、便所バエの自覚はないのかと昭和老害は思うわけですな。
て、オライリーからこんな本まで出てるんだなぁ。ううううむ。ほんまかいな。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
WEBサイトのValidator偏執狂
WEBサイトを制作したりするんで、HTMLやCSS、javascriptの必要最低限のエラーや警告のチェックはしている、つもり。
「W3C Markup Validation Service」https://validator.w3.org
というサイトもあるし、HTMLやCSSの構文チェックをするツールは各種いろいろある。
…なんてこと言いつつ。
エラーも警告も出ない・出さない、いってみれば100点満点のWEBサイトの必要はあるんだろうか。
たとえば、webサイトでアマゾンECSやgoogleアドセンス、あるいはtwitterやfacebookのシェアなど、よそさまのサービスを自分のサイトに組みこむことなどよくある。そして、それらのコードがすでに警告やエラーの対象となってたりする。
そのせいで、100点満点のWEBサイトにならない、だからこれらのコードは使わない、よそのサービスを組込まない、とか言いだしたら本末転倒だろう。
何のためのWEBサイトかと。
Validatorで警告もエラーもない100点満点のWEBサイトのために、本来やりたいこと見せたいものを制限してどうする、てことだ。
ふた昔前は、Validatorでエラーや警告のあるサイトはSEO的に不利だと言われていたけど、今どきはどうなんだろう。googleさまは日進月歩。metaタグのdescriptionよりbodyの文章を「解析、判断して」表示するようになったのはもう何年前のことか。あれ？昨日までmetaタグのキーワード大事じゃなかったっけ？とか、コンテンツの見出しタグ、altタグはどうだっけ？とか。
だいたい、SEOのために100点満点のきれいなHTMLあるいはCSSを頑張るより、googleさまがユーザー視点から解析の精度をあげて検索結果に適切なものを表示するようになることの方が期待できる。
必死になって100点満点を目指してる・警告もエラーもないことをセールストークにしているのを見かけることがあるんだけど、W3Cにお墨付き・認められたからといってユーザーに認められることにはならない。それで作ったサイトはユーザーにとって使いやすいのか・見やすいのか。
HTMLやCSSのエラーは確実に潰すことができるし、それで100点満点に近づくのは充実感・自己肯定感が得られるので面白いんだけど。
ユーザー視点の欠如だ。あるいはただの自己満足。
最低限、ブラウザでの表示で致命的なエラーとなるHTMLのタグの不整合のチェックはするにしても、Validatorで少しでもエラーがないようにするにしても。
そこにこだわってるヒマがあったら、コンテンツの充実や情報設計というか動線やラベリングについて検討すべきだろうと思う。
もちろん、エラーや警告が許されないものもある。上記はWEBサイトについて(念のため)
たとえば電子書籍(EPUB)の納品はシビアで、エラーはひとつでもあったらアウトだ
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» web(158)
paypalを使って電子書籍のダウンロード販売
電子書籍元年が何度もきたおかげで、電子書籍(デジタルコンテンツ)のダウンロード販売がDRMもついてAmazonや楽天kobo、iBookstore、KADOKAWA☆BOOKWALKERに並べることができる時代となった。
また、電子書籍専門というわけではなく、デジタルコンテンツをダウンロード販売できるサイトも百花繚乱雨後筍で、コンテンツさえ用意できれば個人で簡単に販売ができる。
「デジタルコンテンツをダウンロード販売できるサイトを比較してみた」
http://writing-san.blog.jp/archives/32017213.html
また、ワードプレスにはダウンロード販売のためのプラグインまであって、販売チャンネルの選択肢はたくさんある。
「Easy Digital Downloads - ダウンロード販売サイトを簡単に作れるWordPressプラグイン」
http://netaone.com/wp/easy-digital-downloads/
集客力販売力、販売手数料や手間ひまを考えて自分に合うところにコンテンツを置けばいいし、そうすれば販売ページへのURLや購入ボタンをSNSや自分のサイトに貼りつけて告知できる。
ぶっちゃけ、わざわざ自分でダウンロード販売の仕組みとか作るのは時間と労力の無駄なのでオススメしない。
面白そうだ、という好奇心自己満足。それと、もしかすると、何らかの事情で他社サービスにコンテンツを置くわけにはいかないような場合に。
てことなので、以下はわたしの技術メモ。備忘録。
内容的には2010年の雑記とPayPalとのやり取りなどはほぼ同じ。
「paypalと電子書籍のダウンロード販売（その１）」
http://t2aki.doncha.net/?id=1277017233
「paypalと電子書籍のダウンロード販売（その２）」
http://t2aki.doncha.net/?id=1277130006
今回の雑記では自サバ側のこともメモしておく。
【じぶんちでの設定】
コンテンツをサーバーの所定のフォルダにアップロード。
サーバーのデータベースにコンテンツの商品登録。ここで商品にIDを付ける。
以下3つのスクリプトを用意
・ご購入ありがとうございますページのスクリプト
・IPN受信&データベース登録用のスクリプト
・ダウンロード用スクリプト
【PayPalでの購入ボタン作成・各種設定】
「トップ」→「販売ツール」のメニューにある「売り手の設定」から
→「PayPalボタン」
[今すぐ購入]サンプルボタンあたりを雛形に「ボタンの編集」で商品名や値段などを入れる。ここではオプションの商品ID（＝データベースで決められたID）を入れるのを忘れずに。
ボタンを作ったら「コードをコピー」して自分のサイトの購入ボタンを設置したいところにコードをペーストする。
→「ウェブサイトの設定」(ウェブペイメントの設定)
・ウェブペイメントの自動復帰「オン」
・復帰URL：ご購入ありがとうございますページのURLを記入
・支払いデータ転送「オン」※IDトークンをコピーしておく
・暗号化されていないウェブペイメントの受領拒否「オフ」
・PayPalアカウントオプションサービス「オン」
・連絡先電話番号「オフ」
・エクスプレスチェックアウトの設定「いいえ」
→「即時支払い通知」(IPN)
・通知URL：IPNを受信するスクリプトのURL
・メッセージの配布：有効
→「PayPalボタンの言語コード化」
・「詳細オプション」→「UTF-8」
【PayPalとのやりとり】
ユーザーの動きは以下の3つ。
1)ユーザーがオレオレサーバーの購入ボタンをクリックすると
2)PayPalの決済ページに飛んでそこでお支払い
3)お支払いが終わるとオレオレサーバーの購入ありがとうございましたページに戻ってくる。
ユーザーのお支払い終了と同時にPayPalからオレオレサーバーに購入データが飛んでくる。
購入データは以下の2種類。
データを取得して解析するためのサンプルコードがPayPalに用意されていて、そのまんま利用させてもらう。
3)PDT(Payment Data Transfer)
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・ユーザーが購入ありがとうございますページにリダイレクトされてくる時に、トランザクションを持ってアクセスしてくる
→オレオレサーバーからPayPalへ
・トランザクションと管理ページの「支払いデータ転送」の項目に記載されているIDトークン、コマンドをPOSTでPayPalにリクエスト
→PayPalからオレオレサーバーへ
・POSTした内容が正しければ一行目に「SUCCESS」と書かれたデータを返してくる
このPDTデータは
SUCCESS
first_nameJane+Doe
lst_name=Smith
payment_status=Completed
など、1行にひとつ「ネーム＝バリュー」形式、NVP形式のデータとなっている。
※ユーザーが支払いを終えて待たずにすぐブラウザを落としたりするとデータ取得できない。購入ありがとうございますページにリダイレクトされてやってきて初めてデータのやり取りが生じる。
PDTデータ取得＆解析のサブルーチン
※HTMLデコードと文字コードをutf8にしているところ以外はサンプルコードのまんま。
PDTデータのpayer_emailやitem_nameなどを「ご購入ありがとうございます」ページの「～様」や「～をご購入いただきありがとうございました」などの個別の表示に使う。
PDTデータのitem_number(商品ID)でダウンロード商品なのか、別の商品なのかを判定して、ダウンロード商品の場合はダウンロードURLを表示する。ダウンロードURLはユーザーのemailやtransactionidなど一意のものから作成している。
4)IPN(Instant Payment Notification)
ユーザーから見える言わば表側のPDTと違って、こちらは裏側。
ユーザーがお支払いを終えると管理ページで指定したURLにデータが飛んでくるので取りこぼしがない。
PDTはユーザーに見せるご購入ありがとうございますページに使う程度で、オレオレサーバーのデータベースに購入の記録を残すためにはこちら、IPNを使う。
図では赤い矢印がひとつだけど、データのやりとりの実際は。
→PayPalからオレオレサーバーへ
・購入データが送られてくる。いわゆるWEBのフォームデータで「&」で繋がれた「ネーム＝バリュー」形式
→オレオレサーバーからPayPalへ
・送られてきた購入データにコマンドをひとつつけてPayPalにPOSTする
→PayPalからオレオレサーバーへ
・「VERIFIED」か「INVALID」か一行返ってくる。これ以外は調べる必要があるらしいが滅多になさそうだし、PayPalの管理画面で確認すれば良い。
IPNデータ取得＆解析のサブルーチン
エラーはIPNのデータをつけてメールするように。
VIRIFIED(データが正しい)場合でも以下の4点を確認する。
・支払いのステータス「payment_status」が完了「Completed」であることを確認
・すでに完了した取引の悪用防止のために「txn_id」が過去のものと重複していないことを確認
・不正アカウントに支払いされないように「receiver_email」がPayPalアカウントに登録したメールアドレスであることを確認
・価格が変更されていないか確認(商品IDなども)
確認できたらオレオレサーバーのデータベースに必要情報を登録して、ユーザーにお礼とダウンロードURLを書いたメールを送信する(自分にも同じものを送信)
※データ確認の部分やメールの部分以外はサンプルコードのまんま。
【ダウンロードについて】
ダウンロードはダウンロード用のスクリプトがファイルを返すようにしてある。
たとえば、わたしが自分だけで作ったコンテンツなんかはどうでもいいんだけど、表紙が依頼原稿だったり、アンソロジーでほかの人の原稿が入っていたりするとそうもいかない。回数や期間を無制限にするわけにはいかない。
なので、ファイルの置き場所＝URLをそのままユーザーにお知らせできない。
ダウンロード用のスクリプトを噛ませて
・ダウンロードのURLは購入者ごとに違うものを作る
・ダウンロード回数を制御する
・ダウンロード期間を制御する
といったことを仕込んだ。
また、ダウンロードごとにIPやUserAgentを記録すれば、不正なアクセスやダウンロードできない事故などの問題解決にも役立つ。
以前の雑記にも書いたように、PayPalは管理ページに記録が残ってるし取引が生じたらいちいちメールも飛んでくるので、致命的な問題にはならないはず。サポートもびっくりするというか恐縮するぐらいに厚い。
残念なことに(法律的に？)日本では単純にクレジットカードだけで支払いはできなくなった(ペイパルへのアカウント・会員登録が必須となった)けど、個人での少額決済に手軽に使えるので助かるなあ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
なろうをタテにしてEPUB3電子書籍でヨム
カクヨムをEPUB3の電子書籍に変換してダウンロードするスクリプトを書いたんだけど、カクヨムはR18禁止なのでR18がOKのなろうに退避するケースもあるとかないとか。
カドカワもTL(ティーンズラブ)小説があったような気がするけど、エロではない、ということかな。
てことで、なろうに上がっている小説をEPUB3に変換してダウンロードするスクリプトをでっち上げた。
ttp://ncode.syosetu.com/XXXXXXX
↑小説トップページ(?)目次ページのURLを入力すると電子書籍としてダウンロードできます。
とはいえ、なんだかなろうは商標についてのページや利用規約やガイドラインなんかを見るとどうもややこしいところのようなので(印象)、ダメっぽかったら取り下げます。悪しからずご了承くださいませ。
https://t2aki.doncha.net/tmp/narou2epub.pl
↑例によって直リンクできないフォルダなのでこちらのリンクからどうぞ。
ちなみに。
なろうを電子書籍化するサービスやアプリはすでにあるので、ニーズにあったものを探して利用してみましょう。ウチのより高機能。
「なろうを電子書籍化」WEBサービス
http://narou.nyanpass.jp/
「Narou.rb」rubyアプリ
https://github.com/whiteleaf7/narou/wiki
「AozoraEpub3」javaアプリ
http://www18.atwiki.jp/hmdev/pages/21.html
カクヨムを電子書籍に変換してダウンロードするページはこちら
https://t2aki.doncha.net/?id=1457873699
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(102) » 電子書籍(279) » perl(109) » web(158)
カクヨムをタテにしてEPUB3電子書籍でヨム
時事ネタ。
カクヨムの作品URLを入力したらEPUB3の電子書籍としてダウンロードできるようにしてみた。
カクヨムに上がっているWEB小説をEPUB3ファイルにすることで、KindleやiBooks、Kobo、Knoppy(紀伊国屋)、hontoなどの電子書籍リーダーやアプリで読むことができる。
サイトをクロールしてEPUB3にパッケージするスクリプト程度なら手元の部品の継ぎ接ぎでそれっぽいのができるので作った。
（カクヨムのHTMLの構造が変わったらそれまでだし、たぶんカドカワのことなのでそのうちEPUB3変換のクチも別メニューで出てきそうで、メンテするのも不毛なのでこれっきりの一発ネタだろう）
https://t2aki.doncha.net/tmp/kakuyomu2epub.pl
↑カクヨムを電子書籍にしてダウンロード
※直リンクできないフォルダなので、ご利用の場合はこのリンクからよろしく。
アンドロイドのスマホでダウンロードできないことがあるけど、アンドロイドアプリのFirefox（https://play.google.com/store/apps/details?id=org.mozilla.firefox&hl=ja）ならダウンロードできます。それ以外、PCやMac、iphoneなどは問題なくダウンロードできます。
[2020/01/27 22:11:50]
カクヨムのページを見ると書籍化作品が着々と増えていた。WEB掲載が商業デビューのパスとして確立してきてるんだな
カクヨムは横書きのサイトなので半角の英数字などは縦書きにしても寝転がったまま…うーん、こりゃしょうがあるまい。
(かなりテキトーなでっちあげ)
[2016/03/15 16:15:01] 追記。
連続する半角数字以外に、半角の「!?」「?!」「!!」に縦中横のスタイルを当てるようにした。
[2016/03/19 10:59:01] 追記。
それっぽい奥付生成。
完結したストーリーの本文を取りこぼすバグ修正。
[2018/05/22 21:44:12]
カクヨムのHTMLが変わっていて目次を取得できなくなっていたのを修正。
また、一部の文字(実体参照)は面倒なんで削除することにした。
なろうを電子書籍に変換してダウンロードするページはこちら
https://t2aki.doncha.net/?id=1460978141
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
» EPUB3(102) » 電子書籍(279) » perl(109) » web(158)
