フリー著作物と集団知の時代

僕もいくつかフリーで配布しているスクリプトやプラグインはあるけど、昔は黙って使われると腹が立ったし、使うなら断れと思った。実際、ブログにそういう断りを入れていた時期もある。でも、多分それは違うんだろうな。と、今は考えている。とは言っても、ムカツクことは正直あって、コメント欄に絵文字を入れられるスクリプトを公開したら仲のいい友達が使ってくれた。実際には会ったことのないネット上の知り合いだけど。

以前、ブログのページでプログラムのソースコードを引用させてもらった方がいて、その方とは面識がなかったんだけど引用させて頂いた挨拶を先方のブログに残した事がある。

そうしたら、次の返事を頂いた。一部抜粋。

ネットで拾えるものは、もう自由で良くね!かな?。

ここで、誤解があるといけないから補足すると、その方の言っているのは「自分の書いたソース」に関して、黙って勝手に使えばいいと言ってくれているわけだ。

僕は、それを読んで凄いなと思った。

こんな事もあった。

ネット上の知り合いが、ブログのテンプレートを無償公開していて、たまたま情報商材アフィリエイトの詐欺みたいなサイトが、そのテンプレートを使っていたので、「使われてるの知ってる?」って聞いたらこう言われた。

「知りませんでした。でも、公開してるんだから誰でも使ってくれれば嬉しいです」

これも、また凄いと思う。清濁併せ呑むという事か。

僕もいくつかフリーで配布しているスクリプトやプラグインはあるけど、昔は黙って使われると腹が立ったし、使うなら断れと思った。実際、ブログにそういう断りを入れていた時期もある。

でも、多分それは違うんだろうな。と、今は考えている。

とは言っても、ムカツクことは正直あって、コメント欄に絵文字を入れられるスクリプトを公開したら仲のいい友達が使ってくれた。実際には会ったことのないネット上の知り合いだけど。

そして、その絵文字ソフトに不具合があったので、ある日バージョンアップをした。そこで、バージョンアップをしたから交換してくれと言ったら拒否された。

理由は、その不具合には困っていない。新バージョンには公開者サイト(つまり僕)へのリンクがある。そのリンクを外すなら交換する。という事だった。

その瞬間、その大事だった友達は、僕の中では大切ではない、ただの知り合いになってしまって、その後はほとんど会話をしなくなったし、そのブログも見なくなった。

リンクを入れたのは、他に使いたい人がいた時に、どこから落とせるかを知らせるためだったんだけど。

「これいいね、どうしたの?」「拾ってきたけど、どこにあったか覚えてない」という会話を見つければ、リンクを入れようと考えるのは自然な事で、「新バージョンに差し替えて欲しければ、そのリンクを外せ」というのはどういうことだろうと思った。そのスクリプトを使っている当人にとってはリンクがあっても邪魔なだけかもしれないけどね。

とにかく、そんな理由で拒否され、僕の書いたスクリプトは不具合のあるまま交換されていない。

その不具合には困っていないから問題ないというけれど、それが交換されないのだから、僕はその不具合に恥をかかされ続けている。

設置した当人にとっては、それは僕のものではなく、自分のものになっているわけだから、どうでもいい事なんだろう。

使われる以上、それは使い手のものであって、作り手のものではないのかもしれない。

どれだけ、苦労したと思っているのか、というのは作り手の理屈。使い手には関係ない。

使った人が連絡くれるのはうまく動かない時で、困らなかった場合は、何も言ってこないのが普通だ。

不具合のあるまま出してしまったのは自分。いちいち腹を立てていてはいけないんだろうな。

以前、Linux OS の話が出た時に、こんな事を言っている人がいた。

「タダで公開するなんて馬鹿だよね。有料にすれば結構儲かっただろうに」

それ、違うんだな。タダで公開したから人が集まって、いろいろと改良されていった。誰でも自由にソースを読んで、自由に改変して、無料で自由に使ってくれ。そういうコンセプトがなかったら幼年期のOSのまま成長しなかったんじゃないだろうか。自由にいじれるから世界のハッカー達が喜んで手を入れていった。

