JavaScript++かも日記

【仕様】RFC4627 JSON

【JSON , 仕様 】 ブックマーク-- Buzzurl  / Hatena  / Livedoor

ざっくり訳:（p.s.手抜きでごめんなさい。とりあえずってことで。）

1.1.  Conventions Used in This Document（ここは、RFC文書についてのお約束なのでパス）

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The grammatical rules in this document are to be interpreted as
   described in [RFC4234].

2.  JSON Grammar JSON 文法 

JSON文字列は、トークンの連続です。トークンのセットは、6つの構造的キャラクタ、
strings、numbers、そして、 3つのリテラル名から成ります。

JSON文字列は、ひとつの連続したobject (オブジェクト)またはarray(配列)です。

     JSON-text = object / array

6つの構造的なキャラクタは次の通り

      begin-array 配列の始まり     = ws %x5B ws  ; [ 左の角括弧

      begin-objectオブジェクトの始まり    = ws %x7B ws  ; { 左の中括弧

      end-array 配列の終わり      = ws %x5D ws  ; ] 右の角括弧

      end-object オブジェクトの終わり     = ws %x7D ws  ; } 右の中括弧

      name-separator 名前の区切り = ws %x3A ws  ; : コロン

      value-separator 値の区切り= ws %x2C ws  ; , コンマ

(訳注:次の)無意味な空白が、6つの構造的なキャラクタの前または後にあっても許されます。

      ws = *(
                %x20 /              ; Space空白
                %x09 /              ; Horizontal tabタブ
                %x0A /              ; Line feed or New line改行
                %x0D                ; Carriage returnキャリッジリターン
            )

（訳注:ようするに、JSONは次の6つのキャラクタ「[」「{」「]」「}」「:」「;」「,」と「strings」と「numbers」と
「false 」と「true」と「null」の組み合わせで構成され、それは、ひとつの連続したobject (オブジェクト)
またはarray(配列)なのだぞと。で、空白、タブ、改行、キャリッジリターンは整形のためとかで、先の6つの
キャラクタの前後で適当に使ってもOK。みたいな?）

2.1.  Values 値

  JSONの値は、つぎのものでなければならない(MUST) 。object、array、number、または、 
string、あるいは、次の3つのリテラル名（訳注:「false 」か「true」か「null」）のひとつ。

  リテラル名は小文字でなければならない(MUST)。他のどんなリテラル名も許容されていない。
（訳注:つまり、たとえば、Ｗｉｎ風味の「FALSE」とか「NULL」は駄目で、「false」「null」と書くべし。
また、これら7種類以外のたとえば「undefined」とかも絶対使ってはいけないのでございマスト。
使いたければ、「"undefined"」などと書いてstringにするとか?)

         value = false / null / true / object / array / number / string

         false = %x66.61.6c.73.65   ; false

         null  = %x6e.75.6c.6c      ; null

         true  = %x74.72.75.65      ; true

2.2.  Objects　オブジェクト

　オブジェクトの構造は、ゼロ以上の名前と値のペアまたはメンバーを中括弧（{}）で括ります。
名前は文字列です。シングルコロン(:)が各名前のあとに続き、名前を値から区切ります。
シングルコンマセパレータ(,)が、次の名前から区切ります。オブジェクトの中の名前は
ユニーク(一意)であるべきです(SHOULD)。

      object = begin-object [ member *( value-separator member ) ]
      end-object

      member = string name-separator value

(訳注:つまり、たとえば、JSONのobject (オブジェクト)って次のようなもの。
      {}  とか
      {"test":123} とか 
      {"test1":123,"test2":"あいうえお","test3":false,"test4":null} とか
)

2.3.  Arrays 配列

   配列構造は、ゼロ以上の値か要素の周りに角括弧でくくります。要素はコンマで区切ります。

      array = begin-array [ value *( value-separator value ) ] end-array

(訳注:つまり、たとえば、JSONのarray (配列)って次のようなもの。
      [] とか
      [2003,2005,2006] とか 
      ["abc","def","ghi",200,null] とか
)

