図書館員のコンピュータ基礎講座

  • TOP
  • インターネット

【注意】 このドキュメントは、RFC 8259「The JavaScript Object Notation (JSON) Data Interchange Format」の和訳です。このドキュメントの正式版は英語版であり、このドキュメントには翻訳に起因する誤りがありえます。誤訳、誤植などのご指摘は、訳者までお願い致します。

First Update: 2019年9月26日

Internet Engineering Task Force (IETF)                      T. Bray, Ed.
Request for Comments: 8259                                    Textuality
Obsoletes: 7159                                            December 2017
Category: Standards Track
ISSN: 2070-1721

JSON(JavaScript Object Notation)データ交換フォーマット

要約

JSON(JavaScript Object Notation)は、軽くて、テキスト・ベースの、言語に依存しないデータ交換フォーマットです。これは、ECMAScriptプログラミング言語標準から派生しました。JSONは、構造化データをポータブルな表現のための小さなフォーマット規則を定義します。

このドキュメントは、JSONの他の仕様との矛盾を取り除き、仕様のエラーを修復し、経験に基づく相互運用性に関するガイダンスを提供します。

このメモのステータス

これはインターネット標準化過程ドキュメントです。

このドキュメントは、IETF(Internet Engineering Task Force)の成果物です。IETFコミュニティの合意事項を表します。これは公開レビューを受け、IESG(Internet Engineering Steering Group)により公開が承認されています。インターネット標準に関する詳細については、RFC 7841の2項で入手できます。

このドキュメントの現在のステータス、誤り、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8259で入手できます。