インターネットのサーバーで使われているOSは、Linux や FreeBSD。Webサーバーソフトのapache、メールサーバーのqmailやsendmailなどは全部、無償公開されていて、誰でも自由に無料で使える。

もし、それらがなかったら、今、これほどインターネットが発達していたのかはわからない。していたかもしれないし、していなかったのかもしれない。

ANSI-Cの標準ライブラリにもなっているqsort、クイックソートのアルゴリズムを知った時には驚いたもんだけど、数々のアルゴリズムが、無償公開されずに特許をとっていたら、今の進歩は随分遅れているんじゃないだろうか。

インターネットがこれだけ発達し、ハードウェアが進化した今、誰かの流した情報は即時にシェアされ、世界を駆け巡る。

今までは、個人ひとりひとりの知識だったものが、これからは集団知の時代になる。集団という新しい生命体がネットワーク上に生まれるんじゃないかと、僕は考えている。

こないだ、店を持ちたいという知り合いと車で移動していたら、こんな事を言っていた。

「この通りいいんだよ。空室出ないか探してるんだけど、ないんだよな」

地球上の争い事というのは、これまで主に領土の奪い合いだった。土地を奪うことで勢力を拡大する。

でも、インターネット上には、土地は無限にある。ネットで店舗を開くなら空室には困らない。

これからの時代、財産は不動産から知的財産へと変わっていくと思う。

権利や特許の争奪戦になった時、これまでの進歩は停滞するのか。どうなるのか、僕はすごく興味がある。

togetterにまとめられちゃったので、私のCopy__writingに対する見解

ツイッターのアカウント@Copy__writingの件で、反論をtogetterにまとめられてしまったので私の意見を説明します。私個人の気持ちとして、無断転載、パクツイは大嫌いです。ただ、時代というのは変わっています。

ツイッターのアカウント@Copy__writingの件で、反論をtogetterにまとめられてしまったので私の意見を説明します。

Copy__writingが悪質であると周知することは無断転載行為を助長するという意見への回答

ただ、これは推奨するわけでもないし、元々、この考えを世に問うつもりもありません。個人的意見をメンションつけて飛ばしていた事に対して、公に回答されてしまうと言う結果だったので書くだけです。回答してきた、かことは3年半の知り合いで、反論の直前まで共同ブログを運営していた仲でしたから彼女にだけ伝わればいいという考えでした。

私の考え

私個人の気持ちとして、無断転載、パクツイは大嫌いです。

私の気持ちはそうなんですが、ではパクられた作家さん方は、現在(2015年5月11日)87万フォロワーがいるアカウントにツイートされて「大勢に見られたことが問題」なんでしょうか?中にはそういうクリエイターの方もいらっしゃるかもしれません。それなら別ですけど。

でも、クリエイターの方の多くは、大勢に見られる事は問題でないでしょう。「パクられたこと」が問題なんじゃないんですか?

87万のフォロワーがいるアカウントにツイートされる事自体は嬉しいでしょ。違いますか?

問題は「作者を明示せずリンクなし」でツイートされる事、あるいは「自分ではない作者のもの」として不当にツイートされる事でしょ。

もし、そうなら仮に@Copy__writingのアカウントを凍結させることが出来たとしても、大勢に見てもらうチャンスもなくなりますよね。アカウントがなくなるんだから。

悔しいですが@Copy__writingのセレクション能力は高いです。だからフォロワーが多いんでしょう。

その87万フォロワーのいるアカウントには何年もの間、大勢が抗議しているのに何も変わりません。凍結するのは難しいんじゃないですか。

でも、最近変化がありました。私は、その変化に現実的に対応して、そのアカウントを利用しましょうよ。と、いう考えです。

向こうが、無料でリンク付きツイートしたいと言うのなら、応じればいいじゃないですか?

人気の指標なんて、フォロワー数と、リツイート数でしょう。いくら@Copy__writingに対する批判的なツイートをしたところで、それには勝てませんよ。

今は、無断転載のリンクなしツイートばかりですが、向こうからリンクを付けて無料でツイートさせて欲しいと言ってきたんだから断る必要ないでしょう。

