實松アウトプット

iwnidAPI利用 統計データ集

iwnidAPIを利用した統計データ集です。
全体のデータと自動収集データの月別・週別推移を表示します。

statistics.phps

iwnidAPI利用 20件毎表示

iwnidAPIを利用した20件毎表示の暫定版です。大体の雰囲気はこんな感じで使ってみてください。

separate20.phps

iwnidAPI スレッドデータをXMLで返す

概要

iwnidで取得した中から指定したスレッドのデータをXML形式で返します。

リクエストの形式

http://example.com/boardName/xml に対して以下のパラメータをGETリクエストで送信することで、XML形式でスレッドのデータを取得することが出来ます。

all
全てのスレッドデータを取得します。all以外のパラメータはname=valueで指定しますが、allはallのみで指定します。また、allは他にパラメータがある場合、省略が可能です。

live
liveなスレッド限定でスレッドデータを取得するならtrue、liveではないスレッド限定で取得するならfalseを指定します。何も指定しなければ両方を取得します。

start
スレッドデータの選択範囲の開始日時を八桁の整数で指定します。はじめの四桁が年、次の二桁が月、最後の二桁が日になります。それぞれ0以上の整数である程度柔軟に解釈します。
　ex.20070331,20070400,20061531は全て2007年3月31日を指します。

end
スレッドデータの選択範囲の終了日時を八桁の整数で指定します。はじめの四桁が年、次の二桁が月、最後の二桁が日になります。それぞれ0以上の整数である程度柔軟に解釈します。
ex.20070331,20070400,20061531は全て2007年3月31日を指します。

time
開始日時・終了日時をスレ立て時刻で得るならstart、最終確認時刻で得るならconfirmを指定します。指定がない場合のデフォルトはstartです。

limit
一度に取得したいスレッドデータ件数を整数で指定します。指定がない場合は全件取得です。

offset
オフセット値を整数で指定します。オフセット値の指定にはlimitの指定が必須です。オフセット指定がない場合のデフォルトは0です。

order
スレッドデータを昇順ソートする場合はasc、降順ソートする場合はdescを指定します。指定がない場合のデフォルトはascです。

mode
自動収集データのみを取得するにはauto、手動データのみを取得するにはhandを指定します。指定がない場合は両方を取得します。

XMLデータの構造

返り値として得られるXMLデータは以下のような構造になっています。

mainURL
基準ページのURLです。

mainTitle
基準ページのタイトルです。

editor
編集著作権者です。

subject
subject.txtの相対位置です。

lastModTime
最終巡回時刻です。

allThreadCount
保持しているスレッド総数です。

threads
個々のスレッドデータをthread要素に持ちます。

threadの子要素

startTime
RFC2822形式のスレ立て時刻です。

lastConfirmTime
RFC2822形式のスレッド最終確認時刻です。

mode
自動収集の場合auto、手動の場合handです。

title
スレッドタイトルです。

live
liveなスレッドの場合true、livrではないスレッドの場合falseです。

resCount
レス数です。

readURL
スレッドを読む場合の相対位置です。

datURL
datの相対位置です。

originalURL
元スレッドのURLです。

iwnidAPI使用条件

個々のスレッドタイトル及びそれに付随する情報の著作権は２ちゃんねる及びスレ立て人に帰属します。iwnidが収集したスレッドの編集著作権は私(sanemat)に帰属します。

sanematに帰属する著作権の範囲では、クリエイティブ・コモンズ 表示 2.1 日本 ライセンス の下でライセンスします。最小限の表示は'Powered by iwnid, sanemat'のテキスト、それ以上は好きにしてください。また、2ちゃんねるのデータの利用に関しては
２ちゃんねる
http://www.2ch.net/
を参照してください。

iwnidAPI使用制限

現在、呼び出し回数及び転送量に制限はありません。試行錯誤歓迎です。ただしこれは将来にわたって無制限を保障するものではありません。特に、呼び出し側で適度にキャッシュしてもらえると助かります。

リクエストの例

liveな最新1スレを取得する
http://example.com/boardName/xml?limit=1&order=desc&live=true

返り値として得られるデータは以下のようになります。

