「自然順ソート」あれこれ

2016/09/20

 最近ちょっとしたツールを作っていて、スクリプト内で「Finderの表示順にファイルをソート(整列)させたい」という要件がありまして、なかなかに手こずったので今後のために備忘録としてまとめておきます。

Finderでのソート順って?

 まず、Finderでのソート順って何かっていいますと、

ファイル1,ファイル2,ファイル3…ファイル10,ファイル11,ファイル12

 となるようなソート方法のことです。文字列の後に数字が来るような場合でも数値順にソートさせたい。
 perlなどで普通に文字列順にソートさせても数値でソートさせても

ファイル1,ファイル10,ファイル11,ファイル12,ファイル2,ファイル3…

 となってしまい、思ったような処理ができません。

 Finderでのソート順については、降りてきた天の声によると

 とのことらしく。ありがとうございます@ogwataさん。

 なお、どうやらJIS X 4061 照合順番で定義されてるようなソート方法を「自然順ソート」と言うらしいのですが、PerlだとSort::Naturallyあたりのモジュールを利用すればできる模様(参考)。ただ今回は配布ツールでの使用を考えているので、CPANからモジュールを入れる的な話はできれば避けたく、いろいろと違う方向性を模索していたわけです。

Xojo内でCocoaのライブラリを呼び出してソート

 フロントエンドのツールはXojoなので、Xojo内でできればなと思って、過去にQiitaにされていたアップされていたこちらの神エントリをもとにどうにかソートできるようにしたのが以下。さすがです@monokanoさん。

 Xojo内でモジュール化しておいて元の配列を投げ、ソート後の配列を得る、みたいな使い方です。今回の目的としてはFinderのソート順の再現なので、Finderと同じエンジンを使うこちらが一番目的に叶いそうです。ただもちろんCocoaのライブラリを呼び出している以上Mac専用にはなります。

Applescriptでの自然順ソート

 AppleScriptでもできそうかなということでこちらの投稿をもとに作ってみたのが以下。

 他の処理系に投げるので一回文字列に結合して引数として投げ、ソートした後に再結合した文字列を得ます。でそれをまた分解して配列に。
 AppleScriptはテキストアイテムデリミタでの文字列の分解結合処理がいつもながらややこしいのですが、そのあたりはまあご愛敬ということで。こちらもAppleScriptを使う以上Mac専用です。まあそのうちAppleScriptで自然順ソートさせなきゃならないケースも出てくるかも知れないし。

PHPのnatsort関数でソート

 PHPには自然順ソートができるnatsortという関数がデフォルトで入っているとのことなのでやってみたのが以下。

 一番簡単かも。Mac環境に依存しないのでそういう意味での使い出もありそうです。

 3種類の自然順ソートを収録したXojoのファイルをこちら (16)に置いておきます。

 で、ブログにまとめてたら最後になんかPerlでモジュールを使わずにできそうなサンプルを発見してしまった。最初に出てきて欲しかった(汗)。

(2016.9.20)

追加情報メモ。
・ApplescriptならFinderにtellしてsort by nameで並べ替えちゃうのが手っ取り早いと。ただし処理は遅いから大量のファイル処理には向かないとのこと。
・OS Xでもバージョンによって微妙にソート結果が変わったりするらしい。なので確実にFinderのソート順通りのソート結果が欲しければApplescript上からFinderを呼び出して値を取得するか、Cocoaのライブラリを呼び出してソートさせるかするしかない。
・対象がファイル名ならPerl内からosascriptでApplescript呼んでFinderに聞くのが手っ取り早いんじゃないのと言われたのでちょい試しました。以下コードをメモ。

行けますね。楽でいいかも。



EpubCheckでID名がエラーになる問題

2016/08/03

 先日、弊社で作ったEPUBファイルが電子取次さんのチェックに引っかかって修正で戻ってきたという件がありました。EpubCheck※1のエラーとのことなのですが、弊社でのチェッカーのログはエラーになっていない。どうもEpubCheck3.0.1ではエラーとなっていたものがEpubCheck4.0.1でエラーにならなくなり、チェックに引っかからなかったということのようです。ちょっと困った事態なので突っ込んで調べてみました。

