RFC7159 7159.05 → 7159.06

Sign up to get free protection for your applications and to get access to all the features.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA1:
3
- metadata.gz: b662d283a8723554682d016119ce8459a88a1acc
4
- data.tar.gz: eda2d8e84dd1824e1eb698f1a428ebc00924af1d
3
+ metadata.gz: 37c19c8769ba8d1d4bb0880521eb86e397e8a274
4
+ data.tar.gz: 22b19292d8d0afea588f7bce6ae51e24a39bffef
5
5
  SHA512:
6
- metadata.gz: cfb49eb59408e63948ad0c574de89b0339dbcb26ccf983a01c67f23f6feb7b5c7aad238d27a18df1058ca0bfb41164c7063ad60e6b639989dafd0c5933fcc5b3
7
- data.tar.gz: 3e0df175d36f92735ed1d1dd70b38ad385888121fbc01742e54ec7eb3270328852afcaca39d58535c984a2c6d5e6fe4c25d0d8c2c2334899bc1152cad4a715ab
6
+ metadata.gz: f16b7687cf4b22ad1dfba11307f20767b72a3011a3fc138ca7f27976b115c0957b448255953a82414104167421de1040f5deb345ac3be2ae0f931762c942c439
7
+ data.tar.gz: cbf5512338b275d250e57d9456f21674e5c0272732ca482d030cece6a786b11038d57212e5bb8875ce6c965b7623ca35022ca6a06960d6e0e8067e67964520c4
@@ -0,0 +1 @@
1
+ ./RFC7159
@@ -64,13 +64,13 @@ Gem::Specification.new do |spec|
64
64
  spec.require_paths = %w'lib'
65
65
 
66
66
  spec.required_ruby_version = '~> 2.0'
67
- spec.add_development_dependency 'bundler', '~> 1.5'
68
- spec.add_development_dependency 'rake', '~> 10.1'
69
- spec.add_development_dependency 'rdoc', '~> 4.0'
70
- spec.add_development_dependency 'yard', '~> 0.8'
71
- spec.add_development_dependency 'rspec', '~> 2.14'
72
- spec.add_development_dependency 'simplecov', '>= 0'
73
- spec.add_development_dependency 'racc', '~> 1.4.11'
67
+ spec.add_development_dependency 'bundler'
68
+ spec.add_development_dependency 'rake'
69
+ spec.add_development_dependency 'rdoc'
70
+ spec.add_development_dependency 'yard'
71
+ spec.add_development_dependency 'rspec'
72
+ spec.add_development_dependency 'simplecov'
73
+ spec.add_development_dependency 'racc'
74
74
  # racc runtime is inside ruby's stdlib so no runtime dependency.
75
75
 
76
76
  # below are only for comparisons
@@ -61,7 +61,7 @@ module RFC7159
61
61
  # @param [Numeric] width page width (see {::PP})
62
62
  # @return [::String] Dumped valid JSON text representation
63
63
  # @return [port] Indicates the output went to the port.
64
- # @raise [TypeEeepe] obj not JSONable
64
+ # @raise [TypeError] obj not JSONable
65
65
  # @raise [Errno::ELOOP] Cyclic relation(s) detected
66
66
  def self.dump obj, port: ''.encode(Encoding::UTF_8), indent: 4, width: Math.atanh(1)
67
67
  bag = RFC7159::Dumper.new port, indent, width
@@ -32,7 +32,7 @@
32
32
  # POSSIBILITY OF SUCH DAMAGE.
33
33
 
34
34
  # The version
35
- RFC7159::VERSION = 7159.05
35
+ RFC7159::VERSION = 7159.06
36
36
 
37
37
  #
38
38
  # Local Variables:
@@ -105,7 +105,7 @@ describe RFC7159 do
105
105
  0.5 => '0.5', # 0.5 has no error
106
106
  'foo' => '"foo"',
107
107
  "\"\\\/\b\f\n\r\t"=> '"\"\\\/\b\f\n\r\t"',
108
- "\u{dead}" => '"\\uDEAD"', # invalid UTF8 to be valid escaped UTF8
108
+ "\xED\xBA\xAD".force_encoding('utf-8') => '"\\uDEAD"', # invalid UTF8 to be valid escaped UTF8
109
109
  'foo'.encode('utf-32le') => '"foo"',
110
110
  "\xDE\xAD".force_encoding('utf-16be') => '"\\uDEAD"',
111
111
  [] => '[ ]',
@@ -0,0 +1 @@
1
+ [0.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100e100]
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: RFC7159
3
3
  version: !ruby/object:Gem::Version
4
- version: '7159.05'
4
+ version: '7159.06'
5
5
  platform: ruby
6
6
  authors:
7
7
  - Urabe,
@@ -9,78 +9,78 @@ authors:
9
9
  autorequire:
10
10
  bindir: bin
