A JSON text can be safely passed into JavaScript's eval() function (which compiles and executes a string) if all the characters not enclosed in strings are in the set of characters that form JSON tokens. This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods.
var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')');
XMLのコストが高いのはわかるが (スコア:0)
Re:XMLのコストが高いのはわかるが (スコア:0)
君のお腹が一杯になると、何か解決するの？
君の許容量が低いだけ？
恐らく、こういったのはシステム全体を含めた上手い解決策がでるまで、
何回でも何年でもやり続ける作業だと思います。
その解決策が使えるのは、せいぜい数年かもしれませんが…
Re:XMLのコストが高いのはわかるが (スコア:2, すばらしい洞察)
YAML や JSON じゃだめなの？ 正直，XDR とか ASN でもいいと思うんだけど…
XML 対 非XML という対比については分かりやすいのだけど，非 XML 同士では流派の
違いというか，審美観の問題になっている気がするです．
Re:XMLのコストが高いのはわかるが (スコア:2, 興味深い)
プロトコルバッファはVariant型でデータ長を持たない可変長の符号化を行ってる点で他のどれよりも短いデータ長になるから、データが１バイトでも短いとスループットが大きく変わるくらい流量の多いシステムではかなりコスト減につながってると思うぜ。
符号化・復号化時の速度低下も小さそうだし、このあたりはうまいね。
他のじゃこうはいかない。どれもデータかライブラリか仕様が太ってる。
Re:XMLのコストが高いのはわかるが (スコア:1)
このエンコード方法だとデータサイズが 7 * 32bit や 7 * 64bit などを超えた段階で「他のどれよりも短いデータ長」と言うのは無理が出てきませんか? 単純に長さの情報 + バイナリ列の方がトータルサイズが短くなってしまいます。
ある程度のサイズになると、同じ方式で「データバイト長を」エンコードして、その後実データをバイナリ列で付加した方が全データ長は短くなるように思えるのですが。
もちろん、データの性格 (流すデータの各フィールド長が短いものがどれだけ多いか等) で総データ長に差が出てくるので、小さいデータが大半を占める場合にはトータルで短くなると思いますが。
Re:XMLのコストが高いのはわかるが (スコア:1)
そもそも64ビットを超えません。ただ「どれよりもは」ちょっと言いすぎだったかもね。サイズの面ではASN.1のPERではメッセージの定義しだいで一長一短だし。
でも速度サイズ比ではプロトコルバッファが優勢じゃないかな。サイズでASN.1 PERが勝つ場合はビット操作の回数がかなり多そうだ。
Re: (スコア:0)
Varintな
XMLもコンパイルなり前処理して受け渡しすれば軽くもなりそうだが…
Re: (スコア:0)
Re:XMLのコストが高いのはわかるが (スコア:1, 参考になる)
To understand your simple protocol buffer encoding, you first need to understand varints. Varints are a method of serializing integers using one or more bytes. Smaller numbers take a smaller number of bytes. [google.com]
まとめとくと
Re:XMLのコストが高いのはわかるが (スコア:2, 参考になる)
Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。端的な違いとして、 YAML や JSON では符号化後のデータがテキストですが、 protocol buffers では符号化後のデータがバイナリーです。
XDR とか ASN.1 とかは名前しか知りません。誰か protocol buffers がこれらと比較してどうなのか教えてください。
Re:XMLのコストが高いのはわかるが (スコア:1, 参考になる)
どちらもCで使われるデータ構造(struct含む)に毛が生えたようなものをそのままシリアライズしているので、
スキーマが存在しません。
それでだめだったんでしょう。
Re:XMLのコストが高いのはわかるが (スコア:1)
もしよければ、「スキーマが存在しないので駄目」というのをもう少し詳しく教えてもらえないでしょうか。
protocol buffers は、プログラムのバージョンが上がって新しい形式のデータと古い形式のデータを話すプログラムが混在しても大丈夫なように設計されているようです。 XDR や ASN.1 はそうなっていないという意味でしょうか。
Re: (スコア:0)
私の記憶が確かならば、XDRやASN.1は構造体のフィールド名などは保持せず、ただのシリアライズだったはずです。
これではフィールドが変更されると互換性がなくなるでしょう。
スキーマというほどのものではないですが、protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。
いずれにしろ8ビット機時代を思わせる原始的なフォーマットですが、十分実用的で高性能というのはなかなか気の利いた話で、
Googleのような影響力のあるところが公開したのは喜ばしいことだと思います。
Re:XMLのコストが高いのはわかるが (スコア:1)
説明ありがとうございます。よくわかりました。スキーマと聞いてフィールド名や型の情報を連想してしまい、そんなの protocol buffers でも送信されないよなあ、もしかして .proto ファイルのことか? などと少し混乱しかけていました。
たしかにそうですね。
今までも小型で高性能で拡張性のあるシリアライズ方式が必要な場面ではあちこちで似たようなシリアライズ方式が考案されコードが書かれてきたのでしょうから、 protocol buffers の方式とコードが公開されてすぐに何かに活用されるかどうかはわかりませんが、方式やコードを自前で用意する代わりに公開されているものを採用するという選択肢が増えるのは良いことだと思います。
Re:XMLのコストが高いのはわかるが (スコア:1)
これではフィールドが変更されると互換性がなくなるでしょう。
ASN.1では抽象構文自体にメッセージの将来的拡張の可能性を明記するので、拡張後のデコーダなら拡張前とはデータに互換性があり、逆の場合は非互換です。
> protocol buffersではすべてのデータにはフィールド番号がついていますので、
フィールドが変更されても「知らないフィールドは素通しする」で互換性は取れると思います。
プロトコルバッファのプロトコル定義構文からはフィールド番号を指定できないので、メッセージ中の追加フィールド挿入位置により、それより後ろの既存フィールドのフィールド番号が必ずずれると考えていいので、フィールド番号は互換性維持に使えないと思っていいんじゃないかな。メッセージ番号が存在しないのでフィールド番号はどのメッセージのデータかを判別するために使用する物だと思うよ。
（公開されているジェネレータを使わずにエンコードだけ借りるなら話は別だけど）
Re:XMLのコストが高いのはわかるが (スコア:1)
protocol buffers のドキュメントを斜め読みしてみました。
何か誤解しているように思います。 .proto ファイルの language guide [google.com] によれば、 .proto ファイルでは各フィールドに明示的にタグ (メッセージ中のフィールドを識別する番号) を指定します。 #1383160 [srad.jp] の人が「フィールド番号」と呼んでいるものは protocol buffers のタグと同一だと思います。デコーダーは符号化されたデータの中のタグを見て、自分の知らないタグが付いたフィールドをスキップするようで、これによって将来フィールドが追加された場合に新しいデータを古いデコーダーに読ませても大丈夫になっているようです。
また、 protocol buffers のタグは一つのメッセージの中でしか一意でないので、タグを見てメッセージを判別することはできません。デコーダーを呼び出す前に、これから復号しようとするメッセージの型を知っている必要があります。
Re: (スコア:0, おもしろおかしい)
ホントにそれが目的？
そうか！JavaScript なら eval すればオブジェクトのデコードができるものね。
すごいねっ
Re:XMLのコストが高いのはわかるが (スコア:2, すばらしい洞察)
はい。
まあ、 JavaScript はスクリプト言語なので、それくらいのことはできて当然というのが僕の印象ですが……。
Re: (スコア:0)
Re: (スコア:0)
設問が難問なほど、皮肉ってのは生きるものだよ？
eval (スコア:0)
汚染されている可能性がある．JavaScript で JSON データを扱う時でも，そのまま
eval するべきではない．実際，JavaScript で書かれた JSON パーサの実装が複数公開
されている．
JSON の魅力は誰かが「サニタイズ，サニタイズ」と叫んでる間にも，比較的セキュアな
簡易パーサが書けてしまうシンプルさにあると思う．
そのための適当な語彙をもったもので，親近性の高いものが JavaScript (ECMAScript)
だっわけで，JSON が JavaScript と文法上の互換性を持つのは，いわば目的ではなく
手段だったのではないか．
Re:eval (スコア:2, 興味深い)
信頼できないデータを eval するのはセキュリティー上問題があるというのはもちろんですが、僕の元コメント (#1382507) [srad.jp] に対する批判としては的外れです。 #1382507 では、リンクを張った RFC 4627 の 1 節にも書いてある「JSON の design goal は JavaScript のサブセットにすること」という事実を書いただけなので。ただ、 design goal を「目的」と訳したのは不適切だったかもしれません。
RFC 4627 の 1 節より:
また、 RFC 4627 の 6 節を読めば JSON の設計において eval を使って復号できることが意図されていることがわかります。
個人的な好みを書けば、僕は eval が嫌いなので、データが信頼できてもできなくても eval で復号するのは嫌いです。また、信頼できないデータについては、 6 節に書いてあるようなテストで JavaScript の将来のバージョンにわたって安全性が保証されるとも思えませんし。
Re: (スコア:0)
> ... JSON の目的は JavaScript の式として解釈できることで、どちらも目的が違います。
> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
JSON の目的として「minimal, portable, textual」という事実はなかったことに？
比較するときに，明らかに違うところだけに目を向けてもあまり意味がないのでは…
JSON が JavaScript のサブセットとなっていることは大きな特徴の一つだと思いますが，
他のシリアライズ手法と比較するときにそこだけ挙げるのは「的外れ」だと思いました．
Re:eval (スコア:1)
誤解です。 #1382507 [srad.jp] の書き方が少しわかりにくかったのは認めます。 #1382507 の
の部分を以下のように訂正すれば満足していただけるでしょうか。
でも、 #1382507 の当該部分が #1382417 [srad.jp] の
を受けて書かれていることは理解可能だと思うので、多少わかりにくかったという事実を前提としても、なぜこれほどまで誤解されるのか、よくわからなかったりします。