XHTMLのID名のエラー

 エラー内容は「value of attribute "id" is invalid; must be an XML name without colons」とのことだったので、まずは該当箇所を見てみます。ID名が「id="toc-001*"」のような形となっており、なるほどこれはエラーになるわけだと一旦は思いました。XMLではID名に「*」の記号を使うことを許容していないからです※2。ということでまずはEpubCheckの各バージョンでこの状態のEPUBでエラーになるかを見てみます。

 EpubCheck3.0.1だと
EpubCheck3.0.1でのチェック結果

 なるほどエラーとなるようです。

 EpubCheck4.0.1だと
EpubCheck4.0.1でのチェック結果

 エラーになりません。なるほど。

 では、ちょっとID名を変えて見てみます。「id="toc-あ001"」と、ひらがなの「あ」を入れてみました。この状態でEpubCheckをかけますと

 EpubCheck3.0.1で
EpubCheck3.0.1でのチェック結果

 おや、エラーになりませんね。

 同じくEpubCheck4.0.1だと
EpubCheck4.0.1でのチェック結果

 こちらもエラーにならないようです。

HTML5ではID名に何を使ってもよい

 困った話だなと思ったのですが、さらに調べるとどうもHTML5では途中にスペースが入らない限りID名に何を使ってもよいとの話もあるようで※3、これに従うと挙動としては実はEpubCheck3.0.1でエラーになるのが間違いだったということになるのでしょうか。
 ただ、EPUB3を内部的にXMLなどに変換して表示しているビューアも存在しますので、XMLのID名使用可能文字の制限に従っておくのが無難なのは間違いないと思います。ということでどうやらこの件ではEpubCheckを当てにできませんので、独自にPerlでチェッカーを作ってみました。

 こんな感じでしょうか。一応これでチェックは可能となりました。ターミナルで引数にEPUBファイルを指定してやることでログファイルを出力します。環境によってはArchive::Extractモジュールのインストールは必要かもしれません。

 EpubCheckはIDPFが配布している公式なEPUBの構造チェッカーですので、まずはこれを通るデータであることが市場流通させられるEPUBの最低条件であることは言うまでもありませんが、各パラメータチェックの細かな部分を見ていくと、必ずしもEpubCheckだけで十分というわけでもないようです。現場サイドでの対応も必要といったところでしょうか。

*1 IDPFの提供している公式なEPUBデータチェック用バリデータ。これでエラーとならないことが市場に流通させられるEPUBの最低条件。

*2 半角の英数字および「.」「:」「_」「-」のみ使用できる

*3 参考:https://www.marguerite.jp/Nihongo/WWW/RefHTML/Attrs/id.html

追記:XML関係の有識者の方にコメントいただきまして、どうやら規格としてはHTML5およびそれを内包しているEPUB3ではID名にはどんな文字を使ってもよい、ということで確定のようです。ただ、実際には古いXML規格で回っているシステムは多数あるかと思いますので、ID名にひらがなや漢字、旧規格で認可されていた以外の記号類を混ぜるようなことはしない方が無難だろうとは思います。規格と実装はまた別です。

(2016.8.3)



Kindle Unlimited上陸について思うこと

2016/07/19

 Amazonがアメリカ本国で展開中の定額電子書籍読み放題サービス、Kindle Unlimitedがいよいよ日本上陸か、というニュースが入ってきました。まだ噂の段階ですのでどうなるかはわかりませんが、もちろん入ってきたとしても全くおかしくはありません。ということで今回は、このKindle Unlimitedを始めとした「読み放題サービス」についてちょっと思っているところを書いてみたいと思います。

