3

JSON はデータ交換においてますます重要になってきていますが、JSON 仕様はいくつかの点でかなり緩いです:

オブジェクト内の名前は一意である必要があります。

実装は、受け入れるテキストのサイズに制限を設定する場合があります。実装では、ネストの最大深さに制限を設定できます。実装によって、数値の範囲に制限が設定される場合があります。実装によって、文字列の長さと文字の内容に制限が設定される場合があります。

ほとんどの JSON パーサーは重複したオブジェクト キーを無視し、マイナス ゼロ (-0) とゼロを区別しないと思います。ほとんどの場合、数値を 32 ビット浮動小数点数または符号付き整数に制限する場合もあります。さらに、JSON には、有効な Unicode コード ポイントではない文字を含めることができます (この質問を参照してください)。また、基本多言語面 (U+0000 から U+FFFF) を超える Unicode 文字に関して実装に問題がある可能性があるに違いありません。しかし、JSON 仕様でもありません。CouchDB、MongoDB、Persevere/Dojo などの JSON データベースも制限を追加します。各システムで特別な意味を持つ可能性があるため、すべての JSON ストアでid、_id、およびのようなオブジェクト キーを使用できるとは思えません。$ref

これはなんとなくイライラします。JSON は簡単なはずですが、よく見ると多くの障害が見つかります。すべてのパーサーとデータベースで安全に使用できる JSON の一般的な (あまり制限されていない) サブセットはありますか?それとも、NoSQL の動きにより、JSON ドキュメントで使用してはならない拡張機能と特別な構造がますます追加されますか?

4

1 に答える 1

1

一般的に、No.

確かに、かなりの数のバグがあります (たとえば、MongoDBString Parse Errorは 64 ビットの符号なし INT より大きい数値を返します)。これらのいくつかはエラーですが、他のものはプラットフォーム固有の制限です - 他の重要なコンピュータ システムと同様です。

しかし、JSON の「安全なサブセット」を定義することは、一般的には考えられません。JSON スキーマを取得することはできますが、世界中のすべての人がすべきこととすべきでないことに同意することはまずありません。

大まかに言うと、JSON は固有の制限がないため人気があります。(ex. ASN.1 や XML とは対照的に。)

于 2011-05-09T08:10:11.337 に答える