そういう、リンク付きツイートが増えて何が悪いんでしょうか。無断転載ツイートの中にリンク付きがあったら困りますか?すべて一斉にリンク付きに改めないなら許せませんか?それで結局了承した作家さんが後から傷ついてしまったわけでしょ。

断らずに掲載された作品のツイートがリンク付きで流れるようになった場合、次のようなケースは考えられませんか。

ツイートをフォロワーが見て「これステキ。どこにあるんだろ?こないだはサイトへ行けるリンクがあったのに、これにはリンクがない」そんな不満をフォロワーが感じ始めたらどうなりますか。

フォロワーがリンク付きに慣れたなら、その後「リンクがない」と言って離れ出したら困るんです。他のパクリメディアへ移って行ったら困るんです。そうなるなら@Copy__writingだって作者へのリンク付きツイートを増やすようになる可能性はないですか?@Copy__writing以外の、たくさんの無断ツイートアカウントまでもがリンクを入れるようになる可能性があるんじゃないですか?

相手にとっては、フォローしてないユーザーが、どれだけ批判しても痛くも痒くも無いですわ。でも、フォロワーが減ったら動くでしょ。相手は悪党なんだから。フォロワーとツイートは飯の種。

だから「リンクをつけてツイートしたい」と言って来たのなら、承諾したほうがアカウント凍結に追い込もうとするよりも、ずっと発展的じゃないですか?

承諾したくない人は、黙っていても断ります。でも、何も知らない人に拡散して回らなくてもいいじゃないですか?

問題は、@Copy__writingからの申し出に、事情を知らずに応じた作者が被るイメージダウンですよね。それが心配で拡散してるんですよね?でも、実際のところイメージダウンしないでしょ。それは何故か?

フォロワーの大部分は未成年から20代

フォロワーに関しては、おそらく、鈴木名義のメールの内容でほぼ正しいと思います。

実際に@Copy__writingのフォロワーで、リツイートや、リプをしている人達を見てみました。プロフィールと直近のツイートだけでの判断ですが、多くは中高生、大学生、あるいはそれに等しい年代の若者です。

私は昭和生まれなんで、学生時代の情報源で雑誌なんか見ましたけど、今の学生にとってのツイートは雑誌替わりじゃないでしょうか。

雑誌であれば、出版社が販売します。その中で頻繁にパクリをするようなら、販売禁止になるでしょう。そもそも、出版するのに費用もかかるし、誰でも販売できるわけではありません。

でもツイッターならだれでも無料で、身元を隠してツイート出来るので「無断転載」が容易になります。今は、そういう時代です。

無断転載のツイートがバンバンある中で、元からそういうモノだと思っている、中高生、大学生の彼ら彼女らフォロワーにとっては本家サイトへのリンクがないのは普通の事です。誰の作品なのか出典を明記しないのは不思議ではありません。そういうモノだと思っています。無断転載だという認識がないんです。

だからフォロワーは流れて来たものが「不当なツイート」だとは思いません。

フォロワーがそう思っているのに、リンク付きのツイートを承諾してツイートされた場合、何か不利益ってあるんですか?

「この人、パクリアカウントに協力している」なんて思うフォロワーはいないでしょ。

思うのは、@Copy__writingが悪アカウントだと認識している人達、つまりフォローをしていないユーザーです。

もし、後から有料に変わったとします。掲載終了して断ればいいじゃないですか。これまでのところ契約書もなかったし、削除しなかったとしても向こうの都合なんだから払う必要ありません。今後、どこかのサイトで新しい依頼があった場合、掲載前に契約書を送りたいって言われたら住所を教えないで断ればいいですよね。

もし、後になって削除を申し出たのに、削除するなら金を払えと言われたとします。だったら削除しなければいいじゃないですか。何か問題でも?今だって無断で掲載されて削除してくれないんでしょ。

SEOが気になるなら、Twitterにはノーフォロータグがついていますし、リンクからの流入はそれ以上望めます。そもそも、SEOに詳しい人なら@Copy__writingの評判が悪いって知っている人多いでしょ。

