video_chat_get 0.1.4 → 0.1.5

data/vendor/bundle/ruby/2.5.0/gems/json-2.3.0/lib/json/pure/parser 2.rb

@@ -0,0 +1,319 @@
+#frozen_string_literal: false
+require 'strscan'
+
+module JSON
+  module Pure
+    # This class implements the JSON parser that is used to parse a JSON string
+    # into a Ruby data structure.
+    class Parser < StringScanner
+      STRING                = /" ((?:[^\x0-\x1f"\\] |
+                                   # escaped special characters:
+                                  \\["\\\/bfnrt] |
+                                  \\u[0-9a-fA-F]{4} |
+                                   # match all but escaped special characters:
+                                  \\[\x20-\x21\x23-\x2e\x30-\x5b\x5d-\x61\x63-\x65\x67-\x6d\x6f-\x71\x73\x75-\xff])*)
+                              "/nx
+      INTEGER               = /(-?0|-?[1-9]\d*)/
+      FLOAT                 = /(-?
+                                (?:0|[1-9]\d*)
+                                (?:
+                                  \.\d+(?i:e[+-]?\d+) |
+                                  \.\d+ |
+                                  (?i:e[+-]?\d+)
+                                )
+                                )/x
+      NAN                   = /NaN/
+      INFINITY              = /Infinity/
+      MINUS_INFINITY        = /-Infinity/
+      OBJECT_OPEN           = /\{/
+      OBJECT_CLOSE          = /\}/
+      ARRAY_OPEN            = /\[/
+      ARRAY_CLOSE           = /\]/
+      PAIR_DELIMITER        = /:/
+      COLLECTION_DELIMITER  = /,/
+      TRUE                  = /true/
+      FALSE                 = /false/
+      NULL                  = /null/
+      IGNORE                = %r(
+        (?:
+         //[^\n\r]*[\n\r]| # line comments
+         /\*               # c-style comments
+         (?:
+          [^*/]|        # normal chars
+          /[^*]|        # slashes that do not start a nested comment
+          \*[^/]|       # asterisks that do not end this comment
+          /(?=\*/)      # single slash before this comment's end
+         )*
+           \*/               # the End of this comment
+           |[ \t\r\n]+       # whitespaces: space, horicontal tab, lf, cr
+        )+
+      )mx
+
+        UNPARSED = Object.new.freeze
+
+      # Creates a new JSON::Pure::Parser instance for the string _source_.
+      #
+      # It will be configured by the _opts_ hash. _opts_ can have the following
+      # keys:
+      # * *max_nesting*: The maximum depth of nesting allowed in the parsed data
+      #   structures. Disable depth checking with :max_nesting => false|nil|0,
+      #   it defaults to 100.
+      # * *allow_nan*: If set to true, allow NaN, Infinity and -Infinity in
+      #   defiance of RFC 7159 to be parsed by the Parser. This option defaults
+      #   to false.
+      # * *symbolize_names*: If set to true, returns symbols for the names
+      #   (keys) in a JSON object. Otherwise strings are returned, which is
+      #   also the default. It's not possible to use this option in
+      #   conjunction with the *create_additions* option.
+      # * *create_additions*: If set to true, the Parser creates
+      #   additions when if a matching class and create_id was found. This
+      #   option defaults to false.
+      # * *object_class*: Defaults to Hash
+      # * *array_class*: Defaults to Array
+      # * *decimal_class*: Specifies which class to use instead of the default
+      #    (Float) when parsing decimal numbers. This class must accept a single
+      #    string argument in its constructor.
+      def initialize(source, opts = {})
+        opts ||= {}
+        source = convert_encoding source
+        super source
+        if !opts.key?(:max_nesting) # defaults to 100
+          @max_nesting = 100
+        elsif opts[:max_nesting]
+          @max_nesting = opts[:max_nesting]
+        else
+          @max_nesting = 0
+        end
+        @allow_nan = !!opts[:allow_nan]
+        @symbolize_names = !!opts[:symbolize_names]
+        if opts.key?(:create_additions)
+          @create_additions = !!opts[:create_additions]
+        else
+          @create_additions = false
+        end
+        @symbolize_names && @create_additions and raise ArgumentError,
+          'options :symbolize_names and :create_additions cannot be used '\
+          'in conjunction'
+        @create_id = @create_additions ? JSON.create_id : nil
+        @object_class = opts[:object_class] || Hash
+        @array_class  = opts[:array_class] || Array
+        @decimal_class = opts[:decimal_class]
+        @match_string = opts[:match_string]
+      end
+
+      alias source string
+
+      def reset
+        super
+        @current_nesting = 0
+      end
+
+      # Parses the current JSON string _source_ and returns the
+      # complete data structure as a result.
+      def parse
+        reset
+        obj = nil
+        while !eos? && skip(IGNORE) do end
+        if eos?
+          raise ParserError, "source is not valid JSON!"
+        else
+          obj = parse_value
+          UNPARSED.equal?(obj) and raise ParserError,
+            "source is not valid JSON!"
+        end
+        while !eos? && skip(IGNORE) do end
+        eos? or raise ParserError, "source is not valid JSON!"
+        obj
+      end
+
+      private
+
+      def convert_encoding(source)
+        if source.respond_to?(:to_str)
+          source = source.to_str
+        else
+          raise TypeError,
+            "#{source.inspect} is not like a string"
+        end
+        if source.encoding != ::Encoding::ASCII_8BIT
+          source = source.encode(::Encoding::UTF_8)
+          source.force_encoding(::Encoding::ASCII_8BIT)
+        end
+        source
+      end
+
+      # Unescape characters in strings.
+      UNESCAPE_MAP = Hash.new { |h, k| h[k] = k.chr }
+      UNESCAPE_MAP.update({
+        ?"  => '"',
+        ?\\ => '\\',
+        ?/  => '/',
+        ?b  => "\b",
+        ?f  => "\f",
+        ?n  => "\n",
+        ?r  => "\r",
+        ?t  => "\t",
+        ?u  => nil,
+      })
+
+      EMPTY_8BIT_STRING = ''
+      if ::String.method_defined?(:encode)
+        EMPTY_8BIT_STRING.force_encoding Encoding::ASCII_8BIT
+      end
+
+      def parse_string
+        if scan(STRING)
+          return '' if self[1].empty?
+          string = self[1].gsub(%r((?:\\[\\bfnrt"/]|(?:\\u(?:[A-Fa-f\d]{4}))+|\\[\x20-\xff]))n) do |c|
+            if u = UNESCAPE_MAP[$&[1]]
+              u
+            else # \uXXXX
+              bytes = EMPTY_8BIT_STRING.dup
+              i = 0
+              while c[6 * i] == ?\\ && c[6 * i + 1] == ?u
+                bytes << c[6 * i + 2, 2].to_i(16) << c[6 * i + 4, 2].to_i(16)
+                i += 1
+              end
+              JSON.iconv('utf-8', 'utf-16be', bytes)
+            end
+          end
+          if string.respond_to?(:force_encoding)
+            string.force_encoding(::Encoding::UTF_8)
+          end
+          if @create_additions and @match_string
+            for (regexp, klass) in @match_string
+              klass.json_creatable? or next
+              string =~ regexp and return klass.json_create(string)
+            end
+          end
+          string
+        else
+          UNPARSED
+        end
+      rescue => e
+        raise ParserError, "Caught #{e.class} at '#{peek(20)}': #{e}"
+      end
+
+      def parse_value
+        case
+        when scan(FLOAT)
+          if @decimal_class then
+            if @decimal_class == BigDecimal then
+              BigDecimal(self[1])
+            else
+              @decimal_class.new(self[1]) || Float(self[1])
+            end
+          else
+            Float(self[1])
+          end
+        when scan(INTEGER)
+          Integer(self[1])
+        when scan(TRUE)
+          true
+        when scan(FALSE)
+          false
+        when scan(NULL)
+          nil
+        when !UNPARSED.equal?(string = parse_string)
+          string
+        when scan(ARRAY_OPEN)
+          @current_nesting += 1
+          ary = parse_array
+          @current_nesting -= 1
+          ary
+        when scan(OBJECT_OPEN)
+          @current_nesting += 1
+          obj = parse_object
+          @current_nesting -= 1
+          obj
+        when @allow_nan && scan(NAN)
+          NaN
+        when @allow_nan && scan(INFINITY)
+          Infinity
+        when @allow_nan && scan(MINUS_INFINITY)
+          MinusInfinity
+        else
+          UNPARSED
+        end
+      end
+
+      def parse_array
+        raise NestingError, "nesting of #@current_nesting is too deep" if
+          @max_nesting.nonzero? && @current_nesting > @max_nesting
+        result = @array_class.new
+        delim = false
+        until eos?
+          case
+          when !UNPARSED.equal?(value = parse_value)
+            delim = false
+            result << value
+            skip(IGNORE)
+            if scan(COLLECTION_DELIMITER)
+              delim = true
+            elsif match?(ARRAY_CLOSE)
+              ;
+            else
+              raise ParserError, "expected ',' or ']' in array at '#{peek(20)}'!"
+            end
+          when scan(ARRAY_CLOSE)
+            if delim
+              raise ParserError, "expected next element in array at '#{peek(20)}'!"
+            end
+            break
+          when skip(IGNORE)
+            ;
+          else
+            raise ParserError, "unexpected token in array at '#{peek(20)}'!"
+          end
+        end
+        result
+      end
+
+      def parse_object
+        raise NestingError, "nesting of #@current_nesting is too deep" if
+          @max_nesting.nonzero? && @current_nesting > @max_nesting
+        result = @object_class.new
+        delim = false
+        until eos?
+          case
+          when !UNPARSED.equal?(string = parse_string)
+            skip(IGNORE)
+            unless scan(PAIR_DELIMITER)
+              raise ParserError, "expected ':' in object at '#{peek(20)}'!"
+            end
+            skip(IGNORE)
+            unless UNPARSED.equal?(value = parse_value)
+              result[@symbolize_names ? string.to_sym : string] = value
+              delim = false
+              skip(IGNORE)
+              if scan(COLLECTION_DELIMITER)
+                delim = true
+              elsif match?(OBJECT_CLOSE)
+                ;
+              else
+                raise ParserError, "expected ',' or '}' in object at '#{peek(20)}'!"
+              end
+            else
+              raise ParserError, "expected value in object at '#{peek(20)}'!"
+            end
+          when scan(OBJECT_CLOSE)
+            if delim
+              raise ParserError, "expected next name, value pair in object at '#{peek(20)}'!"
+            end
+            if @create_additions and klassname = result[@create_id]
+              klass = JSON.deep_const_get klassname
+              break unless klass and klass.json_creatable?
+              result = klass.json_create(result)
+            end
+            break
+          when skip(IGNORE)
+            ;
+          else
+            raise ParserError, "unexpected token in object at '#{peek(20)}'!"
+          end
+        end
+        result
+      end
+    end
+  end
+end

data/vendor/bundle/ruby/2.5.0/gems/json-2.3.0/lib/json/version 2.rb

@@ -0,0 +1,9 @@
+# frozen_string_literal: false
+module JSON
+  # JSON version
+  VERSION         = '2.3.0'
+  VERSION_ARRAY   = VERSION.split(/\./).map { |x| x.to_i } # :nodoc:
+  VERSION_MAJOR   = VERSION_ARRAY[0] # :nodoc:
+  VERSION_MINOR   = VERSION_ARRAY[1] # :nodoc:
+  VERSION_BUILD   = VERSION_ARRAY[2] # :nodoc:
+end

data/vendor/bundle/ruby/2.5.0/gems/json-2.3.0/references/rfc7159 2.txt

@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      T. Bray, Ed.
+Request for Comments: 7159                                  Google, Inc.
+Obsoletes: 4627, 7158                                         March 2014
+Category: Standards Track
+ISSN: 2070-1721
+
+
+     The JavaScript Object Notation (JSON) Data Interchange Format
+
+Abstract
+
+   JavaScript Object Notation (JSON) is a lightweight, text-based,
+   language-independent data interchange format.  It was derived from
+   the ECMAScript Programming Language Standard.  JSON defines a small
+   set of formatting rules for the portable representation of structured
+   data.
+
+   This document removes inconsistencies with other specifications of
+   JSON, repairs specification errors, and offers experience-based
+   interoperability guidance.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7159.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bray                         Standards Track                    [Page 1]
+
+RFC 7159                          JSON                        March 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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
+   (http://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 7159                          JSON                        March 2014
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Conventions Used in This Document ..........................4
+      1.2. Specifications of JSON .....................................4
+      1.3. Introduction to This Revision ..............................4
+   2. JSON Grammar ....................................................4
+   3. Values ..........................................................5
+   4. Objects .........................................................6
+   5. Arrays ..........................................................6
+   6. Numbers .........................................................6
+   7. Strings .........................................................8
+   8. String and Character Issues .....................................9
+      8.1. Character Encoding .........................................9
+      8.2. Unicode Characters .........................................9
+      8.3. String Comparison ..........................................9
+   9. Parsers ........................................................10
+   10. Generators ....................................................10
+   11. IANA Considerations ...........................................10
+   12. Security Considerations .......................................11
+   13. Examples ......................................................12
+   14. Contributors ..................................................13
+   15. References ....................................................13
+      15.1. Normative References .....................................13
+      15.2. Informative References ...................................13
+   Appendix A. Changes from RFC 4627 .................................15
+
+1.  Introduction
+
+   JavaScript Object Notation (JSON) is a text format for the
+   serialization of structured data.  It is derived from the object
+   literals of JavaScript, as defined in the ECMAScript Programming
+   Language Standard, Third Edition [ECMA-262].
+
+   JSON can represent four primitive types (strings, numbers, booleans,
+   and null) and two structured types (objects and arrays).
+
+   A string is a sequence of zero or more Unicode characters [UNICODE].
+   Note that this citation references the latest version of Unicode
+   rather than a specific release.  It is not expected that future
+   changes in the UNICODE specification will impact the syntax of JSON.
+
+   An object is an unordered collection of zero or more name/value
+   pairs, where a name is a string and a value is a string, number,
+   boolean, null, object, or array.
+
+   An array is an ordered sequence of zero or more values.
+
+
+
+
+Bray                         Standards Track                    [Page 3]
+
+RFC 7159                          JSON                        March 2014
+
+
+   The terms "object" and "array" come from the conventions of
+   JavaScript.
+
+   JSON's design goals were for it to be minimal, portable, textual, and
+   a subset of JavaScript.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The grammatical rules in this document are to be interpreted as
+   described in [RFC5234].
+
+1.2.  Specifications of JSON
+
+   This document updates [RFC4627], which describes JSON and registers
+   the media type "application/json".
+
+   A description of JSON in ECMAScript terms appears in Version 5.1 of
+   the ECMAScript specification [ECMA-262], Section 15.12.  JSON is also
+   described in [ECMA-404].
+
+   All of the specifications of JSON syntax agree on the syntactic
+   elements of the language.
+
+1.3.  Introduction to This Revision
+
+   In the years since the publication of RFC 4627, JSON has found very
+   wide use.  This experience has revealed certain patterns, which,
+   while allowed by its specifications, have caused interoperability
+   problems.
+
+   Also, a small number of errata have been reported (see RFC Errata IDs
+   607 [Err607] and 3607 [Err3607]).
+
+   This document's goal is to apply the errata, remove inconsistencies
+   with other specifications of JSON, and highlight practices that can
+   lead to interoperability problems.
+
+2.  JSON Grammar
+
+   A JSON text is a sequence of tokens.  The set of tokens includes six
+   structural characters, strings, numbers, and three literal names.
+
+   A JSON text is a serialized value.  Note that certain previous
+   specifications of JSON constrained a JSON text to be an object or an
+
+
+
+Bray                         Standards Track                    [Page 4]
+
+RFC 7159                          JSON                        March 2014
+
+
+   array.  Implementations that generate only objects or arrays where a
+   JSON text is called for will be interoperable in the sense that all
+   implementations will accept these as conforming JSON texts.
+
+      JSON-text = ws value ws
+
+   These are the six structural characters:
+
+      begin-array     = ws %x5B ws  ; [ left square bracket
+
+      begin-object    = ws %x7B ws  ; { left curly bracket
+
+      end-array       = ws %x5D ws  ; ] right square bracket
+
+      end-object      = ws %x7D ws  ; } right curly bracket
+
+      name-separator  = ws %x3A ws  ; : colon
+
+      value-separator = ws %x2C ws  ; , comma
+
+   Insignificant whitespace is allowed before or after any of the six
+   structural characters.
+
+      ws = *(
+              %x20 /              ; Space
+              %x09 /              ; Horizontal tab
+              %x0A /              ; Line feed or New line
+              %x0D )              ; Carriage return
+
+3.  Values
+
+   A JSON value MUST be an object, array, number, or string, or one of
+   the following three literal names:
+
+      false null true
+
+   The literal names MUST be lowercase.  No other literal names are
+   allowed.
+
+      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
+
+
+
+
+
+Bray                         Standards Track                    [Page 5]
+
+RFC 7159                          JSON                        March 2014
+
+
+4.  Objects
+
+   An object structure is represented as a pair of curly brackets
+   surrounding zero or more name/value pairs (or members).  A name is a
+   string.  A single colon comes after each name, separating the name
+   from the value.  A single comma separates a value from a following
+   name.  The names within an object SHOULD be unique.
+
+      object = begin-object [ member *( value-separator member ) ]
+               end-object
+
+      member = string name-separator value
+
+   An object whose names are all unique is interoperable in the sense
+   that all software implementations receiving that object will agree on
+   the name-value mappings.  When the names within an object are not
+   unique, the behavior of software that receives such an object is
+   unpredictable.  Many implementations report the last name/value pair
+   only.  Other implementations report an error or fail to parse the
+   object, and some implementations report all of the name/value pairs,
+   including duplicates.
+
+   JSON parsing libraries have been observed to differ as to whether or
+   not they make the ordering of object members visible to calling
+   software.  Implementations whose behavior does not depend on member
+   ordering will be interoperable in the sense that they will not be
+   affected by these differences.
+
+5.  Arrays
+
+   An array structure is represented as square brackets surrounding zero
+   or more values (or elements).  Elements are separated by commas.
+
+   array = begin-array [ value *( value-separator value ) ] end-array
+
+   There is no requirement that the values in an array be of the same
+   type.
+
+6.  Numbers
+
+   The representation of numbers is similar to that used in most
+   programming languages.  A number is represented in base 10 using
+   decimal digits.  It contains an integer component that may be
+   prefixed with an optional minus sign, which may be followed by a
+   fraction part and/or an exponent part.  Leading zeros are not
+   allowed.
+
+   A fraction part is a decimal point followed by one or more digits.
+
+
+
+Bray                         Standards Track                    [Page 6]
+
+RFC 7159                          JSON                        March 2014
+
+
+   An exponent part begins with the letter E in upper or lower case,
+   which may be followed by a plus or minus sign.  The E and optional
+   sign are followed by one or more digits.
+
+   Numeric values that cannot be represented in the grammar below (such
+   as Infinity and NaN) are not permitted.
+
+      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
+
+   This specification allows implementations to set limits on the range
+   and precision of numbers accepted.  Since software that implements
+   IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
+   generally available and widely used, good interoperability can be
+   achieved by implementations that expect no more precision or range
+   than these provide, in the sense that implementations will
+   approximate JSON numbers within the expected precision.  A JSON
+   number such as 1E400 or 3.141592653589793238462643383279 may indicate
+   potential interoperability problems, since it suggests that the
+   software that created it expects receiving software to have greater
+   capabilities for numeric magnitude and precision than is widely
+   available.
+
+   Note that when such software is used, numbers that are integers and
+   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
+   sense that implementations will agree exactly on their numeric
+   values.
+
+
+
+
+
+
+
+Bray                         Standards Track                    [Page 7]
+
+RFC 7159                          JSON                        March 2014
+
+
+7.  Strings
+
+   The representation of strings is similar to conventions used in the C
+   family of programming languages.  A string begins and ends with
+   quotation marks.  All Unicode characters may be placed within the
+   quotation marks, except for the characters that must be escaped:
+   quotation mark, reverse solidus, and the control characters (U+0000
+   through U+001F).
+
+   Any character may be escaped.  If the character is in the Basic
+   Multilingual Plane (U+0000 through U+FFFF), then it may be
+   represented as a six-character sequence: a reverse solidus, followed
+   by the lowercase letter u, followed by four hexadecimal digits that
+   encode the character's code point.  The hexadecimal letters A though
+   F can be upper or lower case.  So, for example, a string containing
+   only a single reverse solidus character may be represented as
+   "\u005C".
+
+   Alternatively, there are two-character sequence escape
+   representations of some popular characters.  So, for example, a
+   string containing only a single reverse solidus character may be
+   represented more compactly as "\\".
+
+   To escape an extended character that is not in the Basic Multilingual
+   Plane, the character is represented as a 12-character sequence,
+   encoding the UTF-16 surrogate pair.  So, for example, a string
+   containing only the G clef character (U+1D11E) may be represented as
+   "\uD834\uDD1E".
+
+      string = quotation-mark *char quotation-mark
+
+      char = unescaped /
+          escape (
+              %x22 /          ; "    quotation mark  U+0022
+              %x5C /          ; \    reverse solidus U+005C
+              %x2F /          ; /    solidus         U+002F
+              %x62 /          ; b    backspace       U+0008
+              %x66 /          ; f    form feed       U+000C
+              %x6E /          ; n    line feed       U+000A
+              %x72 /          ; r    carriage return U+000D
+              %x74 /          ; t    tab             U+0009
+              %x75 4HEXDIG )  ; uXXXX                U+XXXX
+
+      escape = %x5C              ; \
+
+      quotation-mark = %x22      ; "
+
+      unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
+
+
+
+Bray                         Standards Track                    [Page 8]
+
+RFC 7159                          JSON                        March 2014
+
+
+8.  String and Character Issues
+
+8.1.  Character Encoding
+
+   JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32.  The default
+   encoding is UTF-8, and JSON texts that are encoded in UTF-8 are
+   interoperable in the sense that they will be read successfully by the
+   maximum number of implementations; there are many implementations
+   that cannot successfully read texts in other encodings (such as
+   UTF-16 and UTF-32).
+
+   Implementations MUST NOT add a byte order mark to the beginning of a
+   JSON text.  In the interests of interoperability, implementations
+   that parse JSON texts MAY ignore the presence of a byte order mark
+   rather than treating it as an error.
+
+8.2.  Unicode Characters
+
+   When all the strings represented in a JSON text are composed entirely
+   of Unicode characters [UNICODE] (however escaped), then that JSON
+   text is interoperable in the sense that all software implementations
+   that parse it will agree on the contents of names and of string
+   values in objects and arrays.
+
+   However, the ABNF in this specification allows member names and
+   string values to contain bit sequences that cannot encode Unicode
+   characters; for example, "\uDEAD" (a single unpaired UTF-16
+   surrogate).  Instances of this have been observed, for example, when
+   a library truncates a UTF-16 string without checking whether the
+   truncation split a surrogate pair.  The behavior of software that
+   receives JSON texts containing such values is unpredictable; for
+   example, implementations might return different values for the length
+   of a string value or even suffer fatal runtime exceptions.
+
+8.3.  String Comparison
+
+   Software implementations are typically required to test names of
+   object members for equality.  Implementations that transform the
+   textual representation into sequences of Unicode code units and then
+   perform the comparison numerically, code unit by code unit, are
+   interoperable in the sense that implementations will agree in all
+   cases on equality or inequality of two strings.  For example,
+   implementations that compare strings with escaped characters
+   unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not
+   equal.
+
+
+
+
+
+
+Bray                         Standards Track                    [Page 9]
+
+RFC 7159                          JSON                        March 2014
+
+
+9.  Parsers
+
+   A JSON parser transforms a JSON text into another representation.  A
+   JSON parser MUST accept all texts that conform to the JSON grammar.
+   A JSON parser MAY accept non-JSON forms or extensions.
+
+   An implementation may set limits on the size of texts that it
+   accepts.  An implementation may set limits on the maximum depth of
+   nesting.  An implementation may set limits on the range and precision
+   of numbers.  An implementation may set limits on the length and
+   character contents of strings.
+
+10.  Generators
+
+   A JSON generator produces JSON text.  The resulting text MUST
+   strictly conform to the JSON grammar.
+
+11.  IANA Considerations
+
+   The MIME media type for JSON text is application/json.
+
+   Type name:  application
+
+   Subtype name:  json
+
+   Required parameters:  n/a
+
+   Optional parameters:  n/a
+
+   Encoding considerations:  binary
+
+   Security considerations:  See [RFC7159], Section 12.
+
+   Interoperability considerations:  Described in [RFC7159]
+
+   Published specification:  [RFC7159]
+
+   Applications that use this media type:
+      JSON has been used to exchange data between applications written
+      in all of these programming languages: ActionScript, C, C#,
+      Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript,
+      Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, and
+      Scheme.
+
+
+
+
+
+
+
+
+Bray                         Standards Track                   [Page 10]
+
+RFC 7159                          JSON                        March 2014
+
+
+   Additional information:
+      Magic number(s): n/a
+      File extension(s): .json
+      Macintosh file type code(s): TEXT
+
+   Person & email address to contact for further information:
+      IESG
+      <iesg@ietf.org>
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  none
+
+   Author:
+      Douglas Crockford
+      <douglas@crockford.com>
+
+   Change controller:
+      IESG
+      <iesg@ietf.org>
+
+   Note:  No "charset" parameter is defined for this registration.
+      Adding one really has no effect on compliant recipients.
+
+12.  Security Considerations
+
+   Generally, there are security issues with scripting languages.  JSON
+   is a subset of JavaScript but excludes assignment and invocation.
+
+   Since JSON's syntax is borrowed from JavaScript, it is possible to
+   use that language's "eval()" function to parse JSON texts.  This
+   generally constitutes an unacceptable security risk, since the text
+   could contain executable code along with data declarations.  The same
+   consideration applies to the use of eval()-like functions in any
+   other programming language in which JSON texts conform to that
+   language's syntax.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bray                         Standards Track                   [Page 11]
+
+RFC 7159                          JSON                        March 2014
+
+
+13.  Examples
+
+   This is a JSON object:
+
+      {
+        "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]
+          }
+      }
+
+   Its Image member is an object whose Thumbnail member is an object and
+   whose IDs member is an array of numbers.
+
+   This is a JSON array containing two objects:
+
+      [
+        {
+           "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"
+        }
+      ]
+
+
+
+
+
+Bray                         Standards Track                   [Page 12]
+
+RFC 7159                          JSON                        March 2014
+
+
+   Here are three small JSON texts containing only values:
+
+   "Hello world!"
+
+   42
+
+   true
+
+14.  Contributors
+
+   RFC 4627 was written by Douglas Crockford.  This document was
+   constructed by making a relatively small number of changes to that
+   document; thus, the vast majority of the text here is his.
+
+15.  References
+
+15.1.  Normative References
+
+   [IEEE754]  IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
+              Standard 754, August 2008,
+              <http://grouper.ieee.org/groups/754/>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
+              <http://www.unicode.org/versions/latest/>.
+
+15.2.  Informative References
+
+   [ECMA-262] Ecma International, "ECMAScript Language Specification
+              Edition 5.1", Standard ECMA-262, June 2011,
+              <http://www.ecma-international.org/publications/standards/
+              Ecma-262.htm>.
+
+   [ECMA-404] Ecma International, "The JSON Data Interchange Format",
+              Standard ECMA-404, October 2013,
+              <http://www.ecma-international.org/publications/standards/
+              Ecma-404.htm>.
+
+   [Err3607]  RFC Errata, Errata ID 3607, RFC 3607,
+              <http://www.rfc-editor.org>.
+
+
+
+
+
+
+Bray                         Standards Track                   [Page 13]
+
+RFC 7159                          JSON                        March 2014
+
+
+   [Err607]   RFC Errata, Errata ID 607, RFC 607,
+              <http://www.rfc-editor.org>.
+
+   [RFC4627]  Crockford, D., "The application/json Media Type for
+              JavaScript Object Notation (JSON)", RFC 4627, July 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bray                         Standards Track                   [Page 14]
+
+RFC 7159                          JSON                        March 2014
+
+
+Appendix A.  Changes from RFC 4627
+
+   This section lists changes between this document and the text in RFC
+   4627.
+
+   o  Changed the title and abstract of the document.
+
+   o  Changed the reference to [UNICODE] to be not version specific.
+
+   o  Added a "Specifications of JSON" section.
+
+   o  Added an "Introduction to This Revision" section.
+
+   o  Changed the definition of "JSON text" so that it can be any JSON
+      value, removing the constraint that it be an object or array.
+
+   o  Added language about duplicate object member names, member
+      ordering, and interoperability.
+
+   o  Clarified the absence of a requirement that values in an array be
+      of the same JSON type.
+
+   o  Applied erratum #607 from RFC 4627 to correctly align the artwork
+      for the definition of "object".
+
+   o  Changed "as sequences of digits" to "in the grammar below" in the
+      "Numbers" section, and made base-10-ness explicit.
+
+   o  Added language about number interoperability as a function of
+      IEEE754, and added an IEEE754 reference.
+
+   o  Added language about interoperability and Unicode characters and
+      about string comparisons.  To do this, turned the old "Encoding"
+      section into a "String and Character Issues" section, with three
+      subsections: "Character Encoding", "Unicode Characters", and
+      "String Comparison".
+
+   o  Changed guidance in the "Parsers" section to point out that
+      implementations may set limits on the range "and precision" of
+      numbers.
+
+   o  Updated and tidied the "IANA Considerations" section.
+
+   o  Made a real "Security Considerations" section and lifted the text
+      out of the previous "IANA Considerations" section.
+
+
+
+
+
+
+Bray                         Standards Track                   [Page 15]
+
+RFC 7159                          JSON                        March 2014
+
+
+   o  Applied erratum #3607 from RFC 4627 by removing the security
+      consideration that begins "A JSON text can be safely passed" and
+      the JavaScript code that went with that consideration.
+
+   o  Added a note to the "Security Considerations" section pointing out
+      the risks of using the "eval()" function in JavaScript or any
+      other language in which JSON texts conform to that language's
+      syntax.
+
+   o  Added a note to the "IANA Considerations" clarifying the absence
+      of a "charset" parameter for the application/json media type.
+
+   o  Changed "100" to 100 and added a boolean field, both in the first
+      example.
+
+   o  Added examples of JSON texts with simple values, neither objects
+      nor arrays.
+
+   o  Added a "Contributors" section crediting Douglas Crockford.
+
+   o  Added a reference to RFC 4627.
+
+   o  Moved the ECMAScript reference from Normative to Informative and
+      updated it to reference ECMAScript 5.1, and added a reference to
+      ECMA 404.
+
+Author's Address
+
+   Tim Bray (editor)
+   Google, Inc.
+
+   EMail: tbray@textuality.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bray                         Standards Track                   [Page 16]
+