音楽や動画では常識化してきているサブスクリプション型サービス

 近年、動画や音楽の世界では、定額で見放題、聴き放題型のサービス・・・サブスクリプション契約型のコンテンツ提供サービスが一般化してきています。
 動画配信では今は日本における事業では日本テレビの傘下となったHuluを皮切りに普及が進み、現在はアメリカ最大手のNetFlixに勢いがあります。今テレビを購入するとリモコンの目立つ場所にNetFlixのボタンが配置されているという話もあり、もうこれは完全に一般化したと見ていいでしょう※1。ちなみにこれは従来の放送と通信のバランスを崩すかなり大きな動きです。

 一方、音楽の世界でも聴き放題サービスが続々と登場してきています。海外で大きな勢いがあり、近々日本上陸も噂されるSpotify、アジアに拠点を置き、日本を含むアジアの楽曲に強いKKBOX、LINEのサービスとして登場し、かなりの注目を集めたLINE MUSIC、3500万曲という膨大なラインナップを誇るGoogle Play Music、AppleのサービスということでiTunesを始めとした従来のシステムに統合された形で提供されるApple Musicなど、こちらも既に飽和状態と言ってよいかと思います。

まだ課題の残るビジネスモデル

 ただ、こうしたネット経由のサブスクリプション型コンテンツ提供サービスはまだまだ黎明期ということもあり、さまざまな課題も浮かび上がってきています。
 Apple Musicの3ヶ月間無料キャンペーンでキャンペーン期間中にアーティストへの楽曲利用料支払いが行われないという方針に抗議して、米国のビッグアーティスト、テイラー・スウィフトがApple Musicから楽曲を引き上げると表明し、Appleが即座に方針を変えて支払うことになったという一幕が過去にありましたが、新しいビジネスモデルだけにこういった権利者と事業者の駆け引きは当分付いて回りそうです。

 また、LINE MUSICが有料期間に移行した途端に利用者数が激減したなどという話もあり、事業者側にしてみればそれはもちろんタダでサービスを展開し続けられるワケがないのですが、利用者視点としてはラジオやYoutubeの代替と見ているとすれば話がわからなくもありません。また、次から次へと聴き放題サービスがサービスインし、一定期間無料で聞けるキャンペーンを行っていますから、サービスを次々に乗り換えればかなりの間無料で音楽を楽しめるのも確かです。

 いずれにせよこれは利用者側に「常識」的なものがまだ形成されていない新しいサービスだからこそ起きている現象だとは言えそうです。

電子雑誌にサブスクリプションを根付かせた「dマガジン」

 では、本題である出版でのサブスクリプションサービスはどうでしょうか。すぐに思い浮かぶ成功例は、電子雑誌市場でのdマガジンの成功です。これはこれまでほぼ不毛の地だった電子雑誌の世界にサブスクリプションを持ち込むことで、紙に比べて売り上げが大きいとは言えないまでも計算できる一定の売り上げが見込めるものにしたという点でとても評価できるサービスです。
 おそらくはNTTドコモのサービスとしてスマホの契約者を取り込むところからスタートし、ゼロからのスタートではないという立ち位置が良かったのだろうなと思っていますが、出版社にしてみれば各雑誌に一定の売り上げが上積みされるわけで、有り難いことに違いありません。

 また、このdマガジンで配信されている電子雑誌は、写真の権利関係の影響などで一部変更があったりはするものの、ほぼ紙雑誌のデータをそのまま流用して作れる固定版面のEPUBデータですから、制作技術面での参入障壁も非常に低いです。レイアウトで見せているようなタイプの紙の雑誌をリフロー型に作り変えるのは相当以上の手間がかかりますし、雑誌ということで時間もかけられない以上さらに大変なことになるのは明白ですから、「今は固定版面でよい」というのは現実的な判断だと思います。もちろん今後もずっとこのままでよいのかという課題はあるでしょうが、それは各雑誌側が今後考えるべきことになるでしょう。

 電子雑誌の技術面では、epubの次世代規格として検討中のものの中に「Epub Multiple-Rendition」という策定中の規格があり、これに各ビューアが対応してくれば結構大きな影響が出てくるだろうなと思っています。これはひとつのepubパッケージ内に複数のepubデータを収納するというような規格なのですが、固定版面型データとシンプルなリフロー型データを両方収納しておき、適宜切り替えて読ませるといったような使い方が期待できるわけです。

