json 2.4.0 → 2.4.1

Sign up to get free protection for your applications and to get access to all the features.
@@ -1,38 +0,0 @@
1
- # -*- encoding: utf-8 -*-
2
-
3
- spec = Gem::Specification.new do |s|
4
- s.name = "json"
5
- s.version = File.read("VERSION").chomp
6
-
7
- s.summary = "JSON Implementation for Ruby"
8
- s.description = "A JSON implementation as a JRuby extension."
9
- s.licenses = ["Ruby"]
10
- s.author = "Daniel Luz"
11
- s.email = "dev+ruby@mernen.com"
12
-
13
- s.platform = 'java'
14
-
15
- s.files = Dir["{docs,lib,tests}/**/*", "LICENSE"]
16
-
17
- s.homepage = "http://flori.github.com/json"
18
- s.metadata = {
19
- 'bug_tracker_uri' => 'https://github.com/flori/json/issues',
20
- 'changelog_uri' => 'https://github.com/flori/json/blob/master/CHANGES.md',
21
- 'documentation_uri' => 'http://flori.github.io/json/doc/index.html',
22
- 'homepage_uri' => 'http://flori.github.io/json/',
23
- 'source_code_uri' => 'https://github.com/flori/json',
24
- 'wiki_uri' => 'https://github.com/flori/json/wiki'
25
- }
26
-
27
- s.required_ruby_version = Gem::Requirement.new(">= 2.0")
28
- s.test_files = ["tests/test_helper.rb"]
29
-
30
- s.add_development_dependency("rake", [">= 0"])
31
- s.add_development_dependency("test-unit", [">= 2.0", "< 4.0"])
32
- end
33
-
34
- if $0 == __FILE__
35
- Gem::Builder.new(spec).build
36
- else
37
- spec
38
- end
@@ -1,33 +0,0 @@
1
- # -*- encoding: utf-8 -*-
2
-
3
- Gem::Specification.new do |s|
4
- s.name = "json_pure".freeze
5
- s.version = File.read("VERSION").chomp
6
-
7
- s.required_rubygems_version = Gem::Requirement.new(">= 0".freeze) if s.respond_to? :required_rubygems_version=
8
- s.require_paths = ["lib".freeze]
9
- s.authors = ["Florian Frank".freeze]
10
- s.description = "This is a JSON implementation in pure Ruby.".freeze
11
- s.email = "flori@ping.de".freeze
12
- s.extra_rdoc_files = ["README.md".freeze]
13
- s.files = ["./tests/test_helper.rb".freeze, ".gitignore".freeze, ".travis.yml".freeze, "CHANGES.md".freeze, "Gemfile".freeze, "LICENSE".freeze, "README-json-jruby.md".freeze, "README.md".freeze, "Rakefile".freeze, "VERSION".freeze, "diagrams/.keep".freeze, "ext/json/ext/fbuffer/fbuffer.h".freeze, "ext/json/ext/generator/depend".freeze, "ext/json/ext/generator/extconf.rb".freeze, "ext/json/ext/generator/generator.c".freeze, "ext/json/ext/generator/generator.h".freeze, "ext/json/ext/parser/depend".freeze, "ext/json/ext/parser/extconf.rb".freeze, "ext/json/ext/parser/parser.c".freeze, "ext/json/ext/parser/parser.h".freeze, "ext/json/ext/parser/parser.rl".freeze, "ext/json/extconf.rb".freeze, "install.rb".freeze, "java/src/json/ext/ByteListTranscoder.java".freeze, "java/src/json/ext/Generator.java".freeze, "java/src/json/ext/GeneratorMethods.java".freeze, "java/src/json/ext/GeneratorService.java".freeze, "java/src/json/ext/GeneratorState.java".freeze, "java/src/json/ext/OptionsReader.java".freeze, "java/src/json/ext/Parser.java".freeze, "java/src/json/ext/Parser.rl".freeze, "java/src/json/ext/ParserService.java".freeze, "java/src/json/ext/RuntimeInfo.java".freeze, "java/src/json/ext/StringDecoder.java".freeze, "java/src/json/ext/StringEncoder.java".freeze, "java/src/json/ext/Utils.java".freeze, "json-java.gemspec".freeze, "json.gemspec".freeze, "json_pure.gemspec".freeze, "lib/json.rb".freeze, "lib/json/add/bigdecimal.rb".freeze, "lib/json/add/complex.rb".freeze, "lib/json/add/core.rb".freeze, "lib/json/add/date.rb".freeze, "lib/json/add/date_time.rb".freeze, "lib/json/add/exception.rb".freeze, "lib/json/add/ostruct.rb".freeze, "lib/json/add/range.rb".freeze, "lib/json/add/rational.rb".freeze, "lib/json/add/regexp.rb".freeze, "lib/json/add/set.rb".freeze, "lib/json/add/struct.rb".freeze, "lib/json/add/symbol.rb".freeze, "lib/json/add/time.rb".freeze, "lib/json/common.rb".freeze, "lib/json/ext.rb".freeze, "lib/json/ext/.keep".freeze, "lib/json/generic_object.rb".freeze, "lib/json/pure.rb".freeze, "lib/json/pure/generator.rb".freeze, "lib/json/pure/parser.rb".freeze, "lib/json/version.rb".freeze, "references/rfc7159.txt".freeze, "tests/fixtures/fail10.json".freeze, "tests/fixtures/fail11.json".freeze, "tests/fixtures/fail12.json".freeze, "tests/fixtures/fail13.json".freeze, "tests/fixtures/fail14.json".freeze, "tests/fixtures/fail18.json".freeze, "tests/fixtures/fail19.json".freeze, "tests/fixtures/fail2.json".freeze, "tests/fixtures/fail20.json".freeze, "tests/fixtures/fail21.json".freeze, "tests/fixtures/fail22.json".freeze, "tests/fixtures/fail23.json".freeze, "tests/fixtures/fail24.json".freeze, "tests/fixtures/fail25.json".freeze, "tests/fixtures/fail27.json".freeze, "tests/fixtures/fail28.json".freeze, "tests/fixtures/fail3.json".freeze, "tests/fixtures/fail4.json".freeze, "tests/fixtures/fail5.json".freeze, "tests/fixtures/fail6.json".freeze, "tests/fixtures/fail7.json".freeze, "tests/fixtures/fail8.json".freeze, "tests/fixtures/fail9.json".freeze, "tests/fixtures/obsolete_fail1.json".freeze, "tests/fixtures/pass1.json".freeze, "tests/fixtures/pass15.json".freeze, "tests/fixtures/pass16.json".freeze, "tests/fixtures/pass17.json".freeze, "tests/fixtures/pass2.json".freeze, "tests/fixtures/pass26.json".freeze, "tests/fixtures/pass3.json".freeze, "tests/json_addition_test.rb".freeze, "tests/json_common_interface_test.rb".freeze, "tests/json_encoding_test.rb".freeze, "tests/json_ext_parser_test.rb".freeze, "tests/json_fixtures_test.rb".freeze, "tests/json_generator_test.rb".freeze, "tests/json_generic_object_test.rb".freeze, "tests/json_parser_test.rb".freeze, "tests/json_string_matching_test.rb".freeze, "tests/test_helper.rb".freeze, "tools/diff.sh".freeze, "tools/fuzz.rb".freeze, "tools/server.rb".freeze]
14
- s.homepage = "http://flori.github.com/json".freeze
15
- s.licenses = ["Ruby".freeze]
16
- s.rdoc_options = ["--title".freeze, "JSON implemention for ruby".freeze, "--main".freeze, "README.md".freeze]
17
- s.required_ruby_version = Gem::Requirement.new(">= 2.0".freeze)
18
- s.rubygems_version = "3.1.2".freeze
19
- s.summary = "JSON Implementation for Ruby".freeze
20
- s.test_files = ["./tests/test_helper.rb".freeze]
21
-
22
- if s.respond_to? :specification_version then
23
- s.specification_version = 4
24
- end
25
-
26
- if s.respond_to? :add_runtime_dependency then
27
- s.add_development_dependency(%q<rake>.freeze, [">= 0"])
28
- s.add_development_dependency(%q<test-unit>.freeze, [">= 2.0", "< 4.0"])
29
- else
30
- s.add_dependency(%q<rake>.freeze, [">= 0"])
31
- s.add_dependency(%q<test-unit>.freeze, [">= 2.0", "< 4.0"])
32
- end
33
- end
@@ -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
-