11
11
  cert_chain: []
12
- date: 2015-04-07 00:00:00.000000000 Z
12
+ date: 2017-12-23 00:00:00.000000000 Z
13
13
  dependencies:
14
14
  - !ruby/object:Gem::Dependency
15
15
  name: bundler
16
16
  requirement: !ruby/object:Gem::Requirement
17
17
  requirements:
18
- - - "~>"
18
+ - - ">="
19
19
  - !ruby/object:Gem::Version
20
- version: '1.5'
20
+ version: '0'
21
21
  type: :development
22
22
  prerelease: false
23
23
  version_requirements: !ruby/object:Gem::Requirement
24
24
  requirements:
25
- - - "~>"
25
+ - - ">="
26
26
  - !ruby/object:Gem::Version
27
- version: '1.5'
27
+ version: '0'
28
28
  - !ruby/object:Gem::Dependency
29
29
  name: rake
30
30
  requirement: !ruby/object:Gem::Requirement
31
31
  requirements:
32
- - - "~>"
32
+ - - ">="
33
33
  - !ruby/object:Gem::Version
34
- version: '10.1'
34
+ version: '0'
35
35
  type: :development
36
36
  prerelease: false
37
37
  version_requirements: !ruby/object:Gem::Requirement
38
38
  requirements:
39
- - - "~>"
39
+ - - ">="
40
40
  - !ruby/object:Gem::Version
41
- version: '10.1'
41
+ version: '0'
42
42
  - !ruby/object:Gem::Dependency
43
43
  name: rdoc
44
44
  requirement: !ruby/object:Gem::Requirement
45
45
  requirements:
46
- - - "~>"
46
+ - - ">="
47
47
  - !ruby/object:Gem::Version
48
- version: '4.0'
48
+ version: '0'
49
49
  type: :development
50
50
  prerelease: false
51
51
  version_requirements: !ruby/object:Gem::Requirement
52
52
  requirements:
53
- - - "~>"
53
+ - - ">="
54
54
  - !ruby/object:Gem::Version
55
- version: '4.0'
55
+ version: '0'
56
56
  - !ruby/object:Gem::Dependency
57
57
  name: yard
58
58
  requirement: !ruby/object:Gem::Requirement
59
59
  requirements:
60
- - - "~>"
60
+ - - ">="
61
61
  - !ruby/object:Gem::Version
62
- version: '0.8'
62
+ version: '0'
63
63
  type: :development
64
64
  prerelease: false
65
65
  version_requirements: !ruby/object:Gem::Requirement
66
66
  requirements:
67
- - - "~>"
67
+ - - ">="
68
68
  - !ruby/object:Gem::Version
69
- version: '0.8'
69
+ version: '0'
70
70
  - !ruby/object:Gem::Dependency
71
71
  name: rspec
72
72
  requirement: !ruby/object:Gem::Requirement
73
73
  requirements:
74
- - - "~>"
74
+ - - ">="
75
75
  - !ruby/object:Gem::Version
76
- version: '2.14'
76
+ version: '0'
77
77
  type: :development
78
78
  prerelease: false
79
79
  version_requirements: !ruby/object:Gem::Requirement
80
80
  requirements:
81
- - - "~>"
81
+ - - ">="
82
82
  - !ruby/object:Gem::Version
83
- version: '2.14'
83
+ version: '0'
84
84
  - !ruby/object:Gem::Dependency
85
85
  name: simplecov
86
86
  requirement: !ruby/object:Gem::Requirement
@@ -99,16 +99,16 @@ dependencies:
99
99
  name: racc
100
100
  requirement: !ruby/object:Gem::Requirement
101
101
  requirements:
102
- - - "~>"
102
+ - - ">="
103
103
  - !ruby/object:Gem::Version
104
- version: 1.4.11
104
+ version: '0'
105
105
  type: :development
106
106
  prerelease: false
107
107
  version_requirements: !ruby/object:Gem::Requirement
108
108
  requirements:
109
- - - "~>"
109
+ - - ">="
110
110
  - !ruby/object:Gem::Version
111
- version: 1.4.11
111
+ version: '0'
112
112
  - !ruby/object:Gem::Dependency
113
113
  name: json
114
114
  requirement: !ruby/object:Gem::Requirement
@@ -306,6 +306,7 @@ files:
306
306
  - spec/acceptance/valid/0004-numbers/0023-UINT64_MAX.json
307
307
  - spec/acceptance/valid/0004-numbers/0024-INT64_MIN.json
308
308
  - spec/acceptance/valid/0004-numbers/0025-high-resolution-zero.json
309
+ - spec/acceptance/valid/0004-numbers/0026-high-resolution-100.json
309
310
  - spec/acceptance/valid/0005-strings/0001-empty.json
310
311
  - spec/acceptance/valid/0005-strings/0002-basic-latin.json
