This document is hosted by
以下はRFC 4627「The application/json Media Type for JavaScript Object Notation (JSON)」の非公式な日本語訳です。この翻訳はIETFによって発行さ れるものではなく、RFCとしてはIETFにより発行されている原文を参照すべき です。しかし、このRFCを日本語を利用する人びとが理解する上では役立つこ とと期待し、この翻訳を公開します。
この翻訳は、下記URLを原文として、2008年1月23日に加藤仁が行いました。
http://www.ietf.org/rfc/rfc4627.txt
Network Working Group D. Crockford Request for Comments: 4627 JSON.org Category: Informational July 2006
このメモはインターネットコミュニティに情報を提供するが、 インターネットの標準を定義するものではない。再配布は自由。
Copyright (C) The Internet Society (2006).
JavaScript Object Notation (JSON) は、軽量、テキストベース、 言語非依存のデータ交換フォーマットで、ECMAScript に基づいている。 JSON は構造化されたデータを簡潔に表現する書式を定義する。
JSONは4種類のデータ型 (文字列、数値、boolean、null) と 2種類の構造型 (オブジェクト、配列) を表現することができる。 (※訳注：この文書で言うオブジェクト(object)はハッシュのこと)
文字列は0個以上のUnicode文字列である。[UNICODE]
オブジェクトは順不動の0個以上の名前と値のペアである。 名前は文字列、値は文字列・数値・boolean・null・オブジェクト・配列 のいずれかである。
配列は0個以上の値の順列である。
「オブジェクト」と「配列」はJavaScriptの用語である。
JSONは小さく簡単なテキスト形式で JavaScriptのサブセットである。
この文書の用語 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" はそれぞれ [RFC2119] の定義に従う。
この文書の文法は [RFC4234] の定義に従う。
JSON の文字列はトークンの並びである。トークンのセットには 6種類の構造化文字、文字列、数字と3種類のリテラル名がある。
JSON の文字列はオブジェクトまたは配列の並びである。
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 ; , カンマ (値の区切り)
それぞれの構造化文字の前後には下記空白文字を入れてもよい: (※訳注：ws = white space)
ws = *(
%x20 / ; スペース
%x09 / ; 水平タブ
%x0A / ; ラインフィード(LF)
%x0D ; キャリッジリターン(CR)
)
JSONの値は、オブジェクト・配列・数値・文字列・または 下記リテラル名のいずれかでなければならない。
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
オブジェクトの構造は、0個以上の値と名前のペア、またはメンバーを、 中括弧でくくって表わす。名前は文字列である。各名前の後に名前 と値を区切るコロンを書く。カンマは値と次の名前を区切る。 オブジェクト内の名前は一意(unique)であるべきである。(SHOULD)
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
配列はの構造は0個以上の値(要素)を角括弧でくくって表す。 各要素はカンマで区切る。
array = begin-array [ value *( value-separator value ) ] end-array
数値の表記はほとんどのプログラミング言語で使われているものと同じである。 整数部を基本に、マイナス記号、小数部、指数部を書くことができる。
8進数や16進数の表記は許されない。数値の先頭のゼロも許されない。
小数部はドットの後の1個以上の数字で表わす。
指数部は E (大文字小文字とも可)の後にプラスまたはマイナス記号(任意)、 その後に1個以上の数字で表わす。
数字として表わせない数値(無限やNaNなど)は許されない。 (※訳注：NaN = Not a Number = 非数値)
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
文字列はC言語で使われる方法と同様に、前後をダブルクォーテーションで くくって表わす。全てのUnicode文字列はダブルクォーテーションでくくる。 ダブルクォーテーション、バックスラッシュ、および全てのコントロール 文字(U+0000～U+001F)はエスケープする。
どんな文字でもエスケープ表記してよい。 UnicodeのBMP(U+0000～U+FFFF)に含まれる文字なら、 \u0000 (バックスラッシュ、小文字u、コードポイントを示す4桁数字) という6文字の書式になる。 16進数のA～Fを表わす文字は大文字でも小文字でもよい。 例えばバックスラッシュは "\u005C"と表わすことができる。 (※訳注：BMP = Unicodeの基本多言語面)
それとは別にバックスラッシュを使った一般的な2文字表記も使用できる。 例えばバックスラッシュのエスケープは "\\" と簡潔に表記できる。
UnicodeのBMPにない拡張文字をエスケープするためには、 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 改ページ U+000C
%x6E / ; n ラインフィード U+000A
%x72 / ; r キャリッジリターン U+000D
%x74 / ; t タブ U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \ エスケープ
quotation-mark = %x22 ; " クォーテーションマーク
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
JSON は Unicode で表記すべきである。(SHALL) デフォルトのエンコーディングは UTF-8 である。
JSON テキストの最初の2文字は常にASCII文字[RFC0020]であるため、 テキストがUTF-8、UTF-16(BE・LE)、またはUTF-32(BE・LE)かどうかは 最初の4オクテッドに現れるnullのパターンで判定できる。 (※訳注：BE・LEは Unicode のバイトエンコーディングの方法で、 それぞれ BE=ビッグエンディアン、LE=リトルエンディアン、を表わす)
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
JSONパーサーはJSONのテキストを別の形式に変換する。 JSONパーサーはJSONの全ての文法を解釈できなければならない。(MUST) JSONパーサーは拡張機能としてJSON以外の書式を解釈してもよい。(MAY)
実装によっては受け付けるテキストサイズに上限を設けてもよい。(MAY) 実装によっては受け付けるネストの深さに上限を設けてもよい。(MAY) 実装によっては受け付ける数値の桁数に上限を設けてもよい。(MAY) 実装によっては受け付ける文字列の長さに上限を設けてもよい。(MAY)
JSONジェネレータはJSONテキストを生成する。 生成されたテキストはJSONの文法に厳密に従っていなければならない。(MUST)
JSON text のMIMEタイプは application/json である。
タイプ名: application
サブタイプ名: json
必須パラメータ: 無し
任意パラメータ: 無し
エンコーディングの注意点: UTF-8の場合は8bit、UTF-16/UTF-32の場合はbinary:
JSON は UTF-8、UTF-16、UTF-32 のいずれかで表わされる。 UTF-8 の場合は8ビット互換であるが、UTF-16 または UTF-32 の場合は バイナリーになる。
セキュリティの注意点:
一般にスクリプト言語にはセキュリティの問題が起きやすい。 しかしJSONはJavaScriptのサブセットとはいえ、 代入や実行を含まない安全なサブセットである。
文字列としてくくられていない全ての文字がJSONのトークンを構成する 文字セットの中に含まれていれば、そのJSONテキストは JavaScript の 文字列をコンパイル実行する eval() 関数に安全に渡すことができる。 これは JavaScript では、次のようにふたつの正規表現と test()、replace() 関数を使って簡単に確かめることができる。
var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
eval('(' + text + ')');
※訳注：このJavaScriptコードでは、テキストからダブルクォーテーション でくくられた部分を取り去った文字列(test関数の引数=右辺)に、 JSONトークンとして有効な文字セット以外(test関数の親オブジェクト=左辺) の文字が含まれていればfalseとし、全て有効な文字であればJSON文字列を eval()でコンパイル生成したオブジェクトをセットしている。 (JSON文法が誤っていればそれはそれでeval()がエラーとなりfalseとなる)
相互運用性の注意点: 無し
文書番号: RFC 4627
このメディアタイプを使用するアプリケーション:
JSON は次のプログラミング言語でデータ交換に用いられてきた。 ActionScript, C, C#, ColdFusion, Common Lisp, E, Erlang, Java, JavaScript, Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, and Scheme.
追加情報:
マジックナンバー: 無し 拡張子: .json マッキントッシュファイルタイプコード: TEXT
連絡先:
Douglas Crockford
douglas@crockford.com
利用目的: 一般(COMMON)
利用制限: 無し
著者:
Douglas Crockford
douglas@crockford.com
変更管理:
Douglas Crockford douglas@crockford.com
6章参照
JSONオブジェクトの例:
{
"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]
}
}
Imageメンバーはオブジェクトである。
ImageオブジェクトのThumbnailメンバーもオブジェクトである。
ImageオブジェクトのIDsメンバーは数値の配列である。
二つのオブジェクトを含む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"
}
]
[ECMA] European Computer Manufacturers Association, "ECMAScript
Language Specification 3rd Edition", December 1999,
<http://www.ecma-international.org/publications/files/
ecma-st/ECMA-262.pdf>.
[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, <http://www.unicode.org/versions/Unicode4.1.0/>.
Douglas Crockford JSON.org EMail: douglas@crockford.com
Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).