SEOなどに詳しくない、純粋な工芸作家さんが「リンク付きツイート」の依頼を受けて応じた時に、それの何がいけないんですか?

問題は、@Copy__writingの依頼に応じるのが悪い事だと考えているあなたでしょ。

雑誌の時代と違うんだから評価の仕方を変えませんか?

ツイッターが出来たのは最近です。キュレーションサイトみたいな、パクリメディアが出来たのも最近です。時代は変化しています。だから、これらのパクリサイトはまだ増えるでしょう。これが、昔の雑誌の役割をつとめるのなら、無くならないのは時代の変化で仕方がないんじゃないですかね。

サイトを訪れるユーザーが減らない限り、パクツイをフォローするユーザーが減らない限り、パクリメディアは消えないんじゃないでしょうか。

若い世代のフォロワーは悪いことだと認識していないんだから、面白ければフォローします。これは仕方のない事です。

ステキな作家さんを10人見つけて、10人フォローするより、@Copy__writingだけフォローしたほうが簡単でしょ?だから、簡単には減らないですよ、フォロワーは。

パクられてしまった事を恨むのは当然ですが、他の人が依頼に応じてリンク付きツイートを承諾するのまで、阻止する必要はないんじゃないでしょうか。

皆さん、言っても無駄だってわかってるじゃないですか。だったら混乱させることはないでしょ。向こうがリンクを入れようとしているのを阻止して、何の意味がありますか?早い段階でリンクを入れる常識を構築したほうが将来のためでしょ。

私は、悪党の性根が変わるとは思っていませんが、時代が変わって行く中で、正しさの基準が変わることはあると考えています。

昔は天動説が絶対正しかったのに、今は地動説が正しいというように、時代が変われば評価は変わることがある。パクられた怨みがあるのは当然です。でも、時代と共に常識は変わります。

@Copy__writingを潰せないのは、敗北ではなく、淘汰だと思います。悪党と呼ぶ人がいなくなれば悪党ではなくなります。

それなら、向こうがリンクをつけると言ううちに、フォロワーがリンクを押す習慣を少しでも作っておいたほうが良くないですか。

繰り返しますが、これは推奨するわけでもないし、元々、この考えを世に問うつもりもありません。かこ自身はパクられた当事者ではないんだから、@Copy__writingに対する無理な活動は必要ないでしょうという考えだけです。

かこが、当初作っていたパクられ作品の作家さんページヘ行けるリンク集は素晴らしい仕事だと思うし、そういうリンクの有意義さを感じる人が増えればリンクが張られる状況も増えるかもしれない。でも、今やってることって必要なの?

わかっていたと思うんだけどね。


それから、本当に戦う気でいるなら、下のような馬鹿なリツイートはするな。無断転載されたという、その作品自体が法人名とロゴを無断使用している。自ら違法作品をリツイートする奴に何の説得力がある?毎日のようにテレビ番組のキャプチャを流しているアカウントや、著名人の顔をヘッダやアイコンにしているアカウント。そういうのも著作権、肖像権の侵害だが、そういうユーザーをフォローしたままどう戦う?自分達の作品のパクリは許さない。けど自分達が無断使用するのは許すのか?

PHPでTwitterのOAuth認証するサイトのサンプルページを作ってみました

PHPでTwitterのOAuth認証でログインするサイトのサンプルページを作って見ました。実行内容は、次の通りです。
.htaccess を使ってすべてのアクセスを index.php に渡す。index.php でログイン済みかどうかをチェック。ログインしていない場合、template.php を使って状況に応じたメッセージを表示。「ログイン」をクリックしたら、Twitterの認証ページヘリダイレクト。認証がすんだら page_1.php を開く。あとは自由にページを見られる。存在しないページをリクエストされたら、404.php を表示する。「ログアウト」をクリックしたらログアウトする。

PHPでTwitterのOAuth認証を使ってログインするサイトのサンプルページを作って見ました。
http://php-oauth-sample.dwm.me/

追記:上のはあまりにもみすぼらしいので、ちょっと真面目に作り直しました。こちらが新しいサンプルです。
http://dwm.me/sample/todo/