著作権表示

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Document (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

目次

  1. 1. はじめに
    1. 1.1. このドキュメントで用いる規定
    2. 1.2. JSONの仕様
    3. 1.3. この改訂の概要
  2. 2. JSONの文法
  3. 3. 値
  4. 4. オブジェクト
  5. 5. 配列
  6. 6. 数値
  7. 7. 文字列
  8. 8. 文字列と文字に関する課題
    1. 8.1. 文字エンコーディング
    2. 8.2. Unicodeの文字
    3. 8.3. 文字列の比較
  9. 9. パーサ
  10. 10. ジェネレーター
  11. 11. IANAに関する留意点
  12. 12. セキュリティに関する留意点
  13. 13. 例
  14. 14. 参考文献
    1. 14.1. 規範的な参考文献
    2. 14.2. 参考情報の参考文献
  15. 付録A. 7159以からの更新
  16. 貢献者
  17. 著者のアドレス

1. はじめに

JSON(JavaScript Object Notation)は、構造化データをシリアル化するためのテキストの形式です。これは、ECMAScriptプログラミング言語標準の第3版[ECMA-262]で定義されているJavaScriptのオブジェクト・リテラルから派生しています。

JSONは、4つのプリミティブ型(文字列、数値、ブール値、ヌル(null))と2つの構造化型(オブジェクトと配列)を表すことができます。

文字列は、0以上のUnicode文字[UNICODE]のシーケンスです。この引用参考文献は、特定リリースの版ではなく、Unicodeの最新版を参照していることに注意してください。Unicode仕様の将来の変更がJSONの構文に影響することは想定していません。

オブジェクトは、0以上の名前/値のペアの順不同のコレクションで、名前は文字列で、値は文字列、数値、ブール値、ヌル(null)、オブジェクトまたは配列です。

配列は、0以上の値の順序付きシーケンスです。

「オブジェクト」および「配列」という用語は、JavaScriptの規定に由来します。

JSONの設計目標は、最小で、ポータブルで、テキスト形式の、JavaScriptのサブセットにすることでした。

1.1. このドキュメントで用いる規定

このドキュメントの「しなければならない(MUST)」、「してはならない(MUST NOT)」、「必須である／要求される(REQUIRED)」、「することになる(SHALL)」、「することはない(SHALL NOT)」、「すべきである／する必要がある(SHOULD)」、「すべきでない／する必要がない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「推奨されない(NOT RECOMMENDED)」、「することができる／してもよい(MAY)」、「選択できる／任意である(OPTIONAL)」というキーワードは、ここで示しているようにすべて大文字で表示されている場合にのみBCP 14[RFC2119] [RFC8174]で記述されているように解釈されるべきです。

このドキュメントの文法規則は、[RFC5234]で記述されているように解釈されるべきです。

1.2. JSONの仕様

このドキュメントは[RFC7159]を置き換えるものです。当初、JSONを記述し、「application/json」というメディア・タイプを登録していた[RFC4627]は、[RFC7159]によって廃止されました。

JSONは[ECMA-404]にも記述されています。

前文のECMA-404への参照は、このドキュメントを理解するために実装者が参照する必要があるという通常の意味ではなく、いずれの仕様においても「JSONテキスト」という用語の定義には矛盾がないことを強調するために、規範的です。しかし、相互運用性を最大限に高めるためにこの仕様で避けることを推奨しているいくつかの実践が、ECMA-404では認められていることに注意してください。

これが意図するところは、2つのドキュメント間で異なる表現が用いられていても、文法は同じであるということです。もしも、それらの間に差異が見つかれば、ECMAとIETFは連携して両方のドキュメントを更新します。

いずれかのドキュメントでエラーが見つかれば、他方のドキュメントに同様のエラーがあるかどうかが確認されるべきであり、エラーがあれば、可能な限り修正されるべきです。

いずれかのドキュメントが将来的に変更された場合、ECMAとIETFは連携して、その変更があったとしても2つのドキュメントが同調し続けることを保証します。

1.3. この改訂の概要

RFC 4627の公開以来、長年に渡ってJSONは非常に広く使用されています。その経験から、仕様では認められているものの、相互運用性の問題を発生させる特定のパターンが明らかになりました。

また、RFC 4627(RFC正誤表ID 607[Err607]および3607[Err3607]を参照)に関して、また、RFC 7159(RFC正誤表ID 3915[Err3915]、4264[Err4264]、4336[Err4336]、4388[Err4388]を参照)に関して少数の誤りが報告されています。

このドキュメントの目標は、正誤表を適用し、JSONの他の仕様との矛盾を取り除き、相互運用性の問題につながりうる実装を明らかにすることです。

2. JSONの文法

JSONテキストはトークンのシーケンスです。トークンの集合には、6つの構造化型文字、文字列、数値、3つのリテラル名が含まれます。

JSONテキストはシリアル化された値です。JSONの以前の特定の仕様では、JSONテキストはオブジェクトまたは配列に制限されていたことに注意してください。JSONテキストを必要とするオブジェクトまたは配列のみを生成する実装は、すべての実装がこれを適合JSONテキストとして受け入れるという意味で相互運用可能です。

      JSON-text = ws value ws

以下が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 /              ; スペース
              %x09 /              ; 水平タブ
              %x0A /              ; 改行(Line feed)または埋め込み改行(New line)
              %x0D )              ; 復帰改行(Carriage return)

3. 値

JSONの値は、オブジェクト、配列、数値、文字列、または次の3つのリテラル名のいずれかでなければなりません(MUST)。

      false
      null
      true

リテラル名は小文字でなければなりません(MUST)。その他のリテラル名は認められていません。

      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

4. オブジェクト

オブジェクト構造は、0以上の名前/値のペア(またはメンバー)を囲む中括弧のペアとして表されます。名前は文字列です。それぞれの名前の後に1つのコロンが続き、名前と値が区切られます。1つのコンマは、値とそれに続く名前を区切ります。オブジェクト内の名前は一意であるべきです(SHOULD)。

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

      member = string name-separator value

名前がすべて一意であるオブジェクトは、そのオブジェクトを受け取るすべてのソフトウェアの実装が、名前-値のマッピングに合意しているという意味で相互運用可能です。オブジェクト内の名前が一意でなければ、そのようなオブジェクトを受け取るソフトウェアの動作は予測できません。多くの実装は、最後の名前/値のペアのみを報告します。その他の実装は、エラーを報告するかオブジェクトの解析に失敗しますが、重複を含むすべての名前/値のペアを報告する実装もあります。

