青空文庫の公開ページは、データベースによって更新されています。
そのデータベースからの、一般に向けた情報提供について、検討します。
情報提供の現状
総合インデックス＞作家別＞全てを表示の「ア」の上にある、「→「公開中 作家別作品一覧：全て(CSV形式、 zip圧縮）」をダウンロード」から、公開作品のリストを取得できる。（リンクしているので、ここからも引き落とせる。）
ただし、作家別という仕立ての性格から、著者と翻訳者がたっている作品は、このリストの二箇所に表示される。
リストで提供されるデータ項目が、これで良いのかにも、検討が必要だろう。
作品ファイルのURLが盛り込まれていない点については、かねてから、改善を求める声がある。
今後のあり方
現行の list_person_all.csv の拡充計画に対して、twitterや掲示板で、以下のようなコメントがついた
変更、拡張に際しては互換性重視を希望。
csvは現状でも1.9MBと巨大。現行の list_person_all.csv にURLを追加する場合は、冗長部分をカットするべきかと。
青空文庫書誌CSV増補なら、現行版とは切り分けて別提供が一番。それが無理なら既存ファイルの項目末尾に追加。ただ、現在のCSVでも、スマートフォンのアプリで利用するには巨大すぎる。
現行の list_person_all.csv を修正するより、新たな「作品一覧」を出力していただいたほうが、こちらとしてはありがたい。
人物の役割フラグ（著者、翻訳者、校定者、編者、その他）の出力を希望。
まとめると、
list_person_all.csvの名称で提供している作家別作品一覧は、そのままで維持。（すでに利用の仕組みを作っているが、手直しなしに使い続けられるように。）
追加するものには、作品名、作品名読み、ソート用読み、副題、副題読み、原題、仮名遣い種別、初出、著作権フラグ、作品の公開日、ファイルの種類、ファイルのURL、ファイルの最終更新日（ファイルの登録日は入れても使い道がなさそう。）、人物名、人物名読み、人物名ソート用読み、人物の役割フラグ、分類番号（現在は利用していないが、将来に備えて。）等の記載を検討。
将来のUTF-8（？）での提供に備えて、ファイルのエンコーディングも出力しておくべきか。
その他、data_item.csvに記載している項目で、載せた方が良いものはないか。
追加提供するCSVは、list_person_all.csv同様に、作家別とするのか。
それとも、作品別とするのか。
設けられているデータ項目
データベースに用意されている項目を、data_item.csvにまとめた。
右のNavigatorでFilesを選ぶとみえるので、クリックで。
青空文庫API（アルファ版）
もたもたしている間に、できちゃいました。
http://d.hatena.ne.jp/plasticscafe/20100921/1285023847
ざっと拝見して、「作品情報」に、ファイルが更新されたことの目印として使える「最終更新日」を望む人がいるのではないかと感じました。
「公開日」も、「作品情報」にあればあったでよいかもしれませんが、これはどこにも書いていないので、スクレイピングではとれません。データベースから出力する以外なし。
こうしたものが作られた以上、青空文庫としてはまず、拡充したCSVの提供にしぼって進めるということでしょうか。
なぜ書誌CSVの項目拡充か
青空文庫APIがあると良いという利用者からの声に対して以下の道が考えられます。
- 青空文庫自身がAPIを提供する
- 第三者がAPIを容易に作成できるようなお膳立てをする
- なにもしない
本来は1.がスジでしょうが、手が回らない現実があると思います。
現在は、第三者がAPIを提供するために、必要な情報を取得しようと思うと、誰にも得にならない無駄な手間をかけなければなりません。
具体的には、約1万ある図書カード一つ一つにWebアクセスして、スクレイピングし、自前のデータベースを構築するしかない。
これには、青空文庫のサーバ負荷もかかれば、ISPの通信量もかかれば、APIを作成する側でアドホックなスクレイピングをしなければならない手間もかかります。
（語弊があるかもしれませんが、岡崎図書館の事件 http://librahack.jp/ に似たところがあります。）
しかし、必要な情報がまとまった形で青空文庫から提供されていれば、このような無駄は省くことができます。
これには、以下のような選択肢が考えられます。
- 青空文庫データベースのダンプをdailyに提供する
- 書誌情報CSVの項目を増やしてdailyに更新する
1.は、ダンプ公開に問題さえなければ、外部でAPIを作成しようと思うときには一番自由度が高く、また提供自体も技術的には極めて簡単に実現できます。その反面、カジュアルな利用は難しいでしょう。
▼ここから富田
データ項目にはいくつか、公開しないほうがいいことが書かれています。それを避けてまとめられるのなら、ダンプ公開がいいと、私（富田）は、お話を聞いて思いました。
青空文庫の「中」はいつも、手薄でした。今後も同じでしょう。作品よりの人で構成される事情にも、変わりはないと思います。「中」は、集めて記録するところに集中して、データは世間に投げるのが、活用の近道と思います。
世話役作業を担っている呼びかけ人と点検グループに、話を向けてみます。データベースの開発者にも、問い合わせてみます。
▲ここまで
2.は、CSV形式であるため人間にも比較的容易に利用できるメリットがあります。その反面、一つのCSVで情報を提供する場合は、テーブルの正規化を崩さざるを得ず、今後の拡張性が難しくなるデメリットもあります。
▼ここから富田
たとえば私は、ダンプを前にしても手が出せないし、CSVの拡充もやった方がいいと思います。
１ list_person_all.csvの既存の列の後ろに、要素を追加するのか。（ファイルのURL、最終更新日など。それだけでも、ずいぶん肥大化するけれど。）
２ list_person_all.csvとは別に、補遺となるものを新設するか。新設の際は、データ項目は多めに盛り込んでかまわないか。やはり作家別にするのか。それとも作品別にするのか。
▲ここまで
▼ここから2SC1815J
現在list_person_all.csvを利用しているアプリケーションのことを考えると、list_person_all.csvとは別に新しいCSVを提供するのがベストだと思います（上記2の対応）。
もし何らかの事情で2つのCSVを提供することはできないということであれば、次善の策としてlist_person_all.csvの列の後ろに追加だと思います（上記1の対応）。
1の場合、既存のアプリケーションへのインパクトは、アプリの実装によってはゼロである場合もあるでしょうし（既存の項目以降の項目は無視する実装になっている場合）、ゼロでない場合もあると思います（既存の項目数と合わない場合エラーとする実装になっている場合）。（現在list_person_all.csvを利用している豊平文庫さんからのコメントでは、互換性重視を希望とのことでした。）
2のCSVを新設する場合を想定して、data_item.csvに記載されている項目で、追加が考えられるものを挙げてみました。
| 生成元テーブル名 | 項目名 | コメント |
|---|
| 作品データ |
作品ID |
|
| 作品データ |
作品名 |
|
| 作品データ |
作品名読み |
|
| 作品データ |
ソート用読み |
|
| 作品データ |
副題 |
|
| 作品データ |
副題読み |
|
| 作品データ |
原題 |
|
| 作品データ |
仮名遣い種別 |
|
| 作品データ |
初出 |
|
| 作品データ |
著作権フラグ |
|
| 作品データ |
公開日 |
|
| 作品データ |
最終更新日 |
|
| 人物データ |
人物ID |
|
| 人物データ |
姓 |
|
| 人物データ |
名 |
|
| 人物データ |
姓読み |
|
| 人物データ |
名読み |
|
| 人物データ |
姓読みソート用 |
|
| 人物データ |
名読みソート用 |
|
| 人物データ |
姓ローマ字 |
|
| 人物データ |
名ローマ字 |
|
| 人物データ |
役割フラグ |
|
| 人物データ |
生年月日 |
|
| 人物データ |
没年月日 |
|
| 底本データ |
書籍名 |
|
| 底本データ |
出版社名 |
|
| 底本データ |
初版発行年 |
|
| 底本データ |
入力に使用した版 |
|
| 底本データ |
校正に使用した版 |
|
| 底本データ |
種別フラグ |
|
| 分類番号データ |
分類番号 |
|
| 工作員データ |
入力者 |
|
| 工作員データ |
校正者 |
|
| ファイル |
ファイル形式 |
|
| ファイル |
ファイルURL |
|
| ファイル |
最終更新日 |
|
| ファイル |
ファイルエンコーディング |
|
これらの項目で現在の図書カード相当のCSVになります。
ただし、もともと複数のテーブルで管理された情報を一つのテーブルにまとめて出力することにより、正規化が崩れてしまいます。
正規化の崩れとはなにか、このCSVが作品別である場合を考えてみます。
一作品に複数の人物（著者・翻訳者・校訂者等）が関わっている場合、上表の人物データの項目をCSVの1行の中で繰り返して持たなければなりません。
しかし、CSVとして項目数が一定しないのでは利用するプログラムの側で扱いにくいので、事前に「人物1」「人物2」……のように想定される最大人数分のカラムを用意しておくことになります。
この方式を採った場合、想定していた以上の人数が関与する作品が現れたときに破綻してしまいます。
同じ問題は、CSVが作家別であった場合でも、ファイルに関する項目で発生します。
事前に「テキストファイル」「XHTMLファイル」「PDFファイル」……と想定されるフォーマット分のカラムを用意しておくのは、先ほどと同じく拡張性に欠ける問題があります。
先ほどのリストは、いろいろ盛り込んだ場合の例ですが、逆に切りつめた場合の例を挙げてみました。
| 生成元テーブル名 | 項目名 | コメント |
|---|
| 人物データ |
人物ID |
|
| 人物データ |
姓名 |
|
| 人物データ |
姓名読み |
|
| 人物データ |
役割フラグ |
|
| 作品データ |
作品ID |
|
| 作品データ |
作品名 |
|
| 作品データ |
作品名読み |
|
| 作品データ |
副題 |
|
| 作品データ |
副題読み |
|
| 作品データ |
仮名遣い種別 |
|
| 作品データ |
公開日 |
|
| 作品データ |
最終更新日 |
|
-
|
図書カードURL |
|
| ファイル |
テキストファイルURL |
|
| ファイル |
テキストファイル最終更新日 |
|
| ファイル |
テキストファイルエンコーディング |
|
| ファイル |
XHTMLファイルURL |
|
| ファイル |
XHTMLファイル最終更新日 |
|
現在のlist_person_all.csvと同じように、一つの作品について関与した人物の数だけレコードが存在する作家別CSVを想定しています。
読みたい作品を検索する場合の主たる検索項目は、作者名・作品名・仮名遣い種別ではないかと考え、それらで検索してファイルに辿り着くために必要な項目等に絞っています。
（上記にない情報は、図書カードを閲覧してもらうことを想定。）
最終更新日は、情報を差分更新するために必要です。
第三者が最低限の検索機能を提供するAPIを作成する場合や、青空文庫アプリで目的の作品を検索する場合には、この程度の項目があれば十分だと思います。
ただ、上記の例では工作員データの記載がないので、入力された方・校正された方には気持ちよくないかもしれません（図書カードや本文の最後に記載があるとはいえ）。
ここで挙げた「いろいろ盛り込んだCSV」の場合、明らかにiPhone/iPad/Android等で利用するには巨大すぎます。第三者のサーバで一日一回取得して、API用のデータベースを更新するためのものになるでしょう。
「切りつめたCSV」の場合、これでも大きいかもしれませんが、スマートフォンのアプリ内で処理する向けになるでしょう。もちろん、検索項目が作者名・作品名・仮名遣い種別・最終更新日程度で良ければ、第三者によるAPI構築にも足るデータです。
作者の没年月日が提供されていれば、「今日が忌日の作家の作品をトップページに表示する」といった利用もできます。
初出の年が提供されていれば、青空文庫の作品を時代順に年表上 http://www.simile-widgets.org/timeline/ に並べて表示することもできます。
こうした、さまざまな楽しい（しかし現在の青空文庫では手が回っていない）切り口での青空文庫作品へのアプローチを可能にするには、CSVに項目全部盛りが良いでしょう。
その場合は、新設した一つのCSVで提供するのならば、先ほどの正規化の崩れの問題があります。
しかし、現在のlist_person_all.csvと同じような作家別CSVにすることでレコード内での人物データの繰り返しは回避し、ファイルデータについてはテキストとXHTMLの情報のみ提供することに割り切ってしまい、それ以外のフォーマットについては図書カードを見てくださいとしてしまうという考え方もあるかもしれません。
ここまでCSVの拡張（整理）を考えてきましたが、1つのCSVではなくて複数のCSVをZipで固めて提供することや、RSSで提供することなども考えられるかもしれません。
RSSで提供する場合は、OpenSearchの検索結果のような形で全作品のデータをまとめて提供するイメージです。この場合、上記の正規化云々の問題は生じません。
ダブリンコアを拡張して、作品名の読みは dcaozora:titleTranscription で返すなど、仕様を考えなければなりませんが。
▲ここまで
青空文庫側の作業量を最小に抑えるのであれば、データベースのダンプ提供。次に作業量が少ないのは書誌情報CSVの項目拡充だと思います（やると決まれば実作業には一日もかからないでしょう）。
より踏み込んで将来のことを考えると、実現したいAPIのアイデアを出し合い（例えばURLで検索リクエストを投げRSSで検索結果を得るOpenSearchに対応するなど）、そのために必要な項目で、現在の青空文庫データベースにない項目があった場合にどうするかという課題もあります。
▼ここから富田
この要素に関しては、私は皆さんの話を集約することも難しいので、どなたか、リードしていただけるとありがたいです。
現在のデータベースにない項目については、「補充すれば」と、素人の直感としては思います。
これについても、開発者に話してみます。
▲ここまで
青空文庫APIの参考になる事例：
・PORTA（国立国会図書館デジタルアーカイブポータル）のAPI
http://porta.ndl.go.jp/wiki/Wiki.jsp?page=%E5%A4%96%E9%83%A8%E6%8F%90%E4%BE%9B%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%95%E3%82%A7%E3%83%BC%E3%82%B9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
・CiNiiのAPI
http://ci.nii.ac.jp/info/ja/if_opensearch.html
（この「なぜ書誌CSVの項目拡充か」セクションは2SC1815Jの私見であり、青空文庫の見解ではありません）
提供データの拡張方針
ここまでの検討を踏まえて、拡張の第一歩を、以下の通り提案する。（富田、2010年9月28日）
既存のlist_person_all.csvに加えて、同じく公開作品対象の作家別で、データ項目を拡張したCSVを新設する。
名称は、「公開中 作家別作品一覧：全て 拡張版（CSV形式、 zip圧縮）」、「list_person_all_extended」とする。
出力日を記載する。
データベースのダンプの提供は、先の検討課題とする。
記載項目と配列は、基本的には、2SC1815Jさんの提案（二つあるものの上）にそって、以下の変更を加える。
・「仮名遣い種別」の名称を、「文字遣い種別」に変更する。
・人物データの「没年月日」の後に、「著作権フラグ」を追加する。
・ファイルの、「最終更新日」の前に、「修正回数」を追加する。
・ファイル関連情報は、テキスト、HTML/XHTMLのみを出力する。
以下、確認事項。
・作品データの「作品集名読み」「作品集名」「作品について」「備考」「底本管理情報」「最終更新日」「更新者」は含めない。
・人物データの「email」「URL」「人物について」「備考」は含めない。
・工作員データの「工作員ID」「姓名読み」「e-mail」「URL」「備考」は含めない。
・底本データの「備考」は含めない。
・分類番号データの「分類名」「備考」は含めない。
・ファイル関連は、テキストとHTML/XHTMLのみを出力する。ファイルの「初登録日」「文字集合」「備考」は含めない。（なお、data_item.csvのファイルの項に、作品データと重複して「状態の開始日」を記載したのは、不適当でした。）
・関連サイトデータの各項目は、含めない。
・ファイル関連は、2SC1815Jさんの想定通り、CSVの最後に置く。将来、基本ファイルとして提供するものを増やした場合（ePubや、UTF-8版のテキスト、HTML/XHTMLなどがありうるか）は、最後に追加する。
▼ここから2SC1815J追記 2010/11/09
先日、青空文庫の底本をAmazonから探すサービスが公開されました。
底本の情報は、これまでの書誌CSVにも含まれていましたが、より多くの情報を含む書誌CSVが提供されれれば、よりさまざまなサービスが、図書カードURLに総アクセスして情報を集めたりすることなしに提供可能になるでしょう。
この機会に、改めて提供データ拡充の検討を再開できればと思います。
富田さんの挙げられた項目を追加して、以下の項目の作家別CSVはいかがでしょうか。
| 生成元テーブル名 | 項目名 | コメント |
|---|
| 作品データ |
作品ID |
|
| 作品データ |
作品名 |
|
| 作品データ |
作品名読み |
|
| 作品データ |
ソート用読み |
|
| 作品データ |
副題 |
|
| 作品データ |
副題読み |
|
| 作品データ |
原題 |
|
| 作品データ |
文字遣い種別 |
|
| 作品データ |
初出 |
|
| 作品データ |
著作権フラグ |
|
| 作品データ |
公開日 |
|
| 作品データ |
最終更新日 |
|
| 人物データ |
人物ID |
|
| 人物データ |
姓 |
|
| 人物データ |
名 |
|
| 人物データ |
姓読み |
|
| 人物データ |
名読み |
|
| 人物データ |
姓読みソート用 |
|
| 人物データ |
名読みソート用 |
|
| 人物データ |
姓ローマ字 |
|
| 人物データ |
名ローマ字 |
|
| 人物データ |
役割フラグ |
|
| 人物データ |
生年月日 |
|
| 人物データ |
没年月日 |
|
| 人物データ |
著作権フラグ |
|
| 底本データ |
書籍名 |
|
| 底本データ |
出版社名 |
|
| 底本データ |
初版発行年 |
|
| 底本データ |
入力に使用した版 |
|
| 底本データ |
校正に使用した版 |
|
| 底本データ |
種別フラグ |
|
| 分類番号データ |
分類番号 |
|
| 工作員データ |
入力者 |
|
| 工作員データ |
校正者 |
|
| ファイル |
テキストファイルURL |
|
| ファイル |
テキストファイル最終更新日 |
|
| ファイル |
テキストファイルエンコーディング |
|
| ファイル |
テキストファイル修正回数 |
|
| ファイル |
XHTMLファイルURL |
|
| ファイル |
XHTMLファイル最終更新日 |
|
| ファイル |
XHTMLファイルエンコーディング |
|
| ファイル |
XHTMLファイル修正回数 |
|
ところで、図書カードにはファイルサイズの記載がありますが、data_item.csv を見るとファイルサイズの項目はありません。図書カード作成の際はどのようにしているのでしょうか。
↓ここから富田追記 2010年11月14日
ファイル登録時に、データベース側がファイルサイズをみて、自動的に書き込んでいます。
そうした仕様なので、登録フォームにはファイルサイズの項目はありません。
そのために、data_item.csvには書いていませんでした。
作品の文字数の指標が欲しいという話は、よくわかります。
ただ、ご指摘の要素を回避するには、手作業が必要になりそうで、そこが辛いところです。
↑ここで富田追記終わり。
長編／掌編を検索して読みたい、作品の長さを知りたいというニーズはあると思います。
図書カードにあるようにテキストを圧縮したZipファイルのサイズでも大体の目安にはなると思いますが、挿絵付き作品のZipファイルサイズではファイルサイズと作品の長さがかけ離れてしまいますし、圧縮率はテキストの内容によって変わってくるので、Zipファイルのサイズが分かっても、元のテキストファイルのサイ ズが正しく見積もれない問題があります。また、注記やルビが多い作品は、テキスト／XHTMLファイルのサイズが大きくてもページ数にすると少ないといったケースもあります。ルビや注記を取り払ったときに何文字になるといった情報があると良いのですが。
▲ここで追記終わり
▼ここから富田追記 2010年11月14日
提供データ拡充の検討を、再開しましょう。
決めて、一回出す。何ヶ月か出し続けて、その間に注文があれば、再検討ということでよいのでは。
▲ここで富田追記終わり。
▼ここから2SC1815J追記 2010年11月16日
賛成です。
現在のデータベースにない項目（ルビや注記を取り払ったときの文字数、底本のISBNなど）については、すぐに提供は難しいでしょうから、まずは現在提供可能な項目（上記の項目）で試験公開版として走り始めてみても良いと思います。
その際に、これは試験公開版であり項目は変更の可能性があること、追加項目の要望があれば検討に参加して欲しいことなどを明示すると良いのではないでしょうか。
青空文庫の注記記法は、すでに多くの利用システムがあり、改訂するのであればかなり慎重にならなければなりません。
しかし今回のCSVはまだ利用システムが一つも存在しない状態です。
完成品として利用するのではなく、一緒に作っていくものとして利用してもらえれば良いと思います。
また、Wikipediaがミラーリングやオフライン利用などのためにデータベースダンプを提供しているように、将来的には青空文庫でも全作品を圧縮して固めたものを提供してもらえると、第三者によるサービスや言語資源としての利用が広がると思います。
それは、今回の拡充書誌CSVと相補関係にあるものになるでしょう。
つまり、ある時点（年次とか月次とか）でのすべての登録作品が一つのファイルにまとめられた形でダウンロードでき、その全部入りファイルが作成されてから後に青空文庫に追加・更新された作品については、毎日提供される書誌CSVに記載された「テキスト／XHTMLファイル最終更新日」の情報を元に個別ダウンロードしてもらう。そうすることで、全作品をクローリングをすることなく、手元の作品群を最新の状態に保つことができます。
全部入りファイルは、書誌CSVの拡充よりも興味を持つ方が多いかもしれません。
そうした方々と更新頻度やサーバ負荷（ファイル容量と通信量）などについて検討することにして、まずは拡張CSVの提供から進めてはいかがでしょうか。
▲ここで2SC1815J追記終わり
▼実行に向けて富田追記 2010/11/21
次の形で、拡充版の提供を世話役に諮り、データベースの開発者に依頼しようと思います。
当初は暫定版とし、コメントを受けて仕様確定へと進めましょう。
世話役内の相談にも時間を要するし、データベース開発者が、いつ作業できそうかも、現時点ではわかりません。
そんなことなので、暫定版準備中のご意見も、お待ちします。（特に、これまで話に出ていなかった「文字集合」選択肢への、「Unicode」の追加について。）
・CSVファイル提示位置、名称
http://www.aozora.gr.jp/index_pages/person_all.html
の「→「公開中 作家別作品一覧：全て(CSV形式、 zip圧縮）」をダウンロード」の下。
「→「公開中 拡充版作家別作品一覧：全て（CSV形式、 zip圧縮）」として。
・公開の位置づけ
３ヶ月間を暫定運用期間とし、その間に寄せられた注文のうち、とるべきものはとって、仕様を固定する。
・提供データ項目
2SC1815Jさんによる、2010/11/09のリストに、以下の変更を加える。
「底本データ」の「種別フラグ」をトル：「底本」と「底本の親本」を分離。
生成元テーブル名に「底本の親本」を追加：項目名は「書籍名」「出版社名」「初版発行年」
ファイルデータ項目に「文字集合」を追加：ここがJIS X 0213であれば、JIS X 0208で包摂されているものを、表示段階で分離加工する必要はないが、0208であれば、分離加工することも考えられる、といった用途を想定して。
・データ項目に関する変更
この際、以下の変更を加える。
「仮名遣い種別」の名称を、「文字遣い種別」に変更する。
「文字遣い種別」の選択肢（「新字新仮名」「新字旧仮名」「旧字旧仮名」「その他」）に、「旧字新仮名」を追加する。）
「文字集合」の選択肢（「JIS X 0208」「JIS X 0213」）に、「Unicode」を追加する。←バージョンの違いには関わらず、単に「Unicode」としてはと思うが、良いか。）
▲ここで富田追記終わり
▼拡張CSV暫定版における項目の並び順 富田追記 2010/11/22
2SC1815Jさんの一覧をもとに、若干の変更を加えて、以下の項目名、配列順を想定してみました。
分類番号を、作品関連の項目が並んだところに移しました。
初出の出力順を、早めました。
行空きは、CSVには反映させません。
作品ID
作品名
作品名読み
ソート用読み
副題
副題読み
原題
初出 ← 出力順変更
分類番号 ← 出力順変更
文字遣い種別
作品著作権フラグ ← 項目名変更
公開日
最終更新日
人物ID
姓
名
姓読み
名読み
姓読みソート用
名読みソート用
姓ローマ字
名ローマ字
役割フラグ
生年月日
没年月日
人物著作権フラグ ← 項目名変更
底本名 ← 構成、項目名変更
底本出版社名 ← 構成、項目名変更
底本初版発行年 ← 構成、項目名変更
入力に使用した版
校正に使用した版
底本の親本名 ← 構成、項目名変更
底本の親本出版社名 ← 構成、項目名変更
底本の親本初版発行年 ← 構成、項目名変更
入力者
校正者
テキストファイルURL
テキストファイル最終更新日
テキストファイル符号化方式 ← 項目名変更（図書カードの表記にあわせて）
テキストファイル文字集合 ← 項目追加
テキストファイル修正回数
XHTMLファイルURL
XHTMLファイル最終更新日
XHTMLファイル符号化方式 ← 項目名変更（図書カードの表記にあわせて）
XHTMLファイル文字集合 ← 項目追加
XHTMLファイル修正回数
▲富田追記終わり
▼仕様検討に際してのメモ 富田 2010/11/22
・底本と底本の親本がそれぞれ複数あるケースへの対応
まれではあるが、複数の底本と底本の親本をもつ作品がある。（例えば、作品ID1704、みみずのたはことには底本が二つある。）最多でいくつになるのかは、確定できない。とりあえず、底本１、底本２、底本の親本１、底本の親本２を設け、その範囲で出力することで進める。（三つあれば、記載できないものがでる。）
※他の選択肢があれば、コメントをお願いします。
・初出の出力順
底本の親本の後においてはというコメントがあった。ただ、初出は作品の属性として決まるが、底本、底本の親本は決まらない。その点を考慮すれば、作品についての項目が並ぶ現在の位置で進めることも不適当ではないと考え、底本、底本の親本のそばに移すことは控える。
・テキスト版二つのケース
青空文庫開設当初は、ルビあり版からルビなし版を作っていた。その方針を変更し、ルビなしは作品にルビがない場合に限り、かつて両方作ったものについても、ファイル修正の機会に、ルビなしを削除するようにしてきた。だが、なお二つ関連づけたものが残っている可能性があるため、二つある場合はルビありを出力するよう、求める。
▲ここでメモ終わり
▼ここから2SC1815J追記 2010年11月22日
複数の底本と底本の親本をもつ作品ですが、該当する作品はどれくらいの数でしょうか。
元々複数のテーブルからなる現在のデータベースを一つのCSVで書き出すとした時点で、正規化の崩れが不可避に発生します。
上記に挙がっている項目でも、ファイルフォーマットごとの項目については、テキストファイルとXHTMLファイルの二つに絞ると折り合いを付けているものと思います。
もし、複数の底本を持つ作品が極めて少数なのであれば、底本1、底本2等とはせずに、上記の項目のまま（底本は一つだけ記載）にしてしまう手もあると思います。
ちなみに、「みみずのたはこと」 http://www.aozora.gr.jp/cards/000279/card1704.html については、現行のCSVでは
000279,"徳冨 健次郎",001704,"みみずのたはこと",新字新仮名,"","小林繁雄、奥村正明","小林繁雄",公開,2002-11-01,"みみずのたはこと（下）","岩波文庫、岩波書店","1996（平成8）年12月10日第25刷","2001（平成13）年11月7日第27刷"
000280,"徳冨 蘆花",001704,"みみずのたはこと",新字新仮名,"","小林繁雄、奥村正明","小林繁雄",公開,2002-11-01,"みみずのたはこと（下）","岩波文庫、岩波書店","1996（平成8）年12月10日第25刷","2001（平成13）年11月7日第27刷"
となっていて、底本は一つだけしか記載していませんね。
同様の正規化の崩れについては、入力者、校正者についても当てはまります。
入力者や校正者が複数というケースは存在し、また上限が何人であるとも決められません。
入力者や校正者が複数の場合、現行のCSVでは一つの項目のなかで「、」区切りで併記しています。
一つの項目のなかにそのような形式で複数の人物を記載するのがベストとは思いませんが（「藤岡弘、」のように名前に「、」が入っている人がいたら区切り目が分からないという問題もあります）、元々複数のテーブルからなる情報を一つのCSVで表現するという方式のなかでは、やむを得ないかなと思います。
書誌情報一覧をCSVではなくXML形式などで提供し、そうした問題をクリアすることも将来的にはあり得るのではないかと思いますが、現状でできることとしてCSVで出す以上は、ある程度の折り合いを付けることもやむを得ないのではないかと思いますがいかがでしょうか。
▲ここで2SC1815J追記終わり
▼ここから富田追記 2010年11月23日
複数の底本と底本の親本をもつ作品数は、把握できていません。
CSVで出す以上、どこかで割り振るしかないというのはおっしゃる通りで、底本、底本の親本、それぞれ１だけという選択もあって良いと思います。
暫定版は、１ではなく２で作ってはというのは、ぼんやり頭にある「複数のものはごく少数というわけではないよな」というイメージからの、直感です。
複数の入力者、校正者については、ご指摘の通り、既存のものの「、」で繋ぐ形の踏襲が良いと思います。
▲ここで富田追記終わり
▼作業状況に関する追記 富田 2010年11月27日
拡充CSVの暫定版は、12月末までの提供開始を目指して、準備を進めています。
現在は、仕様を渡して、データベースの開発者にみてもらっているところ。
データベースで直したい他の要素も、この際、一緒に片付けようということで、年末までのどこかに、作業予定を組み入れてもらうという話になりました。
▲ここで富田追記終わり
▼拡張版CSVの試作版 2010年12月31日
「拡張CSV暫定版における項目の並び順 富田追記 2010/11/22」にそって、ただし底本と底本の親本欄を、1、2の二つ用意したものを出力してみました。（list_person_all_extended.zip）
暫定版提供開始前の、アルファ版と位置づけてください。
・古いデータしか入っていない、テスト用の環境から出力したので、6541行分の古いデータしかありません。
・並び順は、人物の「姓読みソート用」＞「名読みソート用」＞作品名の「ソート用読み」で決まっています。（既存のlist_person_all.csvと変わりません。項目の並び順が違っているので、印象が異なると思いますが。）
・表計算ソフトで開くと、「生年月日」と「没年月日」で「-」と「.」がばらついて見えるかもしれません。エディターでみれば、「-」でそろっています。
・M列の「最終更新日」は、ファイルが差し替えられたタイミングに加え、書誌データが書き換えられた際にも、変わります。（個人的には、この項目は入らないかもしれないと思いました。）
▲富田追記終わり
▼ここから2SC1815J追記 2011年1月6日
http://www.aozora.gr.jp/index_pages/person_all.html に掲載されるようになった最新の作家別作品一覧拡充版 list_person_all_extended.csv を拝見しました。
・テキスト/XHTMLファイルURLについて
ファイル本体が外部サーバに置いてある作品（著作権存続等による）についてのファイルURL記載に不具合があります。
例えば、「ボヘミアの醜聞」 http://www.aozora.gr.jp/cards/000009/card226.html の場合、
拡張CSVファイルに記載されているテキストファイルの所在地は、
http://www.aozora.gr.jp/cards/000009/files/226_ruby.zip （著者によるレコード）、または、
http://www.aozora.gr.jp/cards/000010/files/226_ruby.zip （翻訳者によるレコード）となっていますが、
正しくは http://www.alz.jp/221b/holmes/scan.zip であり、前者2つのURLにはファイルは存在しません。
（XHTMLファイルURLについても同様です。）
また、ルビありとルビなしの両方のテキストファイルが提供されている場合には、現状はルビなしの方の情報が拡張CSVに記載されているようです。
例えば、「貧しき信徒」http://www.aozora.gr.jp/cards/000013/card542.html の場合、
テキストファイル(ルビあり) http://www.aozora.gr.jp/cards/000013/files/542_ruby.zip
テキストファイル(ルビなし) http://www.aozora.gr.jp/cards/000013/files/542_txt.zip
の両者が提供されていますが、拡張CSVファイルには後者（ルビなし）のURLが記載されています。
ルビありテキストからルビなしテキストを生成することは容易ですが、逆は困難であることを考えると、
書誌情報として指し示す先は、より多くの情報が含まれている「ルビあり」の方にしてはいかがでしょうか。
・複数の底本の項目出力順序について
現在は以下の順番になっていますが、
---
底本名1
底本出版社名1
底本初版発行年1
入力に使用した版1
校正に使用した版1
---
底本名2
底本出版社名2
底本初版発行年2
入力に使用した版2
校正に使用した版2
---
底本の親本名1
底本の親本出版社名1
底本の親本初版発行年1
---
底本の親本名2
底本の親本出版社名2
底本の親本初版発行年2
---
ブロックをまとめて
---
底本名1
底本出版社名1
底本初版発行年1
入力に使用した版1
校正に使用した版1
底本の親本名1
底本の親本出版社名1
底本の親本初版発行年1
---
底本名2
底本出版社名2
底本初版発行年2
入力に使用した版2
校正に使用した版2
底本の親本名2
底本の親本出版社名2
底本の親本初版発行年2
---
のようにしてはいかがでしょうか。
現状の出力順は、底本2を持たない作品の場合であっても、底本1に関する情報の記載が離ればなれになってしまいますが、
底本1（または底本2）に関する情報はそれぞれひとまとめにした方が扱いやすいのではないかと思います。
▲ここで2SC1815J追記終わり
▼ここから富田追記 2011年1月7日
SC1815Jさん、コメントありがとうございました。
皆さん、まず、以下の諸点に対処して、完了後、暫定公開を宣言ということではいかがでしょうか。
・XHTMLをXHTML/HTMLに変更
現在は、HTML版のデータが出力されない。
現在のXHTML版のみの扱いを、XHTML版もしくはHTML版に変更し、XHTML版があればXHTML版を、XHTML版がなくてHTML版があるときは、HTML版のデータを出力するように変更する。
なお、HTML版は基本的には、XHTML版に作り替えつつある。
・外部リンクしているもののファイルURL
外部にあるファイル（大半が著作権あり。一部、著作権なしのものもあり。）のURLが、「内部にあると仮定しての推定ロジック」で記載されている。
データベースの、テキスト版とXHTML/HTML版のURL欄にデータがある場合は、それをそのままCSVに出力する。
URL欄にデータがない場合、内部にあるとみるようにする。
例えば、富田倫生「パソコン創世記」。
CSVでの表示は、現在、以下のようになっている。
テキスト版：http://www.aozora.gr.jp/cards/000055/files/365_txt.zip
XHTML版：データベースには、HTML版の外部URLが記載されているので、現在は出力されていない。
データベースのURL欄には、次の様な外部URLデータがあるので、これをCSVに出力する。
テキスト版：http://attic.neophilia.co.jp/aozora/zipfiles/gopc.zip
HTML版：http://attic.neophilia.co.jp/aozora/htmlban/gopc.html
・ロジックで推定したところにファイルがないケース
著者とそれ以外の役割の人物（翻訳者、校訂者、編者、その他）が、共に関連づけられている作品がある。
例えば、著者、カフカ フランツの「変身」には、翻訳者の原田義人も関連づけられており、CSVでは、「カフカ」と「原田」の２行で出力される。
こうしたケースでは、ファイルは以下のように、著者側に配置されている。
テキスト版：http://www.aozora.gr.jp/cards/001235/files/49866_ruby_41853.zip
XHTML版：http://www.aozora.gr.jp/cards/001235/files/49866_41897.html
現在のCSVでは、訳者側で推定されたURLも表示されているが、そこにはファイルは存在しない。
原田 義人
http://www.aozora.gr.jp/cards/001396/files/49866_ruby_41853.zip
http://www.aozora.gr.jp/cards/001396/files/49866_41897.html
著者以外の役割の人物が関連づけられている作品には、必ず著者も立っている。（著者が特定できないものには、「作者不詳」という著者が関連づけてある。）
著者以外の人物の行には、同じ作品に関連づけられている著者の、テキスト版、XHTML/HTML版のURLを表示する。
・ルビありとルビなし
テキスト版に、ルビありとルビなしが登録されている以下のケースでは、現状のCSVではともに、ルビなしが出力されている。（必ずルビなしが出力されているかは、未確認。）
八木重吉「貧しき信徒」
CSV出力：http://www.aozora.gr.jp/cards/000013/files/542_txt.zip
佐々木味津三「旗本退屈男 01 第一話 旗本退屈男」
CSV出力：http://www.aozora.gr.jp/cards/000111/files/565_txt.zip
ルビありとルビなしがある場合は、ルビありを出力するようにする。
八木重吉「貧しき信徒」
ルビあり：http://www.aozora.gr.jp/cards/000013/files/542_ruby.zip
佐々木味津三「旗本退屈男 01 第一話 旗本退屈男」
ルビあり：http://www.aozora.gr.jp/cards/000111/files/565_ruby.zip
・底本／底本の親本の出力順変更
現在は、底本／底本の親本の関連項目は、以下の順で出力されている。
底本名1 底本出版社名1 底本初版発行年1 入力に使用した版1 校正に使用した版1 底本名2 底本出版社名2 底本初版発行年2 入力に使用した版2 校正に使用した版2 底本の親本名1 底本の親本出版社名1 底本の親本初版発行年1 底本の親本名2 底本の親本出版社名2 底本の親本初版発行年2
これを、以下の通り変更する。（底本1、底本の親本1、底本2、底本の親本2の順に。）
底本名1 底本出版社名1 底本初版発行年1 入力に使用した版1 校正に使用した版1 底本の親本名1 底本の親本出版社名1 底本の親本初版発行年1 底本名2 底本出版社名2 底本初版発行年2 入力に使用した版2 校正に使用した版2 底本の親本名2 底本の親本出版社名2 底本の親本初版発行年2
▲ここで富田追記終わり
▼ここから富田注記 2011年1月11日
上にリストアップした、拡充版CSVの問題点を直しました。
本日更新分から、対応済みです。
http://www.aozora.gr.jp/index_pages/person_all.html
1月13日付のそらもようで、暫定公開開始を告知するよう、準備します。
▲ここで富田追記終わり
▼ここから2SC1815J追記 2011年1月11日
修正版拝見いたしました。
twitterでも述べましたが、宝の山だと思います。
年月を経て蓄積されたデータであるが故に、表記に揺れがあるのはやむを得ないことと思いますが（特に初出や出版社名など、「こう書くべし」といった基準がないもの）、
ざっと見ていて、誤りらしいところがいくつかあったので、以下に挙げました。
作品ID
|
作品名
|
項目
|
値
|
コメント
|
1585
|
故郷
|
底本の親本初版発行年1
|
975（昭和50）年6月から1976（昭和51）年6月
|
975は1975
|
3825
|
槐
|
入力に使用した版1
|
11979（昭和54）年4月10日初版第11刷
|
11979は1979
|
51361
|
大利根の大物釣
|
底本の親本出版社名1
|
1906（明治39）年12月
|
底本の親本初版発行年1とテレコ
|
51361
|
大利根の大物釣
|
底本の親本初版発行年1
|
博文館
|
底本の親本出版社名1とテレコ
|
46483
|
悪因縁の怨
|
テキストファイル修正回数
|
1975
|
なにかの年が混入か
|
42856
|
花火
|
テキストファイル修正回数
|
1985
|
なにかの年が混入か
|
50273
|
政事と教育と分離すべし
|
テキストファイル修正回数
|
1985
|
なにかの年が混入か
|
このほか、底本初版発行年などで、
1916（大正5年）年9月11日 「年」が重複
1989年（平成元）年 「年」が重複
1953年（昭和28）年9月15日 「年」が重複
1988（昭和63）年6月30日 全角空白が先頭に入っている
1980(昭和55)年8月20日 丸括弧が半角
などがあったり、出版社名で
新潮文庫、新潮社
新潮文庫・新潮社
新潮社、新潮文庫
（同じ内容で3通りの記載がある）
岩波書店 岩波文庫
岩波書店、岩波文庫
岩波文庫 、岩波書店
岩波文庫、岩波書店
などがあったりして、できれば統一した方が良いとは思いますが、ここに挙げると煩雑なので省略しました。
拡充書誌情報CSVの実データを拝見すると、欲が出てきて、データクレンジングを行って、より品質の高い書誌情報になったらいいなと感じます。
CSVを見た側がそうした箇所を指摘することはできますが、データの修正作業は青空文庫の内部の方々に行っていただかなければならないので、
そのことにそこまでリソースを割けないという問題が出てくるかもしれません。
メタデータ（書誌情報）を修正するよりも、本文の誤植を修正する方や新しい作品を公開する方を優先したいというお考えもあるかもしれませんし。
（今後、CSVを見た人が「ここはおかしい」と気付いたときの連絡窓口と、そのお知らせを受けてどこまで修正する／できるかという問題。）
・初出情報の記載方法ガイドライン
初出情報については、初出掲載資料名と年代が別項目になっていると年代による並べ替えや抽出が容易になり、活用の幅が広がります。
しかし、初出にもさまざまなパターンがあるので（連載や飛び飛びなど）、単純にCSVの上で「初出掲載資料名」「初出年代」の2項目に分離はできないでしょう。
（「初出掲載資料名1」「初出年代1」「初出掲載資料名2」「初出年代2」……といった、例の正規化の問題。）
一項目に記載するままであっても、それが一定の形式（項目の順序や区切り文字）に従って記載されていれば情報抽出は楽になると思います。
そうした「青空文庫における初出情報記載書式のガイドライン」といったものはありますか。
・図書カードURL
CSVを見ていると、「この作品の図書カードを確認したい」ということが多く、図書カードのURLがCSVには載っていない（作品IDと人物IDから組み立てなければならない）ことがやや気になりました。
CSVに記載されている情報から組み立てられるという点では、図書カードURLをCSVに記載することは冗長とも言えます。
しかし、そうやってCSVの情報から図書カードのURLを得るには、URLが作品IDと人物IDから組み立てられるという外部知識と、実際に組み立てる作業が要求されます。
外部知識なしにこのCSVを見た場合や、このCSVを取り込んで項目を表示するだけといった利用のされ方では、図書カードへの道筋が表示できないことになります。
拡張CSVだけで図書カードを網羅する内容を表現できていれば、図書カードへの道筋は不要かもしれませんが、実際にはそこまで山盛りの内容ではありません。
例えば、CSVでテキストファイルURLにもXHTML/HTMLファイルURLにも記載がないとき、なんのフォーマットなら提供されているのかを確認するには、やはり図書カードのURLが必要です。
ただでさえ項目が多くデータサイズが大きくなっているので、賛否あるかもしれませんが、図書カードURLの項目をCSVに追加してはいかがでしょうか。
▲ここで2SC1815J追記終わり
▼暫定公開版で確認できた問題点 お気づきの点、書き込んでください。
・図書カードのURL出力を望む意見がある。 2011/1/14 富田
下のバグ修正にあわせて、図書カードURLの出力を追加しようと思います。
M列に表示されている「最終更新日」と、N列の「人物ID」の間に、「図書カードURL」として加えるつもりです。 2011/1/17 富田
図書カードURLを追加しました。2011/1/26 富田
http://www.aozora.gr.jp/soramoyou/soramoyouindex.html#000373
・テキスト版なし、HTML版ありで、テキスト版の欄にHTML版が出力されている。 2011/1/14 富田
536 賢者の贈り物 けんじゃのおくりもの けんしやのおくりもの The Gift of Magi 新字新仮名 あり 1999.12.9 2009.2.26 97 オー・ヘンリー オー・ヘンリー おおへんりい O. Henry 著者 1862-09-11 1910.6.5 なし 結城浩 http://www.hyuki.com/trans/magi.html 1999.12.9 ShiftJIS JIS X 0208 0
532 最後の一枚の葉 さいごのいちまいのは さいこのいちまいのは The Last Leaf 新字新仮名 あり 2000.1.11 97 オー・ヘンリー オー・ヘンリー おおへんりい O. Henry 著者 1862-09-11 1910.6.5 なし 結城浩 http://www.hyuki.com/trans/leaf.html 2000.1.11 ShiftJIS JIS X 0208 0
テキスト版がなくて、XHTML/HTML版があるものすべてで、この問題が発生していました。
修正してもらいます。 2011/1/17 富田
修正しました。 2011/1/26 富田
・データサイズが大きすぎるため、日次での差分データ提供を望む意見がある。 2011/01/24 2SC1815J（要望者の代理で記入）
・NDC番号の出力を望む意見がある。 2011/01/26 2SC1815J（要望者の代理で記入）
▲問題点ここまで
▼ここから2SC1815J追記 2011年1月28日
(1)
http://twitter.com/aobeka/status/30462089092923392
青空文庫データベースと公開サイトの文字コードはEUCで、JIS X 0213の文字も扱えます。これまでは、ファイルに合わせて http://tinyurl.com/46lvb9u のように外字注記してきましたが、ここは「癋」ともできます。 #aozorabunko
(2)
http://twitter.com/aobeka/status/30462412226297856
青空文庫のCSVは、シフトJISで出しています。JIS X 0213の文字は、10進数の文字数値参照で出力されます。「ぼく東綺譚」の元データを外字注記から「濹」に変えると、CSVでは「＆#28665;」に。こうされると、困りますか？ #aozorabunko
(3)
http://twitter.com/aobeka/status/30894107165458432
2種類のCSVをSJISで出してきました。拡充版もそうしたのは、前例のなぞり。0213の文字は、現状では3種類で文字数値参照になります。今のままか、グリフが見えるように変えてそろえるか。2種類今のまま、拡充だけ変えるか。 @gridsurfer #aozorabunko
すみません、140文字の限られたなかでは(3)の御説明が良く理解できませんでしたので、確認のため整理させてください。
本文以外の書誌項目（著者名等）について、作品ファイル本体以外で表示される場所は、
- 図書カード/作家リスト/作品リストのHTML
- 既存CSV
- 拡充CSV
の3つだと思います。
上記引用の(1)～(3)は、以下のように考えて良いでしょうか。
(1) 現状では、JIS X 0208外の文字は、データベース上、外字注記の形で保存されており、1.～3.すべてで外字注記の形で表示されている。
(2) これに対して、データベース上でもJIS X 0208の文字と同様にJIS X 0213の範囲まで記載するようにした場合を想定してみると、どのような影響があるか。
(3) データベース上の表記を変更した場合、上記1.～3.すべて現在のままにするか、すべて変更するか、3.だけ変更するか、どれが良いだろうか。
1.のHTMLと2.の既存CSVについては、変更で困るか困らないかは利用側の実装次第です。
1.については、HTMLをスクレイピングして情報を取得しているプログラムの提供者、
2.については、既に利用されている豊平文庫さんのご意見を伺ってみたいところです。
3.の拡充CSVについては、第一印象としては、Shift_JISのCSVの中で一部分だけUnicodeのコードポイントを数値文字参照で記載するくらいなら、
CSV全体をUnicodeで出力してくれた方が利用しやすいと思います。
しかしながら、その場合、次の懸案点があります。
・Unicodeファイルにもかかわらず、UnicodeにはあってJIS X 0213にはない文字については外字注記のままである（文字コードと内容の不整合）。
・少し古いExcelで開くと文字化けしてしまう。
・ファイルサイズが大きくなってしまう。
これらを考えると、もし3.を変更するのであれば、常識的に考えれば筋が悪い、「Shift_JISのCSVの中で一部分だけUnicodeのコードポイントを数値文字参照で記載」という方法もありなのかなと思います。
そもそも3.を変更した方が良いのかという点については、外字注記は外字注記で、人間がCSVファイルを見たときにどのような文字か想像が付くメリットがあり、
数値文字参照になってしまうと、CSVをそのまま見た人間にはどのような文字か全く分からなくなるというデメリットがあるので、どうでしょうね。
拡充CSVは主に機械処理向けと考えると、処理側が数値文字参照をきちんと文字に置き換えてくれるのであれば数値文字参照に変更した方が良いし、
特別な処理をしてくれず、そのまま表示されるのであれば外字注記のままの方が良いと思うので、数値文字参照に変更するのであれば、
適切な処理を行ってもらえるようアナウンスとお願いが必要かなと思います。
▲ここで2SC1815J追記終わり
▼ここから富田追記 2011年1月30日
上記引用の(1)〜(3)は、以下のように考えて良いでしょうか。（2SC1815Jさん）
はい。
今回の話の出発点は、公開サイトの外字注記の煩わしさです。
これまでは、サイトに表示される書誌データは、JIS X 0208の文字だけで書いてきました。
まもなく、永井荷風「濹東綺譚」を公開します。
成島柳北に取り組んでいただいていますが、成島の号の「濹上漁史」でも、データベースに人物登録することになりました。
では、これらの「濹」はやはり、これまでどおり「※［＃「さんずい＋（壥－土へん－厂）」、第3水準1-87-25］」なのかと。
書誌情報については、基本はこれまで通り、JIS X 0208の包摂規準にしたがってとるのだけれど、0213にある「外字」には、コードであてることも考えられそう。作業量としても、それなら問題なく処理できる。
ただ、そう変更した場合はCSV絡みでの判断が求められるとなりました。
公開サイトでの「大きな」みやすさをとって外字注記を廃止すると、今のままのCSVには数値文字参照が混じって、そこに「小さな」みにくさが生じる。
ではと、CSVのエンコーディングを変更すると、多くの人はExcelで開くのだろうから、文字化けが生じる可能性が高い。（私はMacでExcel 2008を使っていて、ここでは化けます。もっと新しいバージョンなら問題ないのか、知らないのですが。）「やや大きめ」の戸惑い、みにくさが生じるだろう。
ではどうするか。
どうもすっきりはいかないのだけれど、「大」の見やすさをとって、0213の文字も使うようにする。
CSVの文字化け確率を下げるために、Shift_JISは維持だろうか。
そうすると、CSV内に数値文字参照というみにくさが生じるのだけれど、それは「受け入れ可能でしょうか？」というのが問いかけの意図です。
0213にもない文字の問題は確かにありますが、今のところ、実データで対象になるものはありません。「ほとんど大丈夫」という感じ。
データベース、公開サイトをUnicodeに変更するのは、一仕事になりそうですというコメントを、開発者から得ています。
▲ここで富田追記終わり。
▼ここから2SC1815J追記 2011年1月31日
詳しい御説明、ありがとうございました。
「濹東綺譚」の公開が近付いているのですね！
最近は青空文庫対応アプリを利用しての閲覧も増えているとは思いますが、Webブラウザを使って青空文庫にアクセスしている方も多いのが現状でしょう。
となると、おっしゃるとおり、図書カード/作家リスト/作品リストのページに表示される内容が見やすくなるメリットは大きいと思います。
(2) データベース上、書誌情報についてJIS X 0208の文字と同様にJIS X 0213の範囲まで記載するように変更
確認ですが、上記(2)の場合であって、CSVファイルはこれまでどおり外字注記のままという選択肢は（現実的には）ないのですよね。
前回も述べましたが、既存のCSVについては、既に利用している方（豊平文庫さんなど？）がいらっしゃるので、変更なしが望ましいとは思います。
しかし、特に反対のご意見がないようであれば、上記(2)を行った場合、
・多くの利用者が目にする図書カード/作家リスト/作品リストのページが大きく見やすくなること
・CSVはこれまでよりは見にくくなるが、CSVを既に利用しているプログラム側で数値文字参照を置換する改修作業も容易であること
から、あくまでも個人的な意見としては、Shift_JISのCSVの中に数値文字参照が混じるのは「受け入れ可能」な変更かなと思います。
▲ここで2SC1815J追記終わり
▼ここから富田追記 2011年2月9日
(2) データベース上、書誌情報についてJIS X 0208の文字と同様にJIS X 0213の範囲まで記載するように変更
確認ですが、上記(2)の場合であって、CSVファイルはこれまでどおり外字注記のままという選択肢は（現実的には）ないのですよね。（2SC1815Jさん）
はい、現実的には。
(2)を、試験的に実施してみます。
3月15日までを拡充版CSVの暫定公開期間としているので、そこにもう一つ実験を追加するという位置づけで。
実験対象範囲は、人名と作品名とします。（底本データでも、ローマ数字等の置き換え可能なものがたくさんありますが、そこまでいっぺんにやって、やはり都合が悪いので戻そうということになったとき、作業が大変になるので。）
データの変更を終えました。
明日のそらもようで、告知します。
この変更で不都合があれば、reception@aozora.gr.jp、掲示板、#aozorabunkoなどで声をかけてください。
▲ここで富田追記終わり。
▼使用文字の拡張で生じた事態と対処 富田 2011年2月11日
リスト、図書カードに使用する文字をJIS X 0208外に拡張したところ、CSVに予想していなかった構造の乱れが生じ、青空文庫ファイルの表示機能を持つソフトに、悪影響がでました。
【2011年2月10日】
・これまで外字注記してきた、JIS X 0208以外の文字を用いました。
・公開サイトのリスト、図書カードは期待通りに表示され、機能にも問題はありませんでした。
・書誌CSVに、予想していなかった問題が生じました。ローマ数字と、「燁」（※［＃「火へん＋華」、第3水準1-87-62］）からむところで、セルの区切りを示す「,」の消失を含む文字化けが生じ、CSVの構造が乱れました。
・CSVを利用していると思われる青空文庫ビュワーで、リストの文字化けや、リンクの機能不全が生じました。
・問題を解消するために、元データで、ローマ数字と「燁」（※［＃「火へん＋華」、第3水準1-87-62］）を、外字注記に戻しました。
【2011年2月11日】
・CSVの構造の乱れがおさまりました。
・前日に生じていた、青空文庫ビュワーの問題が、解消しました。
・JIS X 0208外の文字については、ローマ数字と、「燁」（※［＃「火へん＋華」、第3水準1-87-62］）が、外字注記されています。それ以外は、数値文字参照となっています。
【乱れの実態】
元データの「映画雑感（Ⅰ）」が、list_person_all.csvで以下のように化け、当該のセルの区切りを示す「,」が消失しました。
42 寺田 寅彦 43278 映画雑感（∮,新字新仮名,",Nana ohbe" 浅原庸子 公開 2005.1.8 寺田寅彦全集 第八巻 岩波書店 1997（平成9）年7月7日
にもかかわらず、list_inp_person_all.csvでは、「映画雑感（Ⅶ）」（のつもりのもの）が、構造の乱れなしに、予想通りの数値文字参照で、「映画雑感（Ⅻ）」の形で出力されていました。
42 寺田 寅彦 46437 映画雑感（Ⅻ） 新字新仮名 Cyobirin 入力中 2006.6.13 寺田寅彦全集 第8巻 岩波書店 1997(平成9)年7月7日
この差がどこからくるのか、現状では把握できていません。
なお、「Ⅻ」は「Ⅶ」ではなく、「Ⅻ」です。単純な書き間違えなのか否かは、確認できていません。
▲ここまで
▼ここから2SC1815J追記 2011年2月12日
よくある文字化けなので、システム開発者の方に修正を依頼してはいかがでしょうか。
・公開サイトのリスト、図書カードは期待通りに表示され、機能にも問題はありませんでした。（富田さん）
実際には、図書カード(EUC-JP)でも期待される動作とは異なる表示が生じていました（2月10日に確認）。
例えば、寺田寅彦「映画雑感（Ⅰ）」の図書カードについては、
http://www.aozora.gr.jp/cards/000042/card2467.html
「Ⅰ」の部分が0xFFFDになって化けていました（映画雑感（Ⅱ）以降も同じ）。
これは、文字コード変換に失敗した場合の代替文字(Unicode)です。
http://www.unicodemap.org/details/0xFFFD/index.html
また、長谷川時雨「柳原燁子（白蓮）」の図書カードについては、
http://www.aozora.gr.jp/cards/000726/card45988.html
「燁」はJIS X 0208外字なので数値文字参照で出力されることが期待されますが、実際には文字として出力されていました。
青空文庫のシステムの具体的な構成と今回の作業内容を知らないので、はっきりしたことは言えませんが、
- データベースの更新作業時（外字注記から該当文字へ変換したとき）
- データベースへの入力時（入力時の文字コードからデータベースの文字コード(eucJP-ms)への変換時）
- データベースからの出力時（データベースの文字コード(eucJP-ms)からEUC-JP/Shift_JISへの変換時）
のいずれか（もしくは複合）で、NEC特殊文字やIBM拡張文字のマッピングが適切に行われていないのではないでしょうか。
図書カードでも文字化けが起きていたので、1./2.の段階で既に怪しい気もします。
ところで、図書カードに数値文字参照で出力された場合、人間が見るには良いですが、検索エンジンは拾ってくれるのだろうかと疑問に思いました。
図書カードで「濹東綺譚」が「濹東綺譚」と表記されているとき、「濹東綺譚」で検索してそのページがヒットしないとすれば残念です。
図書カードだけでもUnicode化してしまえば、その問題は解決できます。更新した図書カードだけ順次Unicode化していくのであれば、それほど作業上のネックはないような気がしますが、いかがでしょうか。
▲ここで2SC1815J追記終わり
Comments (0)
You don't have permission to comment on this page.