[JavaScript] json parser、node.jsなど

2012/01/20

こんにちは。きんくまです。

JavaScriptをまた勉強しています。今回はだらだら日記です。

json_parser

この間本を買いました。
>> JavaScript: The Good Parts

そんで、この本の巻末にjsonのパーサーが載っていました。
調べてみたら、githubにあがってるやつでした。

>> douglascrockford / JSON-js

パーサーっていうのは、文字列を解析するものためのものです。
そんで、興味があったので、どうやってやっているのか、調べてました。

本にのってたのは、このページのやつでした。

これは、コードとしても短いので、みやすかったです。
コードが長くなっちゃうと、今見ているのが何をしているのか、わからなくなっちゃうのだけど、これは、そんなことがなかったです。
最後のところが何しているのかわからなかったけど、文字を1文字ずつ読み込んでいって、それが何を表すか評価をしていっていることがよくわかりました。
コードみただけじゃわかんなかったので、console.logさしこんで確認していったのですけどね、、。
前に、syntaxhighlighterみたいのって作ってみたいなーと思ったことがあったのだけど、どうやっていいのかわからなかったのですが、こうやって解析していけば、できそうな気がします。

node.js

前にCoffeeScriptを試したくて、入れたnode.jsでしたが、チュートリアルの動画をみていたら、nodeそのものに興味がわいてきました。

チュートリアルの動画
Homepage – Node Tuts – Node.js Free screencast tutorials

EPISODE 8ぐらいまでみたところ。
スクリーンキャプチャしながらコメントしているので、タイプミスやコードエラーもよくあるのだけれど、それをすぐに直してるところが、なんかリアルっていうか。楽しい感じです。

TextMateを使っているようなので、私も真似して体験版を使ってみました。
そしたら、なんかよさそうだったので、購入しました。
Aptanaの方が高機能なのだけど、TextMateは軽いのでよし。
前のバージョンでは2バイトがうまく表示できなかったみたいだけど、TextMate2が出ていて、そっちはうまく表示できているので、よし。
でも、表示はよいのだけど、日本語入力がうまくいかないのです。Ctrl+mでないと確定できないので、これで長文はかけないという、、。
バグというかそのことを開発元に伝えたいのだけど、どこに書けば良いのだろう?

>> TextMate 2 がやってきた | イナヅマtvログ

それで、node.jsのチュートリアルページも一通りやってみました。

チュートリアルのページ
The Node Beginner Book

チュートリアルのページをやると、どうやって他のjsを読み込んだりするかっていう基本的なことがわかります。

node.jsの何に興味をひかれたかというと、サーバーが簡単に作れるというところです。
httpサーバー、socketサーバー、websocketサーバー。
socketサーバーができるということは、flashとも簡単に通信ができるんです。
websocketのサーバーをたてれば、jsともソケット通信ができるという。

そんで、websocketについて調べてました。
まだ仕様は確定していないので、各ブラウザによって使っている仕様のバージョンが違います。

このページがよくわかりやすいです。
>> Jettyで始めるWebSocket超入門

仕様書をもとに、自分でサーバー側を書いてみようと思いました。(クライアント側のJavaScriptはわりと簡単。ブラウザが難しいところやってくれるからね! )

現在のChrome(16.0.912.75)の仕様書はこれ(iOSのsafariはまた違うバージョンで互換性なし!)
The WebSocket protocol draft-ietf-hybi-thewebsocketprotocol-13

仕様書にはプロトコルが書かれています。
プロトコルっていうのは、通信の手順のとりきめですね。
電話のかけかただったら、受話器をとってから番号を押すみたいな、そういう手順です。

Websocketのこれには2つの段階があります。
1. ハンドシェイク(握手。接続を確立するまで)
2. 実際のデータの送受信(フレームと言われる単位で行う)

そんで、wiki見ながらハンドシェイクまでは自力で実装できたのだけど、データの送受信がどうやってやるのかわからず。
チュートリアル動画にもあったSocket.ioのソースコードを見てみることに。

最初は何をやっているのかわからなかったのですが、ビット演算をしているらしい。
ビット演算子

フレーム構造はこうやって書かれています。

>>http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-13#section-5.2

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-------+-+-------------+-------------------------------+
     |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
     |I|S|S|S|  (4)  |A|     (7)     |             (16/63)           |
     |N|V|V|V|       |S|             |   (if payload len==126/127)   |
     | |1|2|3|       |K|             |                               |
     +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
     |     Extended payload length continued, if payload len == 127  |
     + - - - - - - - - - - - - - - - +-------------------------------+
     |                               |Masking-key, if MASK set to 1  |
     +-------------------------------+-------------------------------+
     | Masking-key (continued)       |          Payload Data         |
     +-------------------------------- - - - - - - - - - - - - - - - +
     :                     Payload Data continued ...                :
     + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
     |                     Payload Data continued ...                |
     +---------------------------------------------------------------+

node.jsのBufferクラスの最小単位は8bit(Octetというらしい)なので、ビット単位のデータを検証したり、埋め込んだりするには、ビット演算が必要になるんですね。
それがわかってしまえば、結構楽しいです。

例えばopcodeという、これからくるデータが何を表すのかがあります。
それを抜き出すには、下位4ビットが必要なので、

opcode = buffer[0] & 0xf

としてあげるとよいです。

データがマスクされているかを示すMASKを取り出すには、

masked = buffer[1] & 0x80

となります。ビット演算やってたら「おお、俺いまプログラマっぽいことしてる!」という、俺イメージの中のプログラマの像に重なってうれしくなりました。

Chromeとはなんとか通信できるようになったのですが、iOSとつなぐのはまた調べないといけないことが多いので、素直にSocket.io使おうかどうか迷うところ。使った方が断然簡単なのだけど、構造を勉強しながら作ると大変な分、得るものが多いので悩みどころですね。

それで、話かわりまして、宣伝といいますか、
今度f-siteでしゃべる機会を得ましたので、この辺をからめて発表してみようと思っています。
お題はjsflなのですけど、無理矢理からめちゃえと。ちなみにdemo2です。

あと、またまた全然話し変わって。
flashとhtml5って比較が出てくるのですけど、最近思うのは、flashというよりはAIRとhtml5って言う方がしっくりくるんじゃないかということです。
描画の速度はもちろんflashの方が上だったり、音声・動画関係のバツグンの安定感もflashが上なのですが、ファイルの保存とか今回のソケットだとか、DBとか含めて考えると、flashっていうより、AIRかと。

あと、いくつかJSのライブラリを見ていると、実は裏で代替機能としてflash使っているものって結構あるのですよね。Socket.ioもそうなんですよ。

自分は別にflashでもhtml5でもどっちの肩をもつつもりもないのですけど、ブラウザネイティブに機能が追加されてきているのは、面白い動きだと思います。
ただ、クロスブラウザを考えると実案件は当分先になるでしょうね。
でもでもiOSやandroidにしぼった形ならかなり近そうです。

今はnodeとJavaScriptそのものをもう少しやってみたいので、しばらく続けたいなと思ってます。

LINEで送る
Pocket

自作iPhoneアプリ 好評発売中!
フォルメモ - シンプルなフォルダつきメモ帳
ジッピー電卓 - 消費税や割引もサクサク計算!

ページトップへ戻る