311
312
  - spec/acceptance/valid/0005-strings/0003-escapes.json
@@ -363,7 +364,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
363
364
  version: '0'
364
365
  requirements: []
365
366
  rubyforge_project:
366
- rubygems_version: 2.4.5
367
+ rubygems_version: 2.6.13
367
368
  signing_key:
368
369
  specification_version: 4
369
370
  summary: RFC7159 parser / generator
@@ -490,6 +491,7 @@ test_files:
490
491
  - spec/acceptance/valid/0004-numbers/0023-UINT64_MAX.json
491
492
  - spec/acceptance/valid/0004-numbers/0024-INT64_MIN.json
492
493
  - spec/acceptance/valid/0004-numbers/0025-high-resolution-zero.json
494
+ - spec/acceptance/valid/0004-numbers/0026-high-resolution-100.json
493
495
  - spec/acceptance/valid/0005-strings/0001-empty.json
494
496
  - spec/acceptance/valid/0005-strings/0002-basic-latin.json
495
497
  - spec/acceptance/valid/0005-strings/0003-escapes.json
@@ -527,4 +529,3 @@ test_files:
527
529
  - spec/acceptance/valid/0009-complicated/0002-example-in-RFC7159-section-13.json
528
530
  - spec/acceptance/valid/0009-complicated/0003-example-in-RFC7159-section-13.json
529
531
  - spec/spec_helper.rb