2.4.  Numbers 数値

  Numbersの表現はほとんどのプログラミング言語で使用されるそれと同様である。 
Numbersは小数部、そしてあるいは、指数部があとに続くかもしれない任意のマイナス記号が
前に置かれるかもしれない整数成分を含んでいる。

  8進と16進法表記は許容されていない。 先行ゼロ(数値の頭に0を置く)は許容されていない。

  小数部は、小数点の後ろに、ひとつ以上の0から9までの値が続きます。

  プラスかマイナス記号が上側か小文字の文字Eのあとに続いているかもしれない状態で、
指数部は始まる。  ひとつつ以上のケタ（0から9までの値）がEと任意のサインのあとに続いている。

  0から9までの値として表すことができない数値(InfinityやNaNなど)は受入れられない。

         number = [ minus ] int [ frac ] [ exp ]

         decimal-point = %x2E       ; .

         digit1-9 = %x31-39         ; 1-9

         e = %x65 / %x45            ; e E

         exp = e [ minus / plus ] 1*DIGIT

         frac = decimal-point 1*DIGIT

         int = zero / ( digit1-9 *DIGIT )

         minus = %x2D               ; -

         plus = %x2B                ; +

         zero = %x30                ; 0

2.5.  Strings 文字列

   string（文字列）の表現はプログラミング言語のCファミリーに使用される慣例と同様です。 
文字列は、最初と最後はコーテーションマーク(引用符）でくくります。すべてのユニコードキャラ
クタが引用符の中に置かれます。引用符や、バックスラッシュやその他制御文字（U+0000〜U+001F）は、
エスケープ文字を用いて表示しないといけません。　(訳注:あれ?ダブルコーテーションでは
なくなったの?、、、でも下のエスケープリストにあるのは二重引用符ですからやはり今までどおり
なのかな、、、?)
   あらゆるキャラクタはエスケープされるかもしれない。もし、キャラクタが、Basic Multilingual Plane
基本多言語水準（U+0000〜U+FFFF）に含まれるなら、
then it may be
   represented as a six-character sequence: a reverse solidus, followed
   by the lowercase letter u, followed by four hexadecimal digits that
   encode the character's code point.  The hexadecimal letters A though
   F can be upper or lowercase.  So, for example, a string containing
   only a single reverse solidus character may be represented as
   "\u005C".

   Alternatively, there are two-character sequence escape
   representations of some popular characters.  So, for example, a
   string containing only a single reverse solidus character may be
   represented more compactly as "\\".

   To escape an extended character that is not in the Basic Multilingual
   Plane, the character is represented as a twelve-character sequence,
   encoding the UTF-16 surrogate pair.  So, for example, a string
   containing only the G clef character (U+1D11E) may be represented as
   "\uD834\uDD1E".
  
         string = quotation-mark *char quotation-mark

         char = unescaped /
                escape (
                    %x22 /          ; "    quotation mark  U+0022（二重引用符）
                    %x5C /          ; \    reverse solidus U+005C（バックスラッシュ）
                    %x2F /          ; /    solidus         U+002F（スラッシュ）
                    %x62 /          ; b    backspace       U+0008（バックスペース）
                    %x66 /          ; f    form feed       U+000C（改ページ）
                    %x6E /          ; n    line feed       U+000A（改行）
                    %x72 /          ; r    carriage return U+000D（復帰）
                    %x74 /          ; t    tab             U+0009（タブ）
                    %x75 4HEXDIG )  ; uXXXX                U+XXXX（16進法表記）


         escape = %x5C              ; \

         quotation-mark = %x22      ; "

3.  Encoding エンコーディング

   JSONテキストはユニコードでコード化されるものとする。  デフォルト・コード化はUTF-8である。


   Since the first two characters of a JSON text will always be ASCII
   characters [RFC0020], it is possible to determine whether an octet
   stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
   at the pattern of nulls in the first four octets.

           00 00 00 xx  UTF-32BE
           00 xx 00 xx  UTF-16BE
           xx 00 00 00  UTF-32LE
           xx 00 xx 00  UTF-16LE
           xx xx xx xx  UTF-8

4.  Parsers

   A JSON parser transforms a JSON text into another representation.  A
   JSON parser MUST accept all texts that conform to the JSON grammar.
   A JSON parser MAY accept non-JSON forms or extensions.

   An implementation may set limits on the size of texts that it
   accepts.  An implementation may set limits on the maximum depth of
   nesting.  An implementation may set limits on the range of numbers.
   An implementation may set limits on the length and character contents
   of strings.

5. Generators

   A JSON generator produces JSON text.  The resulting text MUST
   strictly conform to the JSON grammar.

6. IANA Considerations

   The MIME media type for JSON text is application/json.

   Type name: application

   Subtype name: json

   Required parameters: n/a

   Optional parameters: n/a

   Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32

      JSON may be represented using UTF-8, UTF-16, or UTF-32.  When JSON
      is written in UTF-8, JSON is 8bit compatible.  When JSON is
      written in UTF-16 or UTF-32, the binary content-transfer-encoding
      must be used.

   Security considerations:

   一般的にスクリプト言語には、セキュリティ上の問題が存在します。 JSONは、JavaScriptの
サブセットですが、JSON自体は、JavaScriptから代入と呼び出しを取り除いた安全なサブセットです。

   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 + ')');

   Interoperability considerations: n/a

   Published specification: RFC 4627