<?xml version="1.0" encoding="Shift_JIS" ?>
<iwnid>
  <mainURL>http://example.com/boardName/</mainURL>
  <mainTitle>＠iwnid</mainTitle>
  <editor>sanemat</editor>
  <subject>subject.txt</subject>
  <lastModTime>Sun, 17 Jun 2007 01:14:22 +0900</lastModTime>
  <allThreadCount>1252</allThreadCount>
  <threads>
    <thread>
      <startTime>Sun, 17 Jun 2007 00:42:23 +0900</startTime>
      <lastConfirmTime>Sun, 17 Jun 2007 01:14:15 +0900</lastConfirmTime>
      <mode>auto</mode>
      <title><![CDATA[【野球】ドン底阪神の景気づけプラン　そらそうよドリンク作る ]]></title>
      <live>true</live>
      <resCount>2</resCount>
      <readURL>nonyu.php/1182008543/</readURL>
      <datURL>dat/1182008543.dat</datURL>
      <originalURL>http://news21.2ch.net/test/read.cgi/mnewsplus/1182008543/</originalURL>
    </thread>
  </threads>
</iwnid>

読んだだけでは何がなんだかよくわからないと思います。ですので、xml?allとかxml?live=true&order=desc&limit=10とかxml?start=20070501とかそんな感じでいろいろやってみてください。

iwnid b0.2.4

[新機能] API機能(REST)をつけました。

iwnidでログ収集をしていると、index.htmlはどんどん肥大化していきます。この点、表示部分をカスタマイズしてpager等で分割表示することは現状でも可能です。でもどうせなら、ということでindex.htmlに加えてデータをSQLiteに書き出し、さらにそれをAPI(REST)で呼び出すことが出来るようにしました。

GETでリクエストするとデータがXMLで帰ってくる、というあれです。これにより誰でもデータを引っ張り出して好きなように組み立てることが出来ます。

携帯用の省スペース版、直近10スレッド、スレッド表示を月別に、新着をRSSフィードとして配信、週毎のスレッド数統計、今liveなスレッド一覧、スレ立て時間帯でスレッドを分類、などなどアイデア次第でパターンは無限大です。逆に言えば必要な人は自分でデータをカスタマイズしてね、ということです。

詳しい使い方・私のところでの使用条件は改めて別エントリに書き出します。

専用ブラウザから"ブラウザで開く"類を設定

専用ブラウザから"ブラウザで開く"類のアクセスに404を返したままでした。

http://example.com/test/read.cgi/boardName/threadKey/option を http://example.com/boardName/nonyu.php/threadKey/option にリダイレクトするように設定しました。

ドメイン直下の.htaccessでRewriteEngine Onにするのは嫌だったので、testディレクトリを作りその中の.htaccessで

--
RewriteEngine On
RewriteBase /
RewriteRule ^read\.cgi/([^/]*)/(.*) $1/nonyu.php/$2 [R,L]
--

としました。

iwnid b0.2.3

[新機能] NGワード機能をつけました。

手動で消していく運用は取りこぼしを極力減らすことが出来ます。しかしdat落ち周期の長い板が混じっていた場合、消すまでのタイムラグが長くなってしまいます。 ですのでNGワード機能をつけました。長めのNGワードをアドホックに追加することで取りこぼしを少なくすることが可能です。除外検索の実装はまたいつか…

datのcrawlerを共用鯖に置く非

利　「設置が容易」「コストが安価」
非　「共用鯖ではスクリプトに強制時間制限があることが多い」「共用鯖からの複数アクセスは相手にとって区別が付かない」「IPが変わらない」

自己中心で考えていくとこれ以上ない利なわけですが、使い方によっては各所に迷惑を掛けてしまいます。以下その非について触れます。
ちなみにここでは共用鯖、専用鯖、グローバルIPが割り当てられてる鯖(専用鯖、自宅鯖)ぐらいに分けて考えています。

クローラはクロールされる側から見れば、比較的短時間に同じIPから繰り返し呼び出す対象です。このとき、独自ドメインを取っていようと同じサーバの別のアカウントだろうと、同じIPからのアクセスは同一の相手からのアクセスにしか見えません。もちろんUserAgentやリファラ等で区別することが可能な場合もありますが、「どこからのアクセス」を見る際にそんなところはチェック対象にしないので大差はないです。これはアクセスに対してIPで対応しようがホストを引こうが同じことです。