530
- has_rdoc:
data/README.txt DELETED
@@ -1,899 +0,0 @@
1
-
2
-
3
-
4
-
5
-
6
-
7
- Internet Engineering Task Force (IETF) T. Bray, Ed.
8
- Request for Comments: 7159 Google, Inc.
9
- Obsoletes: 4627, 7158 March 2014
10
- Category: Standards Track
11
- ISSN: 2070-1721
12
-
13
-
14
- The JavaScript Object Notation (JSON) Data Interchange Format
15
-
16
- Abstract
17
-
18
- JavaScript Object Notation (JSON) is a lightweight, text-based,
19
- language-independent data interchange format. It was derived from
20
- the ECMAScript Programming Language Standard. JSON defines a small
21
- set of formatting rules for the portable representation of structured
22
- data.
23
-
24
- This document removes inconsistencies with other specifications of
25
- JSON, repairs specification errors, and offers experience-based
26
- interoperability guidance.
27
-
28
- Status of This Memo
29
-
30
- This is an Internet Standards Track document.
31
-
32
- This document is a product of the Internet Engineering Task Force
33
- (IETF). It represents the consensus of the IETF community. It has
34
- received public review and has been approved for publication by the
35
- Internet Engineering Steering Group (IESG). Further information on
36
- Internet Standards is available in Section 2 of RFC 5741.
37
-
38
- Information about the current status of this document, any errata,
39
- and how to provide feedback on it may be obtained at
40
- http://www.rfc-editor.org/info/rfc7159.
41
-
42
-
43
-
44
-
45
-
46
-
47
-
48
-
49
-
50
-
51
-
52
-
53
-
54
-
55
-
56
-
57
-
58
- Bray Standards Track [Page 1]
59
-
60
- RFC 7159 JSON March 2014
61
-
62
-
63
- Copyright Notice
64
-
65
- Copyright (c) 2014 IETF Trust and the persons identified as the
66
- document authors. All rights reserved.
67
-
68
- This document is subject to BCP 78 and the IETF Trust's Legal
69
- Provisions Relating to IETF Documents
70
- (http://trustee.ietf.org/license-info) in effect on the date of
71
- publication of this document. Please review these documents
72
- carefully, as they describe your rights and restrictions with respect
73
- to this document. Code Components extracted from this document must
74
- include Simplified BSD License text as described in Section 4.e of
75
- the Trust Legal Provisions and are provided without warranty as
76
- described in the Simplified BSD License.
77
-
78
- This document may contain material from IETF Documents or IETF
79
- Contributions published or made publicly available before November
80
- 10, 2008. The person(s) controlling the copyright in some of this
81
- material may not have granted the IETF Trust the right to allow
82
- modifications of such material outside the IETF Standards Process.
83
- Without obtaining an adequate license from the person(s) controlling
84
- the copyright in such materials, this document may not be modified
85
- outside the IETF Standards Process, and derivative works of it may
86
- not be created outside the IETF Standards Process, except to format
87
- it for publication as an RFC or to translate it into languages other
88
- than English.
89
-
90
-
91
-
92
-
93
-
94
-
95
-
96
-
97
-
98
-
99
-
100
-
101
-
102
-
103
-
104
-
105
-
106
-
107
-
108
-
109
-
110
-
111
-
112
-
113
-
114
- Bray Standards Track [Page 2]
115
-
116
- RFC 7159 JSON March 2014
117
-
118
-
119
- Table of Contents
120
-
121
- 1. Introduction ....................................................3
122
- 1.1. Conventions Used in This Document ..........................4
123
- 1.2. Specifications of JSON .....................................4
124
- 1.3. Introduction to This Revision ..............................4
125
- 2. JSON Grammar ....................................................4
126
- 3. Values ..........................................................5
127
- 4. Objects .........................................................6
128
- 5. Arrays ..........................................................6
129
- 6. Numbers .........................................................6
130
- 7. Strings .........................................................8
131
- 8. String and Character Issues .....................................9
132
- 8.1. Character Encoding .........................................9
133
- 8.2. Unicode Characters .........................................9
134
- 8.3. String Comparison ..........................................9
135
- 9. Parsers ........................................................10
136
- 10. Generators ....................................................10
137
- 11. IANA Considerations ...........................................10
138
- 12. Security Considerations .......................................11
139
- 13. Examples ......................................................12
140
- 14. Contributors ..................................................13
141
- 15. References ....................................................13
142
- 15.1. Normative References .....................................13
143
- 15.2. Informative References ...................................13
144
- Appendix A. Changes from RFC 4627 .................................15
145
-
146
- 1. Introduction
147
-
148
- JavaScript Object Notation (JSON) is a text format for the
149
- serialization of structured data. It is derived from the object
150
- literals of JavaScript, as defined in the ECMAScript Programming
151
- Language Standard, Third Edition [ECMA-262].
152
-
153
- JSON can represent four primitive types (strings, numbers, booleans,
154
- and null) and two structured types (objects and arrays).
155
-
156
- A string is a sequence of zero or more Unicode characters [UNICODE].
157
- Note that this citation references the latest version of Unicode
158
- rather than a specific release. It is not expected that future
159
- changes in the UNICODE specification will impact the syntax of JSON.
160
-
161
- An object is an unordered collection of zero or more name/value
162
- pairs, where a name is a string and a value is a string, number,
163
- boolean, null, object, or array.
164
-
165
- An array is an ordered sequence of zero or more values.
166
-
167
-
168
-
169
-
170
- Bray Standards Track [Page 3]
171
-
172
- RFC 7159 JSON March 2014
173
-
174
-
175
- The terms "object" and "array" come from the conventions of
176
- JavaScript.
177
-
178
- JSON's design goals were for it to be minimal, portable, textual, and
179
- a subset of JavaScript.
180
-
181
- 1.1. Conventions Used in This Document
182
-
183
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
184
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
185
- document are to be interpreted as described in [RFC2119].
186
-
187
- The grammatical rules in this document are to be interpreted as
188
- described in [RFC5234].
189
-
190
- 1.2. Specifications of JSON
191
-
192
- This document updates [RFC4627], which describes JSON and registers
193
- the media type "application/json".
194
-
195
- A description of JSON in ECMAScript terms appears in Version 5.1 of
196
- the ECMAScript specification [ECMA-262], Section 15.12. JSON is also
197
- described in [ECMA-404].
198
-
199
- All of the specifications of JSON syntax agree on the syntactic
200
- elements of the language.
201
-
202
- 1.3. Introduction to This Revision
203
-
204
- In the years since the publication of RFC 4627, JSON has found very
205
- wide use. This experience has revealed certain patterns, which,
206
- while allowed by its specifications, have caused interoperability
207
- problems.
208
-
209
- Also, a small number of errata have been reported (see RFC Errata IDs
210
- 607 [Err607] and 3607 [Err3607]).
211
-
212
- This document's goal is to apply the errata, remove inconsistencies
213
- with other specifications of JSON, and highlight practices that can
214
- lead to interoperability problems.
215
-
216
- 2. JSON Grammar
217
-
218
- A JSON text is a sequence of tokens. The set of tokens includes six
219
- structural characters, strings, numbers, and three literal names.
220
-
221
- A JSON text is a serialized value. Note that certain previous
222
- specifications of JSON constrained a JSON text to be an object or an
223
-
224
-
225
-
226
- Bray Standards Track [Page 4]
227
-
228
- RFC 7159 JSON March 2014
229
-
230
-
231
- array. Implementations that generate only objects or arrays where a
232
- JSON text is called for will be interoperable in the sense that all
233
- implementations will accept these as conforming JSON texts.
234
-
235
- JSON-text = ws value ws
236
-
237
- These are the six structural characters:
238
-
239
- begin-array = ws %x5B ws ; [ left square bracket
240
-
241
- begin-object = ws %x7B ws ; { left curly bracket
242
-
243
- end-array = ws %x5D ws ; ] right square bracket
244
-
245
- end-object = ws %x7D ws ; } right curly bracket
246
-
247
- name-separator = ws %x3A ws ; : colon
248
-
249
- value-separator = ws %x2C ws ; , comma
250
-
251
- Insignificant whitespace is allowed before or after any of the six
252
- structural characters.
253
-
254
- ws = *(
255
- %x20 / ; Space
256
- %x09 / ; Horizontal tab
257
- %x0A / ; Line feed or New line
258
- %x0D ) ; Carriage return
259
-
260
- 3. Values
261
-
262
- A JSON value MUST be an object, array, number, or string, or one of
263
- the following three literal names:
264
-
265
- false null true
266
-
267
- The literal names MUST be lowercase. No other literal names are
268
- allowed.
269
-
270
- value = false / null / true / object / array / number / string
271
-
272
- false = %x66.61.6c.73.65 ; false
273
-
274
- null = %x6e.75.6c.6c ; null
275
-
276
- true = %x74.72.75.65 ; true
277
-
278
-
279
-
280
-
281
-
282
- Bray Standards Track [Page 5]
283
-
284
- RFC 7159 JSON March 2014
285
-
286
-
287
- 4. Objects
288
-
289
- An object structure is represented as a pair of curly brackets
290
- surrounding zero or more name/value pairs (or members). A name is a
291
- string. A single colon comes after each name, separating the name
292
- from the value. A single comma separates a value from a following
293
- name. The names within an object SHOULD be unique.
294
-
295
- object = begin-object [ member *( value-separator member ) ]
296
- end-object
297
-
298
- member = string name-separator value
299
-
300
- An object whose names are all unique is interoperable in the sense
301
- that all software implementations receiving that object will agree on
302
- the name-value mappings. When the names within an object are not
303
- unique, the behavior of software that receives such an object is
304
- unpredictable. Many implementations report the last name/value pair
305
- only. Other implementations report an error or fail to parse the
306
- object, and some implementations report all of the name/value pairs,
307
- including duplicates.
308
-
309
- JSON parsing libraries have been observed to differ as to whether or
310
- not they make the ordering of object members visible to calling
311
- software. Implementations whose behavior does not depend on member
312
- ordering will be interoperable in the sense that they will not be
313
- affected by these differences.
314
-
315
- 5. Arrays
316
-
317
- An array structure is represented as square brackets surrounding zero
318
- or more values (or elements). Elements are separated by commas.
319
-
320
- array = begin-array [ value *( value-separator value ) ] end-array
321
-
322
- There is no requirement that the values in an array be of the same
323
- type.
324
-
325
- 6. Numbers
326
-
327
- The representation of numbers is similar to that used in most
328
- programming languages. A number is represented in base 10 using
329
- decimal digits. It contains an integer component that may be
330
- prefixed with an optional minus sign, which may be followed by a
331
- fraction part and/or an exponent part. Leading zeros are not
332
- allowed.
333
-
334
- A fraction part is a decimal point followed by one or more digits.
335
-
336
-
337
-
338
- Bray Standards Track [Page 6]
339
-
340
- RFC 7159 JSON March 2014
341
-
342
-
343
- An exponent part begins with the letter E in upper or lower case,
344
- which may be followed by a plus or minus sign. The E and optional
345
- sign are followed by one or more digits.
346
-
347
- Numeric values that cannot be represented in the grammar below (such
348
- as Infinity and NaN) are not permitted.
349
-
350
- number = [ minus ] int [ frac ] [ exp ]
351
-
352
- decimal-point = %x2E ; .
353
-
354
- digit1-9 = %x31-39 ; 1-9
355
-
356
- e = %x65 / %x45 ; e E
357
-
358
- exp = e [ minus / plus ] 1*DIGIT
359
-
360
- frac = decimal-point 1*DIGIT
361
-
362
- int = zero / ( digit1-9 *DIGIT )
363
-
364
- minus = %x2D ; -
365
-
366
- plus = %x2B ; +
367
-
368
- zero = %x30 ; 0
369
-
370
- This specification allows implementations to set limits on the range
371
- and precision of numbers accepted. Since software that implements
372
- IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
373
- generally available and widely used, good interoperability can be
374
- achieved by implementations that expect no more precision or range
375
- than these provide, in the sense that implementations will
376
- approximate JSON numbers within the expected precision. A JSON
377
- number such as 1E400 or 3.141592653589793238462643383279 may indicate
378
- potential interoperability problems, since it suggests that the
379
- software that created it expects receiving software to have greater
380
- capabilities for numeric magnitude and precision than is widely
381
- available.
382
-
383
- Note that when such software is used, numbers that are integers and
384
- are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
385
- sense that implementations will agree exactly on their numeric
386
- values.
387
-
388
-
389
-
390
-
391
-
392
-
393
-
394
- Bray Standards Track [Page 7]
395
-
396
- RFC 7159 JSON March 2014
397
-
398
-
399
- 7. Strings
400
-
401
- The representation of strings is similar to conventions used in the C
402
- family of programming languages. A string begins and ends with
403
- quotation marks. All Unicode characters may be placed within the
404
- quotation marks, except for the characters that must be escaped:
405
- quotation mark, reverse solidus, and the control characters (U+0000
406
- through U+001F).
407
-
408
- Any character may be escaped. If the character is in the Basic
409
- Multilingual Plane (U+0000 through U+FFFF), then it may be
410
- represented as a six-character sequence: a reverse solidus, followed
411
- by the lowercase letter u, followed by four hexadecimal digits that
412
- encode the character's code point. The hexadecimal letters A though
413
- F can be upper or lower case. So, for example, a string containing
414
- only a single reverse solidus character may be represented as
415
- "\u005C".
416
-
417
- Alternatively, there are two-character sequence escape
418
- representations of some popular characters. So, for example, a
419
- string containing only a single reverse solidus character may be
420
- represented more compactly as "\\".
421
-
422
- To escape an extended character that is not in the Basic Multilingual
423
- Plane, the character is represented as a 12-character sequence,
424
- encoding the UTF-16 surrogate pair. So, for example, a string
425
- containing only the G clef character (U+1D11E) may be represented as
426
- "\uD834\uDD1E".
427
-
428
- string = quotation-mark *char quotation-mark
429
-
430
- char = unescaped /
431
- escape (
432
- %x22 / ; " quotation mark U+0022
433
- %x5C / ; \ reverse solidus U+005C
434
- %x2F / ; / solidus U+002F
435
- %x62 / ; b backspace U+0008
436
- %x66 / ; f form feed U+000C
437
- %x6E / ; n line feed U+000A
438
- %x72 / ; r carriage return U+000D
439
- %x74 / ; t tab U+0009
440
- %x75 4HEXDIG ) ; uXXXX U+XXXX
441
-
442
- escape = %x5C ; \
443
-
444
- quotation-mark = %x22 ; "
445
-
446
- unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
447
-
448
-
449
-
450
- Bray Standards Track [Page 8]
451
-
452
- RFC 7159 JSON March 2014
453
-
454
-
455
- 8. String and Character Issues
456
-
457
- 8.1. Character Encoding
458
-
459
- JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default
460
- encoding is UTF-8, and JSON texts that are encoded in UTF-8 are
461
- interoperable in the sense that they will be read successfully by the
462
- maximum number of implementations; there are many implementations
463
- that cannot successfully read texts in other encodings (such as
464
- UTF-16 and UTF-32).
465
-
466
- Implementations MUST NOT add a byte order mark to the beginning of a
467
- JSON text. In the interests of interoperability, implementations
468
- that parse JSON texts MAY ignore the presence of a byte order mark
469
- rather than treating it as an error.
470
-
471
- 8.2. Unicode Characters
472
-
473
- When all the strings represented in a JSON text are composed entirely
474
- of Unicode characters [UNICODE] (however escaped), then that JSON
475
- text is interoperable in the sense that all software implementations
476
- that parse it will agree on the contents of names and of string
477
- values in objects and arrays.
478
-
479
- However, the ABNF in this specification allows member names and
480
- string values to contain bit sequences that cannot encode Unicode
481
- characters; for example, "\uDEAD" (a single unpaired UTF-16
482
- surrogate). Instances of this have been observed, for example, when
483
- a library truncates a UTF-16 string without checking whether the
484
- truncation split a surrogate pair. The behavior of software that
485
- receives JSON texts containing such values is unpredictable; for
486
- example, implementations might return different values for the length
487
- of a string value or even suffer fatal runtime exceptions.
488
-
489
- 8.3. String Comparison
490
-
491
- Software implementations are typically required to test names of
492
- object members for equality. Implementations that transform the
493
- textual representation into sequences of Unicode code units and then
494
- perform the comparison numerically, code unit by code unit, are
495
- interoperable in the sense that implementations will agree in all
496
- cases on equality or inequality of two strings. For example,
497
- implementations that compare strings with escaped characters
498
- unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not
499
- equal.
500
-
501
-
502
-
503
-
504
-
505
-
506
- Bray Standards Track [Page 9]
507
-
508
- RFC 7159 JSON March 2014
509
-
510
-
511
- 9. Parsers
512
-
513
- A JSON parser transforms a JSON text into another representation. A
514
- JSON parser MUST accept all texts that conform to the JSON grammar.
515
- A JSON parser MAY accept non-JSON forms or extensions.
516
-
517
- An implementation may set limits on the size of texts that it
518
- accepts. An implementation may set limits on the maximum depth of
519
- nesting. An implementation may set limits on the range and precision
520
- of numbers. An implementation may set limits on the length and
521
- character contents of strings.
522
-
523
- 10. Generators
524
-
525
- A JSON generator produces JSON text. The resulting text MUST
526
- strictly conform to the JSON grammar.
527
-
528
- 11. IANA Considerations
529
-
530
- The MIME media type for JSON text is application/json.
531
-
532
- Type name: application
533
-
534
- Subtype name: json
535
-
536
- Required parameters: n/a
537
-
538
- Optional parameters: n/a
539
-
540
- Encoding considerations: binary
541
-
542
- Security considerations: See [RFC7159], Section 12.
543
-
544
- Interoperability considerations: Described in [RFC7159]
545
-
546
- Published specification: [RFC7159]
547
-
548
- Applications that use this media type:
549
- JSON has been used to exchange data between applications written
550
- in all of these programming languages: ActionScript, C, C#,
551
- Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript,
552
- Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and
553
- Scheme.
554
-
555
-
556
-
557
-
558
-
559
-
560
-
561
-
562
- Bray Standards Track [Page 10]
563
-
564
- RFC 7159 JSON March 2014
565
-
566
-
567
- Additional information:
568
- Magic number(s): n/a
569
- File extension(s): .json
570
- Macintosh file type code(s): TEXT
571
-
572
- Person & email address to contact for further information:
573
- IESG
574
- <iesg@ietf.org>
575
-
576
- Intended usage: COMMON
577
-
578
- Restrictions on usage: none
579
-
580
- Author:
581
- Douglas Crockford
582
- <douglas@crockford.com>
583
-
584
- Change controller:
585
- IESG
586
- <iesg@ietf.org>
587
-
588
- Note: No "charset" parameter is defined for this registration.
589
- Adding one really has no effect on compliant recipients.
590
-
591
- 12. Security Considerations
592
-
593
- Generally, there are security issues with scripting languages. JSON
594
- is a subset of JavaScript but excludes assignment and invocation.
595
-
596
- Since JSON's syntax is borrowed from JavaScript, it is possible to
597
- use that language's "eval()" function to parse JSON texts. This
598
- generally constitutes an unacceptable security risk, since the text
599
- could contain executable code along with data declarations. The same
600
- consideration applies to the use of eval()-like functions in any
601
- other programming language in which JSON texts conform to that
602
- language's syntax.
603
-
604
-
605
-
606
-
607
-
608
-
609
-
610
-
611
-
612
-
613
-
614
-
615
-
616
-
617
-
618
- Bray Standards Track [Page 11]
619
-
620
- RFC 7159 JSON March 2014
621
-
622
-
623
- 13. Examples
624
-
625
- This is a JSON object:
626
-
627
- {
628
- "Image": {
629
- "Width": 800,
630
- "Height": 600,
631
- "Title": "View from 15th Floor",
632
- "Thumbnail": {
633
- "Url": "http://www.example.com/image/481989943",
634
- "Height": 125,
635
- "Width": 100
636
- },
637
- "Animated" : false,
638
- "IDs": [116, 943, 234, 38793]
639
- }
640
- }
641
-
642
- Its Image member is an object whose Thumbnail member is an object and
643
- whose IDs member is an array of numbers.
644
-
645
- This is a JSON array containing two objects:
646
-
647
- [
648
- {
649
- "precision": "zip",
650
- "Latitude": 37.7668,
651
- "Longitude": -122.3959,
652
- "Address": "",
653
- "City": "SAN FRANCISCO",
654
- "State": "CA",
655
- "Zip": "94107",
656
- "Country": "US"
657
- },
658
- {
659
- "precision": "zip",
660
- "Latitude": 37.371991,
661
- "Longitude": -122.026020,
662
- "Address": "",
663
- "City": "SUNNYVALE",
664
- "State": "CA",
665
- "Zip": "94085",
666
- "Country": "US"
667
- }
668
- ]
669
-
670
-
671
-
672
-
673
-
674
- Bray Standards Track [Page 12]
675
-
676
- RFC 7159 JSON March 2014
677
-
678
-
679
- Here are three small JSON texts containing only values:
680
-
681
- "Hello world!"
682
-
683
- 42
684
-
685
- true
686
-
687
- 14. Contributors
688
-
689
- RFC 4627 was written by Douglas Crockford. This document was
690
- constructed by making a relatively small number of changes to that
691
- document; thus, the vast majority of the text here is his.
692
-
693
- 15. References
694
-
695
- 15.1. Normative References
696
-
697
- [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
698
- Standard 754, August 2008,
699
- <http://grouper.ieee.org/groups/754/>.
700
-
701
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
702
- Requirement Levels", BCP 14, RFC 2119, March 1997.
703
-
704
- [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
705
- Specifications: ABNF", STD 68, RFC 5234, January 2008.
706
-
707
- [UNICODE] The Unicode Consortium, "The Unicode Standard",
708
- <http://www.unicode.org/versions/latest/>.
709
-
710
- 15.2. Informative References
711
-
712
- [ECMA-262] Ecma International, "ECMAScript Language Specification
713
- Edition 5.1", Standard ECMA-262, June 2011,
714
- <http://www.ecma-international.org/publications/standards/
715
- Ecma-262.htm>.
716
-
717
- [ECMA-404] Ecma International, "The JSON Data Interchange Format",
718
- Standard ECMA-404, October 2013,
719
- <http://www.ecma-international.org/publications/standards/
720
- Ecma-404.htm>.
721
-
722
- [Err3607] RFC Errata, Errata ID 3607, RFC 3607,
723
- <http://www.rfc-editor.org>.
724
-
725
-
726
-
727
-
728
-
729
-
730
- Bray Standards Track [Page 13]
731
-
732
- RFC 7159 JSON March 2014
733
-
734
-
735
- [Err607] RFC Errata, Errata ID 607, RFC 607,
736
- <http://www.rfc-editor.org>.
737
-
738
- [RFC4627] Crockford, D., "The application/json Media Type for
739
- JavaScript Object Notation (JSON)", RFC 4627, July 2006.
740
-
741
-
742
-
743
-
744
-
745
-
746
-
747
-
748
-
749
-
750
-
751
-
752
-
753
-
754
-
755
-
756
-
757
-
758
-
759
-
760
-
761
-
762
-
763
-
764
-
765
-
766
-
767
-
768
-
769
-
770
-
771
-
772
-
773
-
774
-
775
-
776
-
777
-
778
-
779
-
780
-
781
-
782
-
783
-
784
-
785
-
786
- Bray Standards Track [Page 14]
787
-
788
- RFC 7159 JSON March 2014
789
-
790
-
791
- Appendix A. Changes from RFC 4627
792
-
793
- This section lists changes between this document and the text in RFC
794
- 4627.
795
-
796
- o Changed the title and abstract of the document.
797
-
798
- o Changed the reference to [UNICODE] to be not version specific.
799
-
800
- o Added a "Specifications of JSON" section.
801
-
802
- o Added an "Introduction to This Revision" section.
803
-
804
- o Changed the definition of "JSON text" so that it can be any JSON
805
- value, removing the constraint that it be an object or array.
806
-
807
- o Added language about duplicate object member names, member
808
- ordering, and interoperability.
809
-
810
- o Clarified the absence of a requirement that values in an array be
811
- of the same JSON type.
812
-
813
- o Applied erratum #607 from RFC 4627 to correctly align the artwork
814
- for the definition of "object".
815
-
816
- o Changed "as sequences of digits" to "in the grammar below" in the
817
- "Numbers" section, and made base-10-ness explicit.
818
-
819
- o Added language about number interoperability as a function of
820
- IEEE754, and added an IEEE754 reference.
821
-
822
- o Added language about interoperability and Unicode characters and
823
- about string comparisons. To do this, turned the old "Encoding"
824
- section into a "String and Character Issues" section, with three
825
- subsections: "Character Encoding", "Unicode Characters", and
826
- "String Comparison".
827
-
828
- o Changed guidance in the "Parsers" section to point out that
829
- implementations may set limits on the range "and precision" of
830
- numbers.
831
-
832
- o Updated and tidied the "IANA Considerations" section.
833
-
834
- o Made a real "Security Considerations" section and lifted the text
835
- out of the previous "IANA Considerations" section.
836
-
837
-
838
-
839
-
840
-
841
-
842
- Bray Standards Track [Page 15]
843
-
844
- RFC 7159 JSON March 2014
845
-
846
-
847
- o Applied erratum #3607 from RFC 4627 by removing the security
848
- consideration that begins "A JSON text can be safely passed" and
849
- the JavaScript code that went with that consideration.
850
-
851
- o Added a note to the "Security Considerations" section pointing out
852
- the risks of using the "eval()" function in JavaScript or any
853
- other language in which JSON texts conform to that language's
854
- syntax.
855
-
856
- o Added a note to the "IANA Considerations" clarifying the absence
857
- of a "charset" parameter for the application/json media type.
858
-
859
- o Changed "100" to 100 and added a boolean field, both in the first
860
- example.
861
-
862
- o Added examples of JSON texts with simple values, neither objects
863
- nor arrays.
864
-
865
- o Added a "Contributors" section crediting Douglas Crockford.
866
-
867
- o Added a reference to RFC 4627.
868
-
869
- o Moved the ECMAScript reference from Normative to Informative and
870
- updated it to reference ECMAScript 5.1, and added a reference to
871
- ECMA 404.
872
-
873
- Author's Address
874
-
875
- Tim Bray (editor)
876
- Google, Inc.
877
-
878
- EMail: tbray@textuality.com
879
-
880
-
881
-
882
-
883
-
884
-
885
-
886
-
887
-
888
-
889
-
890
-
891
-
892
-
893
-
894
-
895
-
896
-
897
-
898
- Bray Standards Track [Page 16]
899
-