JSON解析ライブラリによって、オブジェクトのメンバーの順序を、呼び出し元のソフトウェアに見せるかどうかという点に違いがあることが観察されています。動作がメンバーの順序に依存しない実装は、これらの違いの影響を受けないという意味で相互運用可能です。

5. 配列

配列構造は、0以上の値(または要素)を囲む角括弧として表されます。要素はコンマで区切られます。

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

配列内の値は同じ型である必要はありません。

6. 数値

数値の表現は、ほとんどのプログラミング言語で用いられているものと似ています。数値は、10進の数字を用いて10進数で表されます。オプションのマイナス記号を前に置くことができる整数コンポーネントが含まれ、その後に小数部や指数部を続けることができます。先行ゼロは認められていません。

小数部は、1つ以上の数字が続く小数点です。

指数部は大文字または小文字の文字Eで始まり、その後にプラス記号またはマイナス記号を続けることができます。Eとオプションの記号の後に1つ以上の数字が続きます。

次の文法で表現できない数値(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

この仕様により、実装では、受け入れられる数値の範囲と精度に制限を設定できます。IEEE 754のbinary64(倍精度)数[IEEE754]を実装しているソフトウェアは一般的に入手可能で広く用いられているため、予想される精度の範囲内で実装がJSON数値に近似するという意味で、提供する精度または範囲を超えないことを期待する実装は良好な相互運用性を実現できます。1E400や3.141592653589793238462643383279などのJSON数値は、潜在的な相互運用性の問題を示している可能性があります。なぜなら、それを作成したソフトウェアは、受信側のソフトウェアが、数値の大きさと精度に関し、広く利用可能なものよりも高い性能を有していることを期待していることを示唆するためです。

そのようなソフトウェアが用いられている場合、整数であり、[-(2**53)+1, (2**53)-1]の範囲にある数値は、実装がその数の値と厳密に一致するという意味で相互運用可能であることに注意してください。

7. 文字列

文字列の表現は、プログラミング言語のCファミリーで用いられている規定に似ています。文字列は、引用符で始まり、引用符で終わります。エスケープしなければならない(MUST)文字(引用符、バックスラッシュ、および制御文字(U+0000からU+0000))を除くすべてのUnicode文字を引用符内に置くことができます。

任意の文字をエスケープできます。文字が基本多言語面(U+0000からU+FFFF)にある場合、6文字のシーケンス(バックスラッシュの後に小文字のu、その後にその文字のコードポイントをエンコードした4桁の16進が続く)として表すことができます。16進文字のAからFは、大文字でも小文字でもかまいません。したがって、例えば、1つのバックスラッシュ文字のみを含む文字列は、「\u005C」と表すことができます。

または、いくつかのよく知られている2文字のシーケンス・エスケープ表現もあります。したがって、例えば、1つのバックスラッシュ文字のみを含む文字列は、「\\」と、よりコンパクトに表すことができます。

基本多言語面にない拡張文字をエスケープするためには、UTF-16サロゲート・ペアをエンコードした12文字のシーケンスとして文字を表します。したがって、例えば、ト音記号(U+1D11E)のみを含む文字列は、「\uD834\uDD1E」と表すことができます。

      string = quotation-mark *char quotation-mark

      char = unescaped /
          escape (
              %x22 /          ; "     引用符                    U+0022
              %x5C /          ; \     バックスラッシュ          U+005C
              %x2F /          ; /     スラッシュ                U+002F
              %x62 /          ; b     バックスペース            U+0008
              %x66 /          ; f     改ページ(Form feed)       U+000C
              %x6E /          ; n     改行(Line feed)           U+000A
              %x72 /          ; r     復帰改行(Carriage return) U+000D
              %x74 /          ; t     タブ                      U+0009
              %x75 4HEXDIG )  ; uXXXX                           U+XXXX

      escape = %x5C              ; \

      quotation-mark = %x22      ; "

      unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

8. 文字列と文字に関する課題

8.1. 文字エンコーディング

閉じたエコシステムの一部ではないシステムの間で交換されるJSONテキストは、UTF-8[RFC3629]を用いてエンコードしなければなりません(MUST)。

以前のJSON仕様では、JSONテキストの送信時にUTF-8を用いる必要はありませんでした。しかし、JSONベースのソフトウェア実装の大半は、UTF-8エンコーディングが相互運用性を実現する唯一のエンコーディングであるという程度にまでUTF-8エンコーディングの使用を選択しています。

実装では、ネットワーク送信されるJSONテキストの先頭にバイト・オーダー・マーク(U+FEFF)を追加してはなりません(MUST NOT)。相互運用性のために、JSONテキストを解析する実装は、バイト・オーダー・マークの存在をエラーとして扱うのではなく、無視することができます(MAY)。

8.2. Unicodeの文字

JSONテキストで表されるすべての文字列が完全にUnicode文字[UNICODE](エスケープされていたとしても)で構成されている場合、そのJSONテキストは、それを解析するすべてのソフトウェア実装がオブジェクトと配列内の名前の内容および文字列値の内容と一致するという意味で相互運用可能です。

しかし、この仕様のABNFでは、メンバー名と文字列値に、例えば、「\uDEAD」(ペアになっていない1つのUTF-16サロゲート)などの、Unicode文字をエンコードできないビット・シーケンスを含めることが認められています。例えば、切り捨てによってサロゲート・ペアが分割されるかどうかを確認せずに、ライブラリがUTF-16文字列を切り捨てたときに、このような事例が観察されました。このような値を含むJSONテキストを受信するソフトウェアの動作は予測できません。例えば、実装が文字列値の長さに対して異なる値を返したり、致命的なランタイムの例外が発生したりする場合があります。

8.3. 文字列の比較

通常、ソフトウェアの実装では、オブジェクト・メンバの名前が等しいかどうかをテストする必要があります。テキスト表現をUnicodeコード単位のシーケンスに変換した後に、コード単位ごとに数値で比較する実装は、実装が2つの文字列の同等性または不同等性に関して、すべての場合に一致するという意味で相互運用可能です。例えば、変換されていないエスケープ文字が含まれている文字列を比較する実装では、「a\\b」と「a\u005Cb」が等しくないと誤って検出される場合があります。

9. パーサ

JSONパーサは、JSONテキストを別の表現に変換します。JSONパーサは、JSON文法に準拠したすべてのテキストを受け入れなければなりません(MUST)。JSONパーサは、JSON以外の書式や拡張機能を受け入れることができます(MAY)。

実装は、受け入れるテキストのサイズに制限を設定できます。実装では、入れ子の最大深度に制限を設定できます。実装は、数値の範囲と精度に制限を設定できます。実装は、文字列の長さと文字の内容に制限を設定できます。

10. ジェネレーター

JSONジェネレーターはJSONテキストを生成します。その結果のテキストは、JSON文法に厳密に準拠しなければなりません(MUST)。

11. IANAに関する留意点

JSONテキストのメディア・タイプはapplication/jsonです。

タイプ名:
application
サブタイプ名:
json
必須パラメータ:
n/a
任意のパラメータ:
n/a
コード化に関する留意点:
binary
セキュリティに関する留意点:
RFC 8259の12項を参照
互換性に関する留意点:
RFC 8259に記載
公開済み仕様書:
RFC 8259
このメディア・タイプを使用するアプリケーション:
JSONは、ActionScript、C、C＃、Clojure、ColdFusion、Common Lisp、E、Erlang、Go、Java、JavaScript、Lua、Objective CAML、Perl、PHP、Python、Rebol、Ruby、Scala、Schemeのすべてのプログラミング言語で記述されたアプリケーション間でデータを交換するために用いられます。
追加情報:
マジック・ナンバー: n/a
ファイル拡張子: .json
マッキントッシュ・ファイル・タイプ・コード: TEXT
詳細情報に関する連絡先:
IESG
<iesg@ietf.org>
意図する使途:
COMMON
使用上の制限:
なし
著者:
Douglas Crockford
<douglas@crockford.com>
改版管理者
IESG
<iesg@ietf.org>

注: この登録では「charset」パラメータは定義されていません。これを追加しても、準拠する受信者には特に影響しません。

12. セキュリティに関する留意点

一般的に、スクリプト言語にはセキュリティ上の課題が存在しています。JSONはJavaScriptのサブセットですが、割り当てと呼び出しを除外しています。

JSONの構文はJavaScriptから借用しているため、その言語の「evaleval()」関数を用いてほとんどのJSONテキストを解析できます(ただし、すべてではありません。U+2028 LINE SEPARATORやU+2029 PARAGRAPH SEPARATORなどの特定の文字はJSONで有効ですが、JavaScriptではそうではありません)。テキストにはデータ宣言と共に実行可能なコードが含まれている可能性があるため、これは一般的に許容できないセキュリティ上のリスクとなります。他のプログラミング言語におけるeval()などの関数の使用にも、JSONテキストがその言語の構文に準拠している場合は、同じ留意点が適用されます。

13. 例

これはJSONオブジェクトです。

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

Imageメンバーは、Thumbnailメンバーがオブジェクトであり、IDsメンバーが数値の配列であるオブジェクトです。

これは、2つのオブジェクトを含むJSON配列です。

      [
        {
           "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"
        }
      ]

値のみを含む3つの小さなJSONテキストを次に示します。

   "Hello world!"

   42

   true

14. 参考文献

14.1. 規範的な参考文献

[ECMA-404]
Ecma International, "The JSON Data Interchange Format", Standard ECMA-404, <http://www.ecma-international.org/publications/ standards/Ecma-404.htm>.
[IEEE754]
IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629]
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[UNICODE]
The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

