[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
INTERNET STANDARD
Errata ExistInternet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 8259 Textuality
Obsoletes: 7159 December 2017
Category: Standards Track
ISSN: 2070-1721
JavaScriptオブジェクト表記（JSON）データ交換フォーマット
要約
JavaScript Object Notation（JSON）は、軽量でテキストベース、言語非依存のデータ交換フォーマットです。
これはECMAScriptプログラミング言語標準から派生しました。JSONは構造化データをポータブルに表現するための小さなフォーマットルールセットを定義します。
本文書は、他のJSON仕様との不整合の解消、仕様の誤りの修正、および経験に基づく相互運用性ガイダンスを提供します。
本メモのステータス
本文書はインターネット標準化過程（Standards Track）の文書です。
本文書はInternet Engineering Task Force（IETF）の成果物です。IETFコミュニティのコンセンサスを反映しており、
パブリックレビューを受け、Internet Engineering Steering Group（IESG）による公開承認を得ています。
インターネット標準規格の詳細はRFC 7841のセクション2をご覧ください。
本文書の最新状況、正誤表、フィードバック方法などは、https://www.rfc-editor.org/info/rfc8259で確認できます。
Bray Standards Track [Page 1]
RFC 8259 JSON December 2017
Copyright Notice
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 Documents
(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.
Bray Standards Track [Page 2]
RFC 8259 JSON December 2017
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 本文書で使用される規約 . . . . . . . . . . . . . . . 4
1.2. JSONの仕様 . . . . . . . . . . . . . . . . . . . . . 4
1.3. 本改訂の概要 . . . . . . . . . . . . . . . . . . . . 5
2. JSON文法 . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 値 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. オブジェクト . . . . . . . . . . . . . . . . . . . . . . 6
5. 配列 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. 数値 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. 文字列 . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. 文字列と文字に関する課題 . . . . . . . . . . . . . . . . 9
8.1. 文字エンコーディング . . . . . . . . . . . . . . . 9
8.2. Unicode文字 . . . . . . . . . . . . . . . . . . . . 10
8.3. 文字列の比較 . . . . . . . . . . . . . . . . . . . 10
9. パーサ . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. ジェネレータ . . . . . . . . . . . . . . . . . . . . . 10
11. IANA考慮事項 . . . . . . . . . . . . . . . . . . . . . 11
12. セキュリティの考慮事項 . . . . . . . . . . . . . . . . 12
13. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
14. 参考文献 . . . . . . . . . . . . . . . . . . . . . . 14
14.1. 引用規格 . . . . . . . . . . . . . . . . . . . . . 14
14.2. 参考情報 . . . . . . . . . . . . . . . . . . . . . 14
付録A. RFC 7159からの変更点 . . . . . . . . . . . . . . . 16
貢献者 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . 16
1. はじめに
JavaScript Object Notation（JSON）は、構造化データのシリアライズに用いるテキストフォーマットです。
これは、ECMAScriptプログラミング言語標準 第三版 [ECMA-262] で定義されたJavaScriptのオブジェクトリテラルに由来します。
JSONは4つのプリミティブ型（文字列、数値、ブール値、およびnull）と、2つの構造型（オブジェクトと配列）を表現できます。
文字列は、0個以上のUnicode文字 [UNICODE] からなるシーケンスです。
この参照は特定のリリースではなく、最新バージョンのUnicodeを指します。Unicode仕様の将来の変更がJSONの構文に影響を与えることは想定されていません。
オブジェクトは、0個以上の名前と値のペアからなる順不同のコレクションであり、名前は文字列、値は文字列、数値、ブール値、null、オブジェクト、または配列となります。
配列は、0個以上の値からなる順序付けられたシーケンスです。
Bray Standards Track [Page 3]
RFC 8259 JSON December 2017
「object（オブジェクト）」と「array（配列）」という用語は、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] を置き換えるものです。[RFC7159] は、元々JSONを定義し、メディアタイプ "application/json" を登録した [RFC4627] を廃止しました。
JSONは [ECMA-404] にも記載されています。
前の文で参照したECMA-404は、通常「実装者が本書を理解するために参照する必要がある」という意味での規範的参照ではなく、「JSON text」という用語の定義間に矛盾がないことを強調するための規範的参照となります。ただし、ECMA-404は本仕様が最大限の相互運用性のために避けることを推奨するいくつかの実践を許容している点に注意してください。
文法は両文書で同一となることを意図していますが、記述方法は異なります。もし相違が見つかった場合、ECMAとIETFは両方の文書を更新するために協力します。
いずれかの文書で誤りが発見された場合、もう一方にも同様の誤りがないか確認し、あれば可能な限り修正します。
今後いずれかの文書が変更される場合、ECMAとIETFは、両文書が変更を通じて整合性を保つよう協力します。
Bray Standards Track [Page 4]
RFC 8259 JSON December 2017
1.3. この改訂の概要
RFC 4627 の発行以来、JSONは非常に広く利用されるようになりました。この利用経験から、仕様上は許可されているものの、相互運用性の問題を引き起こすいくつかのパターンが明らかになりました。
また、RFC 4627 に関して少数のエラータも報告されています（RFC Errata ID 607 [Err607] および 3607 [Err3607] を参照）。さらに RFC 7159 に関しても、 RFC Errata 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 ; , カンマ
Bray Standards Track [Page 5]
RFC 8259 JSON December 2017
6つの構造文字の前後には、無視される空白文字（"insignificant whitespace"）を含めることができます。
ws = *(
%x20 / ; スペース
%x09 / ; 水平タブ
%x0A / ; ラインフィードまたは改行
%x0D ) ; 復帰
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
すべての名前が一意であるオブジェクトは、全てのソフトウェア実装において名前と値の対応が一致するという意味で相互運用性があります。
オブジェクト内の名前が一意でない場合、そのようなオブジェクトを受け取ったソフトウェアの挙動は予測できません。
多くの実装は最後の名前と値のペアのみを報告します。他の実装ではエラーを報告したり、パースに失敗する場合もあります。
Bray Standards Track [Page 6]
RFC 8259 JSON December 2017
オブジェクトについて、一部の実装では重複を含めたすべての名前と値のペアを報告するものもあります。
JSONパーシングライブラリによっては、オブジェクトメンバーの順序を呼び出し側ソフトウェアに見せるかどうか挙動が異なる場合があります。
メンバーの順序に依存しない実装であれば、この違いに影響されず相互運用性が確保されます。
5. 配列
配列構造は、角括弧で囲まれた0個以上の値（要素）として表現されます。要素同士はカンマで区切られます。
array = begin-array [ value *( value-separator value ) ] end-array
配列の中の値が同じ型である必要はありません。
6. 数値
数値の表現は、ほとんどのプログラミング言語で使われている形式と似ています。数値は10進法の数字を使い表現されます。整数部分があり、
先頭にオプションでマイナス記号を付けることができ、その後に小数部や指数部が続く場合があります。先頭に0を付けることはできません。
小数部は小数点の後に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
Bray Standards Track [Page 7]
RFC 8259 JSON December 2017
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系プログラミング言語の慣習に似ています。文字列は引用符で始まり、引用符で終わります。引用符内には、引用符、逆スラッシュ、制御文字（U+0000～U+001F）以外のすべてのUnicode文字を含めることができます。
それらの文字はエスケープする必要があります（MUST）。
どの文字もエスケープすることができます。もしその文字が基本多言語面（U+0000～U+FFFF）内であれば、逆スラッシュ、続いて小文字の u、
続いて4桁の16進数でそのコードポイントを表す6文字列として表現可能です。16進数のA～Fは大文字・小文字いずれも使用できます。例えば、
逆スラッシュ（\）1文字のみからなる文字列は "\u005C" として表せます。
また、よく使われる文字には2文字のエスケープ表現もあります。例えば、逆スラッシュ（\）1文字のみからなる文字列は、より簡潔に"\\" として表記できます。
Bray Standards Track [Page 8]
RFC 8259 JSON December 2017
基本多言語面（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
8. 文字列および文字に関する課題
8.1. 文字エンコーディング
閉じたエコシステムの一部ではないシステム間で交換されるJSONテキストは、UTF-8 [RFC3629] でエンコードしなければなりません（MUST）。
以前のJSON仕様では、JSONテキストの送信時にUTF-8の使用を必須とはしていませんでした。しかし、
ほとんどすべてのJSONベースのソフトウェア実装がUTF-8エンコーディングを選択しており、事実上これだけが相互運用性を確保できるエンコーディングとなっています。
実装は、ネットワーク越しに送信するJSONテキストの先頭にバイトオーダーマーク（U+FEFF）を追加してはなりません（MUST NOT）。
相互運用性の観点から、JSONテキストをパースする実装は、バイトオーダーマークが存在してもエラーとせず無視してもかまいません（MAY）。
Bray Standards Track [Page 9]
RFC 8259 JSON December 2017
8.2. ユニコード文字
JSONテキスト内のすべての文字列がユニコード文字 [UNICODE]
のみ（エスケープ形式も含む）で構成されている場合、そのJSONテキストは相互運用可能であり、
どのソフトウェア実装でもオブジェクトや配列内の名前および文字列の内容について一致した解釈となります。
しかし、本仕様のABNFではメンバー名や文字列値にユニコード文字として符号化できないビット列を含めることを許容しています。
例えば "\uDEAD"（単独のUTF-16サロゲート）。このような事例は、ライブラリがUTF-16文字列をサロゲートペアの分割を確認せずに切り詰めた場合などに見られます。
このような値を含むJSONテキストを受け取ったソフトウェアの挙動は予測できません。例えば、ある実装では文字列値の長さが異なったり、致命的なランタイム例外を発生させる場合もあります。
8.3. 文字列の比較
ソフトウェア実装には、オブジェクトメンバーの名前の等価性の判定が通常求められます。テキスト表現をユニコードのコードユニット列に変換し、
その上で数値的に（コードユニットごとに）比較する実装は、どの場合でも2つの文字列の等価性について一致した結果となるため、相互運用可能です。
例えば、エスケープされた文字を未変換のまま比較する実装では "a\\b" と "a\u005Cb" が等しくないと誤って判定される可能性があります。
9. パーサ
JSONパーサはJSONテキストを別の表現に変換します。JSONパーサはJSON文法に準拠したすべてのテキストを受け入れなければなりません（MUST）。
JSONパーサは非JSON形式や拡張も受け入れてもかまいません（MAY）。
実装は、受け入れるテキストのサイズに上限を設けることができます。また、ネストの最大深さの制限や、数値の範囲・精度の上限、
文字列の長さや内容に関する制限を設けることもできます。
10. ジェネレータ
JSONジェネレータはJSONテキストを生成します。生成されるテキストはJSON文法を厳密に満たさなければなりません（MUST）。
Bray Standards Track [Page 10]
RFC 8259 JSON December 2017
11. IANAに関する考慮事項
JSONテキストのメディアタイプは application/json です。
タイプ名: application
サブタイプ名: json
必須パラメータ: 該当なし
オプションパラメータ: 該当なし
エンコーディングに関する考慮事項: バイナリ
セキュリティに関する考慮事項: 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。
追加情報:
マジックナンバー: 該当なし
ファイル拡張子: .json
Macintoshファイルタイプコード: TEXT
詳細情報の問合せ先:
IESG
<iesg@ietf.org>
用途の意図: 共通（COMMON）
使用制限: なし
著者:
Douglas Crockford
<douglas@crockford.com>
変更管理者:
IESG
<iesg@ietf.org>
Bray Standards Track [Page 11]
RFC 8259 JSON December 2017
注意: この登録には "charset" パラメータは定義されていません。
これを追加しても、準拠した受信側には実質的な影響はありません。
12. セキュリティに関する考慮事項
一般的に、スクリプト言語にはセキュリティ上の問題があります。JSONはJavaScriptのサブセットですが、代入や呼び出しを除外しています。
JSONの構文はJavaScriptから流用されているため、多くのJSONテキストはその言語の "eval()" 関数でパースできます
（ただしすべてではありません。たとえばU+2028 LINE SEPARATOR や U+2029 PARAGRAPH SEPARATOR のような、一部の文字はJSONでは許可されますがJavaScriptでは許可されません）。
このような手法は、一般に受け入れ難いセキュリティリスクとなります。テキストにデータ宣言とともに実行可能なコードが含まれる可能性があるためです。
同様の配慮は、JSONテキストがその言語の構文に準拠している他のプログラミング言語でeval()のような関数を使う場合にも当てはまります。
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メンバーが数値の配列であるオブジェクトです。
Bray Standards Track [Page 12]
RFC 8259 JSON December 2017
これは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
Bray Standards Track [Page 13]
RFC 8259 JSON December 2017
14. 参考文献
14.1. 規範的参考文献
[ECMA-404] Ecma International, 「JSONデータ交換フォーマット」,
Standard ECMA-404,
<http://www.ecma-international.org/publications/
standards/Ecma-404.htm>.
[IEEE754] IEEE, 「IEEE 浮動小数点演算の標準」,
IEEE 754.
[RFC2119] Bradner, S., 「RFCsで要件レベルを示すキーワード」, BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997年3月,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., 「UTF-8, ISO 10646の変換フォーマット」, STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003年11月,
<https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., 編集. および P. Overell, 「構文仕様のための拡張BNF: ABNF」, STD 68, RFC 5234,
DOI 10.17487/RFC5234, 2008年1月,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., 「RFC 2119 キーワードにおける大文字・小文字の曖昧性」, BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2017年5月, <https://www.rfc-editor.org/info/rfc8174>.
[UNICODE] The Unicode Consortium, 「Unicode標準」,
<http://www.unicode.org/versions/latest/>.
14.2. 参考情報
[ECMA-262] Ecma International, 「ECMAScript言語仕様」,
Standard ECMA-262, Third Edition, 1999年12月,
<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>.
Bray Standards Track [Page 14]
RFC 8259 JSON December 2017
[Err4264] RFCエラータ, エラータID 4264, RFC 7159,
<https://www.rfc-editor.org/errata/eid4264>.
[Err4336] RFCエラータ, エラータID 4336, RFC 7159,
<https://www.rfc-editor.org/errata/eid4336>.
[Err4388] RFCエラータ, エラータID 4388, RFC 7159,
<https://www.rfc-editor.org/errata/eid4388>.
[Err607] RFCエラータ, エラータID 607, RFC 4627,
<https://www.rfc-editor.org/errata/eid607>.
[RFC4627] Crockford, D., 「JavaScriptオブジェクト表記(JSON)用メディアタイプ application/json」, RFC 4627,
DOI 10.17487/RFC4627, 2006年7月,
<https://www.rfc-editor.org/info/rfc4627>.
[RFC7159] Bray, T., 編集., 「JavaScriptオブジェクト表記(JSON)データ交換フォーマット」, RFC 7159, DOI 10.17487/RFC7159, 2014年3月,
<https://www.rfc-editor.org/info/rfc7159>.
Bray Standards Track [Page 15]
RFC 8259 JSON December 2017
付録A. RFC 7159からの変更点
このセクションでは、本書とRFC 7159の間の違いを示します。
o 1.2節は、ECMA-262からJSON仕様が削除されたことを反映し、ECMA-404を規範的参照とし、「規範的」の特定の意味を説明するよう更新されました。
o 1.3節は、RFC 4627ではなくRFC 7159に対して提出されたエラタを反映するよう更新されました。
o 8.1節は、ネットワーク越しに転送する際のUTF-8使用を必須とするよう変更されました。
o 12節は、ECMAScriptの「eval()」関数使用によるセキュリティリスクの記述精度を高めるように更新されました。
o 14.1節は、ECMA-404を規範的参照として追加するよう更新されました。
o 14.2節は、ECMA-404を削除し、ECMA-262のバージョンを更新し、エラタリストを刷新しました。
貢献者
RFC 4627はDouglas Crockfordによって執筆されました。本書はその文書に比較的少数の変更を加えて作成されており、ここに記載されている文章の大部分は彼のものです。
著者連絡先
Tim Bray（編集者）
Textuality
Email: tbray@textuality.com
Bray Standards Track [Page 16]