Web2.0を活用する10の方法、その7
UJinn Competition

企画、「名作に隠されたメッセージを探せ!」

060213_084451  去年の夏に、「世界初?3Dブログエントリー」というエントリーを書いて以来、何とか大量生産する手法はないものかと考えていたのだが、今日、CSSのたまたま資料を読んでいて思いついたことがあったので、試しに作ってみたら、結構簡単にできてしまった。

 http://satoshi.blogs.com/3d/wagahai.html

 興味のあるウェブ・エンジニアの方はソースコードを見ていただければ一目瞭然だが、"position:relative" が全体のレイアウトに影響を及ぼさないという点を利用すると、こんなに簡単に「ステレオグラム」が作れてしまうのだ。

 「これで大量生産が出来る!」と思ったのだが、隠しメッセージが含まれた文章を作るのは結構大変である。そこで、思いついたのが、著作権の切れた小説などから、強引に隠しメッセージを拾い出す、というアイデアである。上の例は、夏目漱石の「我輩は猫である」の冒頭の文章から、無理やり拾い集めて作った文章を「隠しメッセージ」として浮き出させているのである。

 そこで、突然だが、読者の皆さんに一つお願いがある。青空文庫に行き、自分の好きな作品を選んでそこから無理やりに「隠しメッセージ」を探しだしていただきたいのである。まず母体となる文章(300~400文字程度)を作品の中から抜き出し、そこからさらに10~30文字の「隠しメッセージ」を拾い出すのである。

 そうやって見つけ出した「隠しメッセージの含まれた文章」は、このエントリーのコメント欄に投稿していただければ、私が上の例と同じ方法でステレオグラムに変換して、このブログで公開する。コメント欄に投稿していただく時には、母体となる文章をそのまま貼り付け、隠しメッセージとして抜き出す文字を【】で囲んでいただければよい。

 上の例を同じ方法で記述すると、以下のようになる。

 吾輩は猫である。名前はまだ無い。どこで生れたかとんと見当がつかぬ。【何でも】薄暗いじめじめした所でニャーニャー泣いていた事だけは【記憶している】。吾輩はここで始めて【人】間というものを見た。しかもあとで聞くとそれ【は】書生という人間中で一番獰悪な種族であったそうだ。この書生というのは時々我々を捕えて煮て食うという話である。しかしその当時は【何と】いう考【も】なかったから別段恐しいとも思わなかった。ただ彼の掌に載せられてスーと持ち上げられた時何だかフワフワした感じがあったばかりである。掌の上で少し落ちついて書生の顔を見たのがいわゆる人間というものの見始であろう。この時【妙なものだ】と思った感じが今でも残っている【。】

 そもそもメッセージなど隠されていない文章中に無理やりメッセージを探し出すという作業は、かなりクリエーティビティが必要な作業なので、週末に暇つぶしにでもやっていただけるとありがたい。

Comments

mrwk

これをつい自動化したくなるのがハッカーの性。

Satoshi

>これをつい自動化したくなるのがハッカーの性。

どちらの自動化でしょうか?与えられたテキストファイルからこの3Dメッセージを作るサービスなら私にも簡単に作れますが、青空文庫から指定したメッセージを含んだテキストを見つけてくれるプログラムは結構大変そうですね。出来れば、どなたか後者を作ってくれると助かります…

egg

いくつか試みましたが、ろくな文章になりません。
でも、楽しいです。
もう少し、試行錯誤してみます。

Maki

Satoshiさん、今回のテーマと関係ないのですが、IBM Researchが興味のある調査結果を公表しています。
2012年、TVは大きく変化している可能性があります。
*URL: http://www-1.ibm.com/services/us/imc/pdf/g510-6242-end-of-tv-sum.pdf

mahiran

今回の「我が輩は猫である」の文章は、以前のサンプルよりも飛び出し方が小さいような気がしますね。フォントの違いによるものでしょうか?

Satoshi

Makiさん、確かに興味ある調査結果ですね。色々と触発されます。

mahiranさん、飛び出し方は、隠し文字をどのくらい本来の位置からずらすか、によってきまります。今回は少し控えめにしすぎましたかね。

mrwk

とりあえず簡単な実装として".{0,100}?" のようなパターンを各文字の間に挟んだ正規表現を作ってそれで検索するpythonスクリプトを書いてみました。URLのところにスクリプトとテキストを置いています。コマンドライン引数とかはさぼっているので適当にコードを書き替えてください。

最大100文字スキップで「我輩は猫である」に対して「何でも記憶している人」を検索してみると3箇所みつかりました。
スキップできる文字数を500くらいにすると手元マシン(celeron2.7GHz)で2.3秒ほどかかって結果が出力されます。正規表現のバックトラック動作が重いのでしょう。
もうちょっと離れたものや、長いメッセージ、大量のテキストを扱おうとすると、対象テキストについて事前のインデックス作成がほしくなりそうです。

mrwk

一晩寝ながら(?)考えてみました、各文字ごとにファイルのIDと出現位置のリストへのハッシュを作っておけば、以下のような動作でなんとかなりそうな気がします。

1.ひと文字目の全出現位置に対応するノード群をつくって(各ノードはファイルIDと出現位置をおぼえておきます)
2.2文字目の出現位置群を与えてファイル名と出現位置が条件にあうもの(ファイル名が同じ、出現位置が今のより後、あまり離れすぎていない etc.)だけをtrieの要領で各ノードの後に追加する。対応する出現位置がなかった枝は切り捨てる。
3. 2を終端まで繰り返す

ただ、単純に上を実装すると、「あああああああああああああ」から
「ああああ」を検索するような、該当文字が多い時にメモリが悲惨なことになりそうなので、同じ場所にぶつかった時はその前の場所列から適当なものを枝刈りする仕掛けを入れたほうがいいかもしれません。

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)