書籍の「定額読み放題サービス」

 さて、肝心の書籍の定額読み放題サービスはどうかと言えば、こちらも既に先行している例はあり、auの展開する「ブックパス」Yahoo!ブックストアの「月額読み放題プラン」などがあります。いずれも手軽な値段でコミックや軽い読み物などを楽しめるという性格のストアです。また少々変わり種としては、有斐閣が展開する法律系古典書籍の定額読み放題サービス「YDC1000」などもあります。

 Kindleがここに参入してくるとなると、当然ビッグプレーヤーということで相当以上のインパクトはあるでしょうが、やはりコンテンツの中心は軽い読み物やコミックになるようには思います。
 ただ、Kindleはもともとビジネス書に強いという特性を持つストアですので、そちら方面がかなり多く並ぶというのはあるかも知れません。
 また、Amazonはサービス開始初年度には通常の販売と同額の代金を出版社に支払うとの話もあるようですので、これが本当ならそれなりに人気作がラインナップに入ってくる可能性はあるでしょう。

堅い専門書などは一見向かないが・・・

 一方、専門書など「堅い」タイプの本はKindle Unlimitedのような一般向け読み放題サービスには一見向かないようには思えます。ただ、例えば新刊発売後の数ヶ月間だけKindle Unlimiedで読めるようにしておき、プロモーションとして利用する手はあるのではないかと思います。

 先日の紀伊国屋書店新宿南店の閉店に象徴されるように、利幅の薄い本を商品とする書店は大型書店ですら苦戦を強いられているのが現状であり、従来新刊の販売プロモーションに大きな役割を果たしてきた書店店頭の面陳、平積みの面積は減り続けています。これを補完する意味で、一定期間電子読み放題サービスに出すというのは意味があるように思います。

 「堅い」本は現在でも多くの場合は紙で購入されていますし、通常手元に置いておいて折に触れて何度も参照したいものでしょうから、数ヶ月で読めなくなるのであれば結局「試し読み」と同義になるでしょう。従来も書店店頭では全ページ目を通すことができたのですから、これによって書籍の売り上げが減るといったようなことは無いのではないでしょうか。

 ただし、普通に考えれば他の大量のコンテンツに「埋もれ」ますから、出版社の側で販促用Webページを用意し、SNS等で拡散をかけるなどの方法で独自に導線を用意してやる必要はありそうです。
 また、「堅い」本であっても、例えば大学で教科書に使われるようなものなどにはちょっと向かないようにも思いますし、実際にどの本で仕掛けるかは各出版社が慎重に判断する必要はあるでしょう。

 書籍の「定額読み放題サービス」というのは一見、従来の紙の本ではちょっと考えようが無かったビジネスモデルであるように思われます。ただ、例えばネットカフェ/マンガ喫茶は、場所やドリンク、コミック以外のゲームなどのコンテンツ提供と込みであるとは言え、「定額読み放題サービス」としての側面を持っています。
 また、地域や大学などの「図書館」は、各地域の税金や大学の学費などを原資に書籍を購入し、地域住民や学生に書籍を貸し出しているという意味で広義の「定額読み放題サービス」であるとは言えそうです。もっとも図書館にはそれ以外にもの地域や学校内のコミュニティセンターや、長期にわたっての資料のアーカイビングなど他にさまざまな役割がありますから、「読み放題サービス」としてのみ考えるのは無理がありますが。

 いずれにせよ、デジタルコンテンツでのサブスクリプション型サービス自体はもう大きな流れとして定着してきており、出版の分野でも一定の地位を占めると思っています。ただ、そこでの主流がKindle Unlimitedになるのかどうかはちょっとまだわかりません。この分野が今後どう発展し、定着していくのか、しばらくは目が離せないところです。

※1 参考:ネットフリックスの時代(西田宗千佳/講談社現代新書)

(2016.7.19)



プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。