要するに、自分が節度を持ってアクセスしていても同じIPから（同じサーバじゃなくても）無茶するやつがいればまとめて規制を受けます。逆もまた然りです。

次に、共用鯖のスクリプトは大量のアクセス・重い処理を一気に処理することは想定していても、ぽつぽつと定期的に（数秒〜数十秒間隔）軽い処理をすることは想定していません。だいたいどのサーバでも10秒から30秒程度で強制的にストップされてしまいます。settimelimit等の設定しだいですが、これを弄れないサーバも多いです。

制限時間内に巡回を終えなければ、という方向にばかり意識が向かってしまうと、毎秒n回の連打アクセスなんてことになってしまいます。

そして、こと2chそれも読み込みに限った規制の話をします。とかげの尻尾切り、バーボンハウス、海外規制、htaccessで手動、知っているのはこれぐらいです。2chwikiを見れば大体のことは把握できます。それ以上詳しい情報は各自調べてください。
２ちゃんねるWiki - いきいき Wiki ( http://info.2ch.net/wiki/ )

一番食らいやすいのはとかげの尻尾切り規制です。これは、K秒・分単位に、L回アクセスがあった場合、M時間アクセスできなくなる、ものです。これに引っかかると規制リスト入りしてバーボンハウスとなります。巡回プログラムをパラメータ調整しながら作っていたときに私も実際に何度か食らいました。これは回線切ってIP変えられる場合は簡単に対応できます。自分が繋いでいたIPを割り当てられた人はドンマイですが。しかし、固定IPの場合そうも行きません。ただしこの規制は、ほっとくと直ります。

連続書き込み、クローラで地引、なんて場合に引っかかるのがバーボンハウス規制です。トカゲの尻尾きり→規制リスト入りでバーボンハウスの場合は前述の通りほっとけば直ります。しかし、それ以外のルートでバーボンハウスの場合はほっといても直りません。クロール専用鯖( http://liveb1.2ch.net/ )が用意されている場合、そこは地引いてもバーボンハウスにはならないそうです。しかし、クロール鯖が用意されていない板も多々あるのでその場合は気を付ける必要があります。

海外規制は書き込みのみ規制、読み込みも規制を含めて何段階もありそうです。ここは推測にすぎません。具体的には、海外無料鯖からつないだ時に2chから接続を拒否されるものがありました。個別に規制されていたのか、IPで包括的に規制されているのか、その辺がわかる術は私にありません。

最後に手動規制。以前自分が悪さをしたり、あるいはそのIPから誰かが悪さをした場合、手動で永久規制になっているものがあります。その場合解除の見込みはほぼ無いです。

以上の規制はブラックリスト型ですが、逆にホワイトリストも存在します。みみずん、肉ちゃんねる、p2.2ch.netクラスになるとそっちに入れてもらえるらしいですが、そこまではなかなか。

「共用鯖ではスクリプトに強制時間制限があることが多い」「共用鯖からの複数アクセスは相手にとって区別が付かない」「IPが変わらない」

これらの理由から共用鯖にcrawlerを置くことは非なのです。回線負荷、ハードウェア負荷が小さくても、です。

2chのp2スレのテンプレ「※レンタル鯖にp2設置は2ch運営とp2ユーザーに迷惑なのでやめましょう。 」はこの辺も含めて言ってるんだと思います。

でもさあ、グローバルIPもらえる専用鯖や自宅鯖って技術的にも金銭的にもハードル高い…

iwnid b0.2.2

[バグ修正] datから取得する情報を無害化しました。

スレッドタイトルの出力前にstrip_tagsしました。
これ↓が解決しました。

實松アウトプット: iwnidがスレッドタイトルをそのまま表示する件

更新トリガに使っている各種RSSリーダ・アンテナのIP・UA

　Bloglines
HTTP_REFERER:
HTTP_USER_AGENT:Bloglines/3.1 (http://www.bloglines.com; 1 subscriber)
REMOTE_ADDR:65.214.44.29
gethostbyaddr:crawler.bloglines.com
メモ：巡回間隔は約1時間

google reader
HTTP_REFERER:
HTTP_USER_AGENT:Feedfetcher-Google;
(+http://www.google.com/feedfetcher.html; 1 subscribers;
feed-id=2780404538756860077)
REMOTE_ADDR:72.14.199.15
gethostbyaddr:72.14.199.15
メモ：巡回間隔は約3時間

livedoor reader
HTTP_REFERER:
HTTP_USER_AGENT:livedoor FeedFetcher/0.01
(http://reader.livedoor.com/; 1 subscriber)
REMOTE_ADDR:203.104.98.220
gethostbyaddr:5a-m02-d5.data-hotel.net
メモ：巡回間隔は約5時間

はてなアンテナ
HTTP_REFERER:
HTTP_USER_AGENT:Hatena Antenna/0.5 (http://a.hatena.ne.jp/help)
REMOTE_ADDR:222.149.234.136
gethostbyaddr:p3136-ipbf615marunouchi.tokyo.ocn.ne.jp
メモ：巡回間隔は約5時間　HEAD→GETと取得が丁寧

WEBCRON
HTTP_REFERER:
HTTP_USER_AGENT:WEBCRON ENGINE II - v1.0.1
REMOTE_ADDR:62.193.231.80
gethostbyaddr:wpc1810.amenworld.com
メモ：最短の巡回間隔は1時間　設定次第　巡回にムラあり

iwnid b0.2.1

[バグ修正] 更新用のフィードが更新無かった時304を返さなくなっていたバグを修正しました。

ヘッダ出力の前にrequireされてるファイルがexit吐いてて、それが悪さをしていました。returnに変えてバグを修正。

iwnid b0.2.0

[新機能] 複数板の巡回に暫定対応しました。

但しスレッドキーの衝突チェックはしていないため、スレッドキー衝突の際には不具合が発生します。

単一板対応だったものをforeachでグルグル回せるようにしました。 2chでは単一板の場合に同時にスレッドが立てられてもスレッドキーが重ならないようにbbs.cgiで調整されています。しかし、複数板の場合にそのような調整はありません。スレッドキーが衝突しないようにこちら側で調整する必要があります。この場合ファイル名をオリジナルのスレッドキーから変えてしまえば何とかなる気もしますが、いろいろ副次的な調整も必要になってしまいます。スレッドキーをオリジナルのスレッドキーとして保持することを最優先にするため、スレッドキー衝突を防ぐ仕組みは実装していません。

[新機能] ログの項目を増やしました。ログは上位互換になります。これに伴いindexhtmlやsubjecttxtを作成するためのスレッドタイトルは、datではなくログの項目から読み取る方式に変更しました。

ログは1バイトにしたかったので今までスレッドタイトルを入れていませんでした。しかし毎回全部のdatを読み込んでというのは激しく無駄なのでログをShiftJISにしてスレッドタイトルを収納することにしました。

[修正] マッチングの前に正規化を入れました。

半角カタカナは正規表現で引っ掛けるのが難しいです。どう正規化するのかは設定ファイルで決めます。

[修正] その他全体を書き直しました。

ベタ書きしか出来ないので設定を変えようとすると全体的に書き換える必要が…

0.1.2 -> 0.2.0で増えたバグ

更新用のfeedは更新が無かったときに304を返すはずなのに200かつ空っぽなものを返してしまう。headerの前に何か出力しちゃってるぽい。でも見つけられず。

既知のバグ

あぼーんが簡易判定なので、あぼーん後にファイルサイズが小さくなっていないとあぼーんが検出できず、ログがぐちゃぐちゃに。差分は1バイト前から取得して始めが\nなら〜って方法に変えたほうがいいかもしれません。

ShiftJISの正規表現よくわかんね

$searchsの配列に検索語を入れて、それをimplodeで|で繋いでpreg_matchしているけれどエラーが出ました。一つ一つコメントアウトして問題の検索語を調べたところ

$searchs[] = "ち(　)*?ー";

↑これでした。 xdebugのエラーメッセージは
Warning: preg_match() [function.preg-match]: Compilation failed: missing terminating ] for character class at offset 92
これ。 "ー"の2バイト目が"["なのでそれで誤動作してるっぽいです。どう直していいのかわかんね。とりあえず外して動作中。

iwnidがスレッドタイトルをそのまま表示する件

index.htmlやsubject.txt出力の際に2chや互換板を完全に信頼して流し込まれたスレッドのタイトルをそのまま表示している。これに変なコードを流し込まれたらまずい。たまたま出力がhtmlだったからまだましだけど、phpだったらやばかったなあ。早いうちに改修する必要アリ。

サニタイズすればいいのかな。
文字コードが違ったりした場合、タグに表示されてしまうものを流し込まれるなんて脆弱性もあったはず。いまいちわからないので情報集めないと。

手動でliveなdatを追加する仕組みを作ろう

手動でliveなdatを追加する仕組みを作ろう。

手動で古いdat（もちろん古くなくてもいいんだけれど）を追加する仕組みははじめに作ったけれど、手動で巡回対象に組み込む仕組みはなかった。一度datを取得に行く仕組みを作ってしまえば、以前つけた「前回liveだったスレをsubject.txtにかかわらず取得する」機能が副産物として活きて継続的に取得が出来るはず。

まだ未実装。

CSSをシコシコ書く

iwnidシステム本体とは直接関係ないけれど、実際設置するには生のHTMLだけじゃなくてそれにCSSやjavascriptの皮をかぶせなければいけない。そのCSSをシコシコ書いた。webに限らずデザインが非常に不得手なのでいつも困る。

まずクロスブラウザで差異を吸収するおまじないを検索で拾ってきて、それに肉付けをする。色使いはどうしたものか、いまさらwebセーフカラーでも無いよなあとおもいつつも割と共通に見える色を探してみる。色彩感覚にも乏しいので収集対象に引っ掛けた色のグラデーションで仕上げてみた。

シンプルだけど悪くは無いのが出来たので満足してます。はい。 javascriptでtableをしましまにしたかったけれどそれはまたの機会に。

IEとFireFoxでテーブルのpaddingの解釈がちがうっぽいなあ あとキャプションもおかしくなっちゃった。これはもうちょっといじらないとだな

google readerしか更新情報拾ってくれにゃい→bloglinesは通った

livedoor readerとはてなrssとbloglinesはiwnidのフィードが反映されない。
google readerは反映される。

何かサーバから返すものが足りないのかな

理由が判明。 適当に継ぎ接ぎしてたfeedがvalidじゃなかった。サーバなんてレベルの話じゃなかった。なんとも間抜け。ということでfeed validator先生の言うことをよく聞く。
guid要素にはURIに使えない文字を入れるな→外した→guid要素にパーマリンク以外を入れるときは isPermaLink="false"属性つけろ→つけた→valid

これでbloglinesは通った。あと二つはまだかな。時間の問題かそれ以外か。

iwnid b0.1.1

[ロジック修正] subject.txtの中で検索にmatchしたスレッドに加えて、前回巡回対象の中でliveだったdatを巡回対象に追加しました。

板とび等でsubject.txtからこぼれてそのままdat落ちしても、取得漏れがなくなりました。

[新機能] feedを吐き出して、その読み込みをトリガに巡回できるようにしました。

擬似cronをアクセスの多いところにトリガとして仕込んで更新させる、といっても人なんて早々来ないですし、ロボットもそう頻繁にはアクセスしてくれません。webcronというサービスもありますが訪問は不安定です。そこで更新情報をfeedとして吐き出してそれをサーバ型のrssリーダに叩いてもらいます。更新されたときには更新情報が動的に書き換わるわけです。更新されていないときには304を返します。

header("Content-type: text/xml;charset=utf-8");
を入れなければならないのを忘れて画面が真っ白に。ちょっと嵌りました。

iwnidはまだまだ取りこぼす

まだdat落ちしていないスレに「live」ってマークをつけたのですが、liveなはずなのにliveマークがついて無いスレがあるのを見つけて初めて取りこぼしに気付きました。

現在の設計は

該当板のsubject.txtを配列に入れる
↓
タイトルが正規表現にマッチするスレッドを抜き出す
↓
それについてdatを取りにいく

こういう流れになっています。つまり現在、板飛び等何らかの理由でsubject.txtからこぼれた場合（いわゆる「書き込むとスレが見えるようになる状態」）にそのスレを拾い上げることが出来ません。

subject.txtの中でマッチしたdatに加えて前回巡回したdatも巡回チェックに入れる必要がありそうです。そうすれば巡回→書き込み→板飛び→(書き込まれない)→巡回の現状取りこぼしが起きる場面でも書き込まれたdatを拾い上げることが出来ます。

もちろんこれでも、巡回後にスレが立てられてそのあとsubject.txtから落っこちてその後巡回した場合には拾えませんが、それを言い出すと巡回間隔をどこまでもつめていく必要があったり、そもそも不可視スレはどうするんだ、ということもあるのでまあいいかと。単発の取りこぼしはいいとして、そこそこ続いてるスレのケツが欠けることだけは避けたいのです。

取りこぼし部分の減らし方はわかったのでこれははやいとこ実装しよう。まだ未実装。

iwnidを設置するサーバに困る

ちゃんと設置できても使えるサーバと使えないサーバがあるのは2chが海外ホストをdenyしてる場合があるのね。詳しくは調べてないけど。fsockopen使えるサーバなのに接続できないのはそういう場合みたい。

xreaやさくらで有料サーバ借りちゃうのもいいけど、それだと万一支払い止ったときに即消えるんだよなあ。それが微妙。datの溜まる速度と容量、phpでfsockopen使えてある程度の安定性、そして一番大切な2chとの相性を全部満たす無料サーバはそうそうない。

現状だと100スレちょっとで10MB超えるのでどうしても100MB以上の容量がいる。保存するのはキー.dat.gzで、キー.datを要求されたときにdatの最終更新日とファイルサイズを返してdatを転送できればいいんだけど、そこまで今の自分には出来ないんでとりあえずペンディング。

iwnid b0.1

iwnid b0.1が完成しました。fsockopen使ってHEADで更新確認はするしGETで差分取得はするしで実用に耐えます。

始めたころに書いた、というか公式マニュアルとその下のユーザー投稿からあまり意味もわからずにコピペした部分が今ならもう少し最適化して書ける気もします。がその辺はいまさらって感じもするのでペンディング。

問題は条件に合うサーバがそう多くないことです。容量の関係でどうしても海外無料サーバ中心に探すことになりますが、fsockopenが使えなかったり、2chへのアクセスが制限されていたり。日本語圏ならサーバの危険な雰囲気を感じ取れることもあるけど、英語圏だとよくわかんないです。

さてあとはエラー処理とパーミッションがらみのfixがしばらく必要ですね。

文字コードの取り扱い

文字コードって環境に合わせて相互変換すればいいわけじゃないのか。 shiftjis→utf8→shiftjisに変換すると从*＇ｖ＇）→从*?ｖ?）に化ける。

文字コードはそのまま、ひたすらそのまま触らずに変数に入れっぱなしにするのが吉と。内部では出来るだけutf8で、と勝手に思い込んでたのは間違い。 subject.txtの出力方法再調整・index.htmlをutf8じゃなくてshiftjisで吐き出すように今までのを書き換える必要アリ。

dat.gzは不具合が多い、それでも

dat直置き直読みとdat.gz置きブラウザ側伸張を比較してみた。

dat.gzの利点

• ファイル容量の節約。特にAAが多いものは劇的で406,289byteが35,267byteに縮むものもあった。
• 容量節約に伴う転送量の削減。

dat.gzの欠点

• 差分取得が不能。
• 伸張したときに大きくなるファイル(ex.前掲のものなど)だとlive2chでぐちゃぐちゃになる。(janestyleとtwintailは平気)
• 各2chブラウザが更新チェックを行う際、伸張したローカルdatのサイズbyte,-1byteで更新チェックをかける。サーバには伸張してないdat.gzしかない(そんなファイルサイズは存在していない)ので404を返してしまう。よって2chブラウザからはdat落ちに見える。

欠点一つめ二つめはともかく三つめは2ch仕様との不整合なのでこれはどうにもならないかも。

それでもサイズが十分の一になるってのはすごく魅力的なんだよなあ。サイズが小さくなることで無料サーバでも一元管理が出来る。それによりローカルのバックアップも楽。うーん…

見えてきたけど放棄して楽な道へ

實松アウトプット: 配列の操作が難しい の続き。なんだか見えてきた。

$dat_hand_array[y][0]を配列$y0arrayに取得。
$dat_auto_array[x][0]を$y0arrayと比較して、$y0arrayに無い場合にxを返す。
返ってきたxと$dat_auto_arrayで$dat_ｘ_arrayを作る。

こんな感じかな？

いや、やっぱいいや。グダグダ考えずに一次元目のキーにdatのキー入れちゃった方が全然楽そ

配列の操作が難しい

二次元配列の操作が難しい。

$dat_hand_array
Array
(
    [0] => Array
        (
            [0] => 1173338640
            [1] => http://ex22.2ch.net/test/read.cgi/morningcoffee/1173338640/
            [2] => 1174895506
            [3] => hand
            [4] => 249

        )

    [1] => Array
        (
            [0] => 1173423620
            [1] => http://ex22.2ch.net/test/read.cgi/morningcoffee/1173423620/
            [2] => 1174895506
            [3] => hand
            [4] => 922

        )

    [2] => Array
        (
            [0] => 1173060327
            [1] => http://ex22.2ch.net/test/read.cgi/morningcoffee/1173060327/
            [2] => 1174895566
            [3] => hand
            [4] => 423

        )

)
$dat_auto_array
Array
(
    [0] => Array
        (
            [0] => 1173060327
            [1] => http://ex22.2ch.net/test/read.cgi/morningcoffee/1173060327/
            [2] => 1174895566
            [3] => auto
            [4] => 236

        )

    [1] => Array
        (
            [0] => 1173340422
            [1] => http://ex22.2ch.net/test/read.cgi/morningcoffee/1173340422/
            [2] => 1174895842
            [3] => auto
            [4] => 36

        )

)

• $dat_auto_array[x][0]の値の中で$dat_hand_array[y][0]の値の中に無い場合、そのx番目の配列を$dat_x_arrayに次々抜き出す。
• $dat_hand_arrayと$dat_x_arrayをくっつけて$dat_all_arrayを作る。

一個目の操作が出来ね

手動でdatを追加した後のsubject.txt生成

ディレクトリの中からファイル名の配列を取得
ファイル名の配列からキー.dat.gzのキーを取得
subject.txtを作るためにキーの配列分繰り返す
　キーのレス数(＝行数)を取得
　1行目からキーのスレタイを取得(.datはsjisなのでutf8に要変換)
　配列に収納 スレタイは5番目。スレタイ末尾の改行は除去
subject.txt(shiftjis)を二次元配列から出力
subject.txtにまとめて書き込む

これでsubject.txtの生成も完成しました。

手動追加部分が完成

手動追加部分は出来ました。

datディレクトリの中からファイル名の配列を取得
ファイル名の配列からキー.datのキーを配列に取得
ファイル名の配列からキー.dat.gzのキーを配列に取得
キー.datのキーとキー.dat.gzのキーを比較してキー.dat.gzが無いキー.datの名前を取得
該当するキー.datをキー.dat.gzに圧縮
該当キー.datのレス数(＝行数)を取得
該当キー.datを削除
該当キー.dat.gzについて キー<><>unixtime<>hand<>レス数\n をlogに追記

流れはこんな感じです。ローカルで動かす分なのであまり効率性は考えずにファイルを開いたり閉じたりしてます。

logの一つ目の<>の後ろには元のURLを手動で記入してます。

logとレス数と元のＵＲＬからフルdatなのかを手作業で調べるのが面倒くさいです。dat落ちスレのミラー探すサイトが無ければめげてたなあ。サーバ移転があって取り残されてる側のdatだったりすると特に。でもサーバ移転の歴史が頭に入ってれば平気。平気？

iwnidプロジェクト

2ch自動過去ログ倉庫プロジェクト＠自分用をiwnidプロジェクトと名付ける。

プロジェクトって言っても一人だし、blogのカテゴリにiwnidってつけるだけ。考え方や部分部分のコードは出していくけど完成品のコードは出さない予定。あんまり安易に根こそぎクロールに使われるのはよくない。サーバと共存していかないと。とはいいつつ基本的に車輪の再開発だったり技術的拙さゆえのヘマは多かったりするけど、そこは習作ということで勘弁。

I Want NIchannel Datfiles の頭文字をとってIWNID。

gzip圧縮を透過的に読めた

datのディレクトリにhtaccessを置くことで解決。

RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME} !\.gz$
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule .+ %{REQUEST_URI}.gz
ForceType text/plain
AddEncoding x-gzip .gz

外部javascriptをgzip圧縮して置くには〜という議論から設定をパクりました。ForceType使えばいい、と。 IE6、Firefox、live2ch、unDonut、でそれぞれ確認済み。

實松アウトプット: webブラウザから読めない をクリア。

サーバとの通信HTTP Headers

IEで 實松アウトプット: webブラウザから読めない のパーマリンクを開きdatへのリンクをクリックすると一回目は

GET /koharu_morningcoffee/dat/1173060327.dat HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, */*
Referer: http://sane.justblog.jp/blog/2007/03/httpsanelxljpko.html
Accept-Language: ja
Accept-Encoding: gzip, deflate
If-Modified-Since: Sun, 25 Mar 2007 19:48:13 GMT
If-None-Match: "476a19-3dd7-91aab940;91aab940"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET
CLR 1.1.4322; .NET CLR 2.0.50727)
Host: sane.lxl.jp
Connection: Keep-Alive
Cookie: dbx-postmeta=grabit=0-,1-,2+,3+,4+,5-,6-;
dbx-pagemeta=grabit=0-,1-,2-,3-,4-,5-,6-&advancedstuff=0-

HTTP/1.1 304 Not Modified
Date: Mon, 26 Mar 2007 05:56:31 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Connection: close
ETag: "476a19-3dd7-91aab940;91aab940"
Content-Location: 1173060327.dat.gz
Vary: negotiate

二回目以降は

GET /koharu_morningcoffee/dat/1173060327.dat HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, */*
Referer: http://sane.justblog.jp/blog/2007/03/httpsanelxljpko.html
Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET
CLR 1.1.4322; .NET CLR 2.0.50727)
Host: sane.lxl.jp
Connection: Keep-Alive
Cookie: dbx-postmeta=grabit=0-,1-,2+,3+,4+,5-,6-;
dbx-pagemeta=grabit=0-,1-,2-,3-,4-,5-,6-&advancedstuff=0-

HTTP/1.1 200 OK
Date: Mon, 26 Mar 2007 05:58:31 GMT
Server: Apache/2.0.40 (Red Hat Linux)
Content-Location: 1173060327.dat.gz
Vary: negotiate
TCN: choice
Last-Modified: Sun, 25 Mar 2007 19:48:13 GMT
ETag: "476a19-3dd7-91aab940;91aab940"
Accept-Ranges: bytes
Content-Length: 15831
Connection: close
Content-Type: application/x-gzip
Content-Encoding: gzip

を返してきてる。サーバ側からの応答に問題があるんだろうけどなんなのかよくわかんね。これからこれから。

webブラウザから読めない

http://sane.lxl.jp/koharu_morningcoffee/dat/1173060327.dat
IEからクリックすると 1173060327.dat って名前でgzip圧縮されてるファイルが落っこちちゃうなあ。Firefoxだと普通に 1173060327.dat.gz がダウンロードされちゃう。やりたい挙動はサーバ上にはdat.gzでクリックするとdatが落ちてくるというもの。.htaccessにはあちこちからつぎはぎした

RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME} !\.gz$
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule .+ %{REQUEST_URI}.gz
AddEncoding x-gzip .gz
AddType application/x-gzip .gz .tgz
AddType text/plain .dat

を書き込んでいます。たぶんまだ何か足りない。

live2chではうまいこと読めるんだけど。とりあえず保留。

2chの自動過去ログ倉庫を作りたい

2chの自動過去ログ倉庫を作りたい。さて何から手をつけようか。動いて楽しいところから手をつけよう。

datのアップダウンはひとまず手動、専用ブラウザからdatが見える。これを目標に勉強開始。