アカウント名:
パスワード:
Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。端的な違いとして、 YAML や JSON では符号化後のデータがテキストですが、 protocol buffers では符号化後のデータがバイナリーです。
XDR とか ASN.1 とかは名前しか知りません。誰か protocol buffers がこれらと比較してどうなのか教えてください。
> JSON [ietf.org] の目的は JavaScript の式として解釈できる ホントにそれが目的？ そうか！JavaScript なら eval すればオブジェクトのデコードができるものね。
はい。
すごいねっ
まあ、 JavaScript はスクリプト言語なので、それくらいのことはできて当然というのが僕の印象ですが……。
信頼できないデータを eval するのはセキュリティー上問題があるというのはもちろんですが、僕の元コメント (#1382507) [srad.jp] に対する批判としては的外れです。 #1382507 では、リンクを張った RFC 4627 の 1 節にも書いてある「JSON の design goal は JavaScript のサブセットにすること」という事実を書いただけなので。ただ、 design goal を「目的」と訳したのは不適切だったかもしれません。
RFC 4627 の 1 節より:
JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
また、 RFC 4627 の 6 節を読めば JSON の設計において eval
> Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 > ... JSON の目的は JavaScript の式として解釈できることで、どちらも目的が違います。 > JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript. JSON の目的として「minimal, portable, textual」という事実はなかったことに？ 比較するときに，明らかに違うところだけに目を向けてもあまり意味がないのでは…
> Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 > ... JSON の目的は JavaScript の式として解釈できることで、どちらも目的が違います。
> JSON's design goals were for it to be minimal, portable, textual, and a subset of JavaScript.
JSON の目的として「minimal, portable, textual」という事実はなかったことに？ 比較するときに，明らかに違うところだけに目を向けてもあまり意味がないのでは…
誤解です。 #1382507 [srad.jp] の書き方が少しわかりにくかったのは認めます。 #1382507 の
YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。
の部分を以下のように訂正すれば満足していただけるでしょうか。
YAML [yaml.org] は設計上の目標の一つに可読性を、 JSON [ietf.org] は設計上の目標の一つに JavaScript の式として解釈できることを掲げており、どちらも protocol buffers とは設計上の目標が違います。
でも、 #1382507 の当該部分が #1382417 [srad.jp] の
YAML や JSON じゃだめなの？
を受けて書かれていることは理解可能だと思うので、多少わかりにくかったという事実を前提としても、なぜこれほどまで誤解されるのか、よくわからなかったりします。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
XMLのコストが高いのはわかるが (スコア:0)
Re: (スコア:0)
君のお腹が一杯になると、何か解決するの？
君の許容量が低いだけ？
恐らく、こういったのはシステム全体を含めた上手い解決策がでるまで、
何回でも何年でもやり続ける作業だと思います。
その解決策が使えるのは、せいぜい数年かもしれませんが…
Re: (スコア:2, すばらしい洞察)
YAML や JSON じゃだめなの？ 正直，XDR とか ASN でもいいと思うんだけど…
XML 対 非XML という対比については分かりやすいのだけど，非 XML 同士では流派の
違いというか，審美観の問題になっている気がするです．
Re: (スコア:2, 参考になる)
Protocol buffers は拡張性を持った方法でデータを小さく高速に符号化するための方式です。 YAML [yaml.org] の目的は拡張性と可読性、 JSON [ietf.org] の目的は JavaScript の式として解釈できることで、どちらも目的が違います。端的な違いとして、 YAML や JSON では符号化後のデータがテキストですが、 protocol buffers では符号化後のデータがバイナリーです。
XDR とか ASN.1 とかは名前しか知りません。誰か protocol buffers がこれらと比較してどうなのか教えてください。
Re: (スコア:0, おもしろおかしい)
ホントにそれが目的？
そうか！JavaScript なら eval すればオブジェクトのデコードができるものね。
すごいねっ
Re: (スコア:2, すばらしい洞察)
はい。
まあ、 JavaScript はスクリプト言語なので、それくらいのことはできて当然というのが僕の印象ですが……。
Re: (スコア:0)
Re: (スコア:0)
設問が難問なほど、皮肉ってのは生きるものだよ？
eval (スコア:0)
汚染されている可能性がある．JavaScript で JSON データを扱う時でも，そのまま
eval するべきではない．実際，JavaScript で書かれた JSON パーサの実装が複数公開
されている．
JSON の魅力は誰かが「サニタイズ，サニタイズ」と叫んでる間にも，比較的セキュアな
簡易パーサが書けてしまうシンプルさにあると思う．
そのための適当な語彙をもったもので，親近性の高いものが JavaScript (ECMAScript)
だっわけで，JSON が JavaScript と文法上の互換性を持つのは，いわば目的ではなく
手段だったのではないか．
Re: (スコア:2, 興味深い)
信頼できないデータを eval するのはセキュリティー上問題があるというのはもちろんですが、僕の元コメント (#1382507) [srad.jp] に対する批判としては的外れです。 #1382507 では、リンクを張った RFC 4627 の 1 節にも書いてある「JSON の design goal は JavaScript のサブセットにすること」という事実を書いただけなので。ただ、 design goal を「目的」と訳したのは不適切だったかもしれません。
RFC 4627 の 1 節より:
また、 RFC 4627 の 6 節を読めば JSON の設計において eval
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] の
を受けて書かれていることは理解可能だと思うので、多少わかりにくかったという事実を前提としても、なぜこれほどまで誤解されるのか、よくわからなかったりします。