14.2. 参考情報の参考文献

[ECMA-262]
Ecma International, "ECMAScript Language Specification", Standard ECMA-262, Third Edition, December 1999, <http://www.ecma-international.org/publications/files/ ECMA-ST-ARCH/ ECMA-262,%203rd%20edition,%20December%201999.pdf>.
[Err3607]
RFC Errata, Erratum ID 3607, RFC 4627, <https://www.rfc-editor.org/errata/eid3607>.
[Err3915]
RFC Errata, Erratum ID 3915, RFC 7159, <https://www.rfc-editor.org/errata/eid3915>.
[Err4264]
RFC Errata, Erratum ID 4264, RFC 7159, <https://www.rfc-editor.org/errata/eid4264>.
[Err4336]
RFC Errata, Erratum ID 4336, RFC 7159, <https://www.rfc-editor.org/errata/eid4336>.
[Err4388]
RFC Errata, Erratum ID 4388, RFC 7159, <https://www.rfc-editor.org/errata/eid4388>.
[Err607]
RFC Errata, Erratum ID 607, RFC 4627, <https://www.rfc-editor.org/errata/eid607>.
[RFC4627]
Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487/RFC4627, July 2006, <https://www.rfc-editor.org/info/rfc4627>.
[RFC7159]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <https://www.rfc-editor.org/info/rfc7159>.

付録A. RFC 7159からの更新

この項では、このドキュメントとRFC 7159のテキストとの間の変更点を示します。

  • JSON仕様がECMA-262から削除されたことを反映し、ECMA-404を規範的な参考文献にし、「規範的」の特定の意味を説明するために1.2項を更新した。
  • RFC 4627ではなく、RFC 7159に対して提出された正誤表を反映するように1.3項を更新した。
  • ネットワークを介して送信する際にはUTF-8の使用が必要であるように8.1項を更新した。
  • ECMAScriptの「"eval()"」関数の使用に伴うセキュリティ上のリスクの説明の精度を向上させるために12項を更新した。
  • ECMA-404を規範的な参考文献として含むように14.1項を更新した。
  • ECMA-404を削除するために14.2項を更新し、ECMA-262のバージョンを更新し、正誤表を更新した。
貢献者

RFC 4627は、Douglas Crockfordによって作成されました。このドキュメントは、そのドキュメントに比較的小さな変更を加えて作成されました。したがって、ここの文章の大部分は彼に帰属します。

著者のアドレス 
   Tim Bray (editor)
   Textuality

   Email: tbray@textuality.com
ページのトップへ
CyberLibrarian : tips on computer for librarians, 1998-