ただし、今ご覧頂いているページの内容は最初のサンプルにそって書かれています。

作ったファイルは、.htaccess と index.php、page_1.php、page_2.php、404.php、それから template.php です。

ファイルはhttp://php-oauth-sample.dwm.me/twitter_oauth_sample.zip からダウンロードできます。

実行内容は、次の通りです。

  • .htaccess を使ってすべてのアクセスを index.php に渡す。
  • index.php でログイン済みかどうかをチェック。
  • ログインしていない場合、template.php を使って状況に応じたメッセージを表示。
  • 「ログイン」をクリックしたら、Twitterの認証ページヘリダイレクト。
  • 認証がすんだら page_1.php を開く。
  • あとは自由にページを見られる。(他には page_2.php しかありませんけど)
  • 存在しないページをリクエストされたら、404.php を表示する。
  • 「ログアウト」をクリックしたらログアウトする。

page_1.php と page_2.php それから 404.php は独立していて、それ以外の処理を template.php に渡して表示します。

また、ライブラリとして https://github.com/abraham/twitteroauthで公開されている twitteroauth を使っています。(上に書いた圧縮ファイルの http://php-oauth-sample.dwm.me/twitter_oauth_sample.zip には同梱していません)

Twitter Apps で認証キーを取得する

まずはじめにTwitter Apps(https://apps.twitter.com/)で、API key と API secret を取得します。

Twitter AppsTwitter Apps

Website と書かれた項目と Callback URL と書かれた項目以外は、好きに書いて構いませんが、認証画面で次のように表示されます。

Twitter Apps

Website には、認証させるサイトのURLを入力します。

Callback URL は、認証が済んだ後に自動でリダイレクトされる先のURLです。私のサンプルでは http://php-oauth-sample.dwm.me/twitter_callback/ になっていますが、ここで必要なデータを取得したら、再びリダイレクトして http://php-oauth-sample.dwm.me/page_1/ に飛ばしています。結果として、ログインしたユーザーが最初に見るのは http://php-oauth-sample.dwm.me/twitter_callback/ ではなく http://php-oauth-sample.dwm.me/page_1/ になります。

また、Twitter Apps に登録する際に注意しなくてはいけないのが、Allow this application to be used to Sign in with Twitter という部分です。ここにチェックを入れておかないと、ログインする度に認証ページが開いてしまいます。

ここにチェックをいれておけば、最初の認証以外は、すぐに http://php-oauth-sample.dwm.me/twitter_callback/ へリダイレクトさせることが出来ます。その説明は次のページが詳しいです。

PHPで「Sign in with Twitter」を実装する方法 – 頭ん中

同ページより引用

  • ユーザーが呼び出し元アプリケーションを承認している場合
    • ユーザーが Twitter にログインしている場合:直ちに承認されて、呼び出し元のアプリケーション(callback URL)にリダイレクトされる。
    • ユーザーが Twitter にログインしていない場合:Twitter のログイン画面が表示され、ログイン後は直ちに承認されて、呼び出し元のアプリケーションにリダイレクトされる。
  • ユーザーがまだ呼び出し元アプリケーションを承認していない場合、あるいは承認を取り消している場合
    • ユーザーが Twitter にログインしている場合:OAuth の承認画面が表示され、承認後は呼び出し元のアプリケーションにリダイレクトされる。
    • ユーザーが Twitter にログインしていない場合:まず Twitter のログイン画面が表示され、ログイン後に OAuth の承認画面に移り、承認後は呼び出し元のアプリケーションにリダイレクトされる。

ライブラリ twitteroauth の取得

OAuth認証をするために使うライブラリを https://github.com/abraham/twitteroauth から取得します。

開いたページの右側に Download ZIP というボタンがあるので、それをクリックするとダウンロードできます。

twitteroauth

ダウンロードした .zip ファイルを解凍するとファイルがたくさんありますが、必要なのは twitteroauth というフォルダだけです。このフォルダの中に入っている2つのファイル OAuth.phptwitteroauth.php を使います。

.htaccess の作成

この項目は私のやった方法の場合で、OAuth認証と基本的に無関係です。

サイトへの、すべてのリクエストを index.php に渡して、そこで処理するために次の内容の .htaccess を用意しました。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule . index.php [QSA,L,PT]
</IfModule>

実際の .htaccess には他にもいろいろ書いていますが、mod_rewrite に必要なところだけ書き出しています。これで、すべてのアクセスは index.php に渡されるので、そこで処理をします。

URLは http://php-oauth-sample.dwm.me/page_1/ という形式で、この場合だと page_1.php を読み込んで表示するようにします。

index.php の内容

大きく分けると switch 文で、次のように処理を振り分けています。

実際に使っているファイルは http://php-oauth-sample.dwm.me/twitter_oauth_sample.zip からダウンロードできますので、そちらを参照してください。

switch($match[1]){
	// ログインをリクエストされた場合
	case TWITTER_LOGIN:

		// 認証用のtokenを取得

		if(token が取得できたら){
			// Twitter へリダイレクトして終了
			//(認証後、登録したリダイレクトページに返ってくる)
			return;
		}

		// token が取得できなければ、表示するメッセージを用意してbreak
		break;

	// Twitterの認証画面からリダイレクトされてきた場合
	case TWITTER_CALLBACK:

		if(認証されていたら){
			// 送られたデータをセッションに渡し
			// http://php-oauth-sample.dwm.me/page_1/ ヘ リダイレクトして終了
			return;
		}

		// 認証されなていなければ、表示するメッセージを用意してbreak
		break;

	// ログアウトをリクエストされた場合
	case LOGOUT:

		// セッションをクリア

		// ログアウト完了のメッセージを用意してbreak
		break;

	// その他のケース
	default:

		if(指定のページが存在する場合){

			if(ログインしていれば){
				// そのページを表示して終了
				return;
			}

			// ログインしていなければ、ログインを促すメッセージを用意

		}else{
			// ページが存在しなければ 404ページを読み込んで終了
			return;
		}

		// 指定のページが存在するけど、ログインしていない場合はbreak
		break;
}

// ここまでで return していなければ
// template.php に用意したメッセージを埋め込んで表示

header('Content-Type: text/html; charset=UTF-8');
require_once(TEMPLATE_FILE);

ログインをリクエストされた場合

// API key と API secret は https://dev.twitter.com/apps から取得する

define('API_KEY', '*************************');
define('API_SECRET', '**************************************************');

define('LOCATION_BASE', 'http://php-oauth-sample.dwm.me');
define('TWITTER_CALLBACK', 'twitter_callback'); // Twitterからのコールバックページ

/************************************************************************/

// switch文から該当部分のみ抜粋

case TWITTER_LOGIN:

	// token を取得

	$auth = new TwitterOAuth(API_KEY, API_SECRET);
	$url = sprintf('%s/%s/', LOCATION_BASE, TWITTER_CALLBACK);
	$token = $auth->getRequestToken($url);

	// token が取得できたら Twitter へリダイレクトして終了
	//(認証後、登録したリダイレクトページに返ってくる)

	if(isset($token['oauth_token']) && isset($token['oauth_token_secret'])){

		// セッションに登録
		$_SESSION['oauth_token']        = $token['oauth_token'];
		$_SESSION['oauth_token_secret'] = $token['oauth_token_secret'];

		// 2つ目の引数が true だと
		// アプリケーションを承認済みユーザーは即座にcallbackページにリダイレクト
		// 未登録の場合は、承認画面を表示後、承認が終わるとリダイレクトされる
		// ただし、Twitter Apps で
		// Allow this application to be used to Sign in with Twitter
		// にチェックを入れておく事が必要

		$auth_url = $auth->getAuthorizeURL($_SESSION['oauth_token'], true);

		header("Location: " . $auth_url);
		return;

	}

	// token が取得できなければ、表示するメッセージを用意してbreak

	$message = 'エラーが発生しました。恐れ入りますが、もう一度やり直してください。';

	break;

Twitterの認証画面からリダイレクトされてきた場合

case TWITTER_CALLBACK:

	// 認証されていたら
	if(isset($_REQUEST['oauth_verifier']) && ('' != $_REQUEST['oauth_verifier'])){

		$auth = new TwitterOAuth(API_KEY, API_SECRET,
			$_SESSION['oauth_token'], $_SESSION['oauth_token_secret']);

		$access_token = $auth->getAccessToken($_REQUEST['oauth_verifier']);

		$_SESSION['user_id']     = $access_token['user_id'];
		$_SESSION['screen_name'] = $access_token['screen_name'];

		// ログイン後、最初に表示するページヘリダイレクトして終了
		// URLにGETで oauth_token と oauth_verifier が含まれているので
		// それを消すために require でファイルを読むのではなくリダイレクトさせる

		// define('FIRST_PAGE', '/page_1/');

		header('Location: ' . LOCATION_BASE . FIRST_PAGE);
		return;

	}

	// 認証されなければ、表示するメッセージを用意してbreak

	$message = 'ログイン出来ません。Twitterアカウントを確認してください。';

	// 認証されていなければセッションの削除
	session_destroy();
	unset($_SESSION);

	break;

ログアウトをリクエストされた場合

case LOGOUT:

	// ログアウト完了のメッセージを用意

	$message = 'ログアウトしました。';

	// セッションの削除
	session_destroy();
	unset($_SESSION);

	break;

閲覧用のページが指定された場合

default:

	// define('FILE_PATTERN', FILES_PATH . '/files/%s.php');
	// .php ファイルは FILES_PATH/files/ にある

	$path = sprintf(FILE_PATTERN, $match[1]);

	// 指定のページが存在する場合

	if(file_exists($path)){

		// ログインしていれば

		if(isset($_SESSION['user_id'])){

			// そのページを表示して終了

			header('Content-Type: text/html; charset=UTF-8');
			require_once($path);
			return;

		}

		// ログインしていなければ、ログインを促すメッセージを準備

		$message = sprintf('%sをご覧になるにはログインが必要です。', $match[1]);

	}else{ // 指定のページが存在しない場合

		// ページが見つからない404ページを読み込んで終了

		header('HTTP/1.0 404 Not Found');

		$file_404 = sprintf(FILE_PATTERN, PAGE_404);
		require_once($file_404);
		return;

	}

	break;

大体、このような流れで処理しています。

動作はデモページ http://php-oauth-sample.dwm.me/ でご確認ください。

実際のファイルはhttp://php-oauth-sample.dwm.me/twitter_oauth_sample.zip からダウンロードできます。(ライブラリの twitteroauth は同梱していません)

消えたコメントはInternet Archiveを探せ!

ファンブログのコメントとトラックバックが削除されましたが、もう戻ることはないでしょう、多分。本当に復旧すると思って待っている人は、諦めた方がいいのではないかと思います。でも、消えてしまったコメントが読める方法があります。

関連記事:Windowsでファンブログの全記事バックアップスクリプト
追記:この記事で紹介しているInternet Archiveより、上の関連記事中で説明しているGoogleのキャッシュの方がコメント保存率が高いです。

ファンブログのコメントとトラックバックが削除されましたが、もう戻ることはないでしょう、多分。本当に復旧すると思って待っている人は、諦めた方がいいのではないかと思います。

自分としては、別の記事「消えたコメントのことは嘆かない奴ら」にも書きましたが、この状態は大歓迎。今後は何でもいいから書いてありさえすればコメントしに人が来るということはありません。コメントをする仲良しではなく、記事を読む読者を増やさないと、誰も来なくなるでしょう。

とはいえ、コメント出来ないのはともかく、今までのコメントが戻らないのは辛いです。新しいコメントとトラックバックは不要ですが、すでにもらったコメントは消さないで欲しかった。自分はバックアップを取れているから、本気で怒っていませんが、がっかりしている人もいるかもしれません。

でも、いろいろな人の意見を読んだけど、コメント出来ないことに腹を立てている人ばかりで、消えたコメントの事を悲しんでいる人って見つからなかったんだけどね。それについては上の記事で書いたから、ここでは触れない事にします。

「新しいコメントとトラックバックは不要ですが」と書きましたが、コメント欄をつけたければ自分でつければいいと思います。参考記事:ファンブログのコメント欄に「DISQUS」を設置

Internet Archiveにデータを探す

場合によっては、失ったコメントを読めるかもしれません。その場所はInternet Archiveです。

例えばマスクドライダー17号さんの場合なら、2013年01月17日の18:38:25の時点でのログが保存されています。

サイドバーの最新コメントをクリックすると、「マスクドライダー17号|2013年01月18日(金) 00:58」のコメントが出てきます。ログは17日18:38:25までのはずなのに、18日00:58のコメントですが、日本時間とグリニッジ標準時の時差は9時間なので、正常です。つまりInternet Archiveの時刻に9時間足したのが日本時間です。

以前、Internet Archiveの使い方は記事にしているので、それを参考にご自分のブログを探してみてください。

その他、参考になるかもしれない記事

Internet Archiveという自動保存Web魚拓

これは「HTML」というカテゴリーが適当というわけではないですが、他にいいカテゴリーがないので、ここに入れておきます。内容は簡単な「豆知識」です。

このブログは今年、2013年3月1日に模様替えをしました。テンプレート自体は形になっていますが、古い記事を開くと、記事の部分だけ表示が変だったりします。古い記事は新しいスキンのレイアウトにあっていないんです。今後、古い記事を順番に改訂し、レイアウトを統一しなくてはいけないなと思っています。

で、ですね。古い記事によっては、特にカテゴリーの「ブログカスタマイズ」であったり「スタイルシート」においては、記事の説明と実際の(現在の)このブログのレイアウトと違っていたりして、意味が通じないことがあります。

古いレイアウトを再現して、提示できればいいんですけど、それをやるのは大変だし、どーしましょ?というのが、今回のお題。

「Internet Archive」という自動保存「Web魚拓」

世の中には、探せば便利なものがありまして「Internet Archive」というのも、そのひとつです。

便利である半面、人によっては都合が悪い場合もあるかもしれません。というのは消したはずのページが、ここに残っているかもしれないからです。「ウェブ魚拓」というのがありますが、あれの自動保存版といえばわかりやすいでしょうか?それもタイムラインに沿って探せるようになっています。

「Internet Archive」の使い方

「Internet Archive」には膨大な数のサイトが保存されていますが、検索には探したいサイトのURLが必要です。サイト名が分かってもURLが分からなければ探せません。基本的には「ブックマークしてあったページがなくなった。あのページの情報が欲しかったのに!」というような時に力を発揮するのが「Internet Archive」です。ですが、サイト名が分かる場合はGoogleなどで検索すればURLが見つかるかもしれません。

今回は、このブログのURL「http://fanblogs.jp/ayzfqir5/」を例に説明します。

まず、Internet Archiveのページを開きます。サイトの左上は下図のようになっています。

サイトを検索する場合、タブは「Web」のままで、Searchに探したいページのURLを打ち込みます。「All Media Types」はそのままでいいです。そして「GO!」ボタンをクリック。

Internet Archive

下のようなグラフと一緒にカレンダーの一覧が表示されます。このブログを始めたのは2011年の5月ですが、グラフを見ると「Internet Archive」に保存されたのは2011年の末からのようです。

検索結果

ということで2011年の、このブログを見てみます。グラフは現在(2013年)を指しているので、2011年をクリックします。ちょっとモタつくかもしれませんが、ページのカレンダーが2011年の一覧に変わります。

カレンダー

カレンダーの日付が水色になっているのが、保存されているデータのある日です。それによると、このブログがはじめてアーカイブされたのは2011年12月22日のようです。

その日付をクリックしてみます。出ました。懐かしい画面。当時のレイアウトのこのブログです。

2011年12月22日のレイアウトの、このブログ

今度は、今年のカレンダーから1月17日を選択。確かに今年1月のレイアウトです。

2013年1月17日のレイアウトの、このブログ

このようにして「Internet Archive」では古いWebページを探して見ることが出来ます。誰でも無料で使えますので、困ったときは利用してみてはいかがでしょう?