Applications that use this media type:

　　JSONは、以下のプログラミング言語で書かれたアプリケーションとデータをやりとりするのに
使われています。： ActionScript, C, C#,ColdFusion, Common Lisp, E, Erlang, Java, 
JavaScript, Lua,Objective CAML, Perl, PHP, Python, Rebol, Ruby, and Scheme.

   Additional information:

      Magic number(s): n/a
      File extension(s): .json
      Macintosh file type code(s): TEXT

   Person & email address to contact for further information:
      Douglas Crockford
      douglas@crockford.com

   Intended usage: COMMON

   Restrictions on usage: none

   Author:
      Douglas Crockford
      douglas@crockford.com

   Change controller:
      Douglas Crockford
      douglas@crockford.com

7. Security Considerations

   See Security Considerations in Section 6.

8. Examples

   This is a JSON object:

   {
      "Image": {
          "Width":  800,
          "Height": 600,
          "Title":  "View from 15th Floor",
          "Thumbnail": {
              "Url":    "http://www.example.com/image/481989943",
              "Height": 125,
              "Width":  "100"
          },
          "IDs": [116, 943, 234, 38793]



Crockford                    Informational                      [Page 7]

RFC 4627                          JSON                         July 2006


        }
   }

   Its Image member is an object whose Thumbnail member is an object
   and whose IDs member is an array of numbers.

   This is a JSON array containing two objects:

   [
      {
         "precision": "zip",
         "Latitude":  37.7668,
         "Longitude": -122.3959,
         "Address":   "",
         "City":      "SAN FRANCISCO",
         "State":     "CA",
         "Zip":       "94107",
         "Country":   "US"
      },
      {
         "precision": "zip",
         "Latitude":  37.371991,
         "Longitude": -122.026020,
         "Address":   "",
         "City":      "SUNNYVALE",
         "State":     "CA",
         "Zip":       "94085",
         "Country":   "US"
      }
   ]

9. References

9.1.  Normative References

   [ECMA]    European Computer Manufacturers Association, "ECMAScript
             Language Specification 3rd Edition", December 1999,
             .

   [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
             October 1969.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4234] Crocker, D. and P.  Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 4234, October 2005.

   [UNICODE] The Unicode Consortium, "The Unicode Standard Version 4.0",
             2003, .

Author's Address

   Douglas Crockford
   JSON.org
   EMail: douglas@crockford.com

---

---

【コメント】(←clickで入力欄open)