「小説家になろう」など、小説ホスティングサイトから ePub 形式の電子書籍データを作るスクリプトを私は作って使っている。
https://github.com/SaitoAtsushi/yomou-publisher
このスクリプトは新規投稿分だけでなく必ずその小説の全てを取得してから ePub にするデザインになっている。 過去に取得した分に変更がなくても再度取得するという無駄をしているのだ。 どうしてキャッシュしないのかというと、変更箇所が検出できない場合があるからだ。
まず、 URL は以下のような形式になっている。
http://ncode.syosetu.com/作品コード/話数/
作品コードはNコードという名前が付いている。 短編の場合は話数の部分はないが、ここでは複数の話から成る長編作品のみを考えることにする。
そして目次ページにはそれぞれの話がいつ投稿されたのか、最終改訂日はいつかといった情報も書かれている。
以上を踏まえてこのような例を考えてみる。
| パス | 表題 | 投稿日 | 更新日 |
|---|---|---|---|
| /n1234i/1 | 起 | 1日 | - |
| /n1234i/2 | 承 | 2日 | - |
| /n1234i/3 | 転 | 2日 | - |
| /n1234i/4 | 結 | 3日 | - |
この後で「承」が流れに合わないと判断して削除するとこうなる。
| パス | 表題 | 投稿日 | 更新日 |
|---|---|---|---|
| /n1234i/1 | 起 | 1日 | - |
| /n1234i/2 | 転 | 2日 | - |
| /n1234i/3 | 結 | 3日 | - |
パスの話数の部分は常に連続する。 削除があるとその分を詰めて常に連続するようにさせられるのだ。 この挙動が問題をややこしくする元凶である。
更に、元々は「転」だった話こそが「承」にふさわしいと考えて改題するとこうなる。 (改題も内容の更新と同様に更新扱いされて更新日が変わる。 改題した日は4日とする。)
| パス | 表題 | 投稿日 | 更新日 |
|---|---|---|---|
| /n1234i/1 | 起 | 1日 | - |
| /n1234i/2 | 承 | 2日 | 4日 |
| /n1234i/3 | 結 | 3日 | - |
この状態で再びスクリプトを走らせて電子書籍化するとなると、前回と比べてどこが改訂されたか判断できるだろうか。 ここから読み取れる可能性は複数種類ある。 「承」の内容が改訂されて「転」が削除されたようにも見えてしまうのだ。 同じようなことが最新話数あたりで起こると更新されたという事実さえ見えない場合も有り得る。
もちろんそういったことが起こるのはごく稀だとは思う。 しかし確実に起こり得ることだ。 だから私は、いっそ全くキャッシュしないという選択をしているのである。
Document ID: cb64fd3f95388f19b93fb404bf760cbb
