conformance.rst 4.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120
  1. .. _rfc-conformance:
  2. ***************
  3. RFC Conformance
  4. ***************
  5. JSON is specified in :rfc:`4627`, *"The application/json Media Type
  6. for JavaScript Object Notation (JSON)"*.
  7. Character Encoding
  8. ==================
  9. Jansson only supports UTF-8 encoded JSON texts. It does not support or
  10. auto-detect any of the other encodings mentioned in the RFC, namely
  11. UTF-16LE, UTF-16BE, UTF-32LE or UTF-32BE. Pure ASCII is supported, as
  12. it's a subset of UTF-8.
  13. Strings
  14. =======
  15. JSON strings are mapped to C-style null-terminated character arrays,
  16. and UTF-8 encoding is used internally.
  17. All Unicode codepoints U+0000 through U+10FFFF are allowed in string
  18. values. However, U+0000 is not allowed in object keys because of API
  19. restrictions.
  20. Unicode normalization or any other transformation is never performed
  21. on any strings (string values or object keys). When checking for
  22. equivalence of strings or object keys, the comparison is performed
  23. byte by byte between the original UTF-8 representations of the
  24. strings.
  25. Numbers
  26. =======
  27. .. _real-vs-integer:
  28. Real vs. Integer
  29. ----------------
  30. JSON makes no distinction between real and integer numbers; Jansson
  31. does. Real numbers are mapped to the ``double`` type and integers to
  32. the ``json_int_t`` type, which is a typedef of ``long long`` or
  33. ``long``, depending on whether ``long long`` is supported by your
  34. compiler or not.
  35. A JSON number is considered to be a real number if its lexical
  36. representation includes one of ``e``, ``E``, or ``.``; regardless if
  37. its actual numeric value is a true integer (e.g., all of ``1E6``,
  38. ``3.0``, ``400E-2``, and ``3.14E3`` are mathematical integers, but
  39. will be treated as real values). With the ``JSON_DECODE_INT_AS_REAL``
  40. decoder flag set all numbers are interpreted as real.
  41. All other JSON numbers are considered integers.
  42. When encoding to JSON, real values are always represented
  43. with a fractional part; e.g., the ``double`` value 3.0 will be
  44. represented in JSON as ``3.0``, not ``3``.
  45. Overflow, Underflow & Precision
  46. -------------------------------
  47. Real numbers whose absolute values are too small to be represented in
  48. a C ``double`` will be silently estimated with 0.0. Thus, depending on
  49. platform, JSON numbers very close to zero such as 1E-999 may result in
  50. 0.0.
  51. Real numbers whose absolute values are too large to be represented in
  52. a C ``double`` will result in an overflow error (a JSON decoding
  53. error). Thus, depending on platform, JSON numbers like 1E+999 or
  54. -1E+999 may result in a parsing error.
  55. Likewise, integer numbers whose absolute values are too large to be
  56. represented in the ``json_int_t`` type (see above) will result in an
  57. overflow error (a JSON decoding error). Thus, depending on platform,
  58. JSON numbers like 1000000000000000 may result in parsing error.
  59. Parsing JSON real numbers may result in a loss of precision. As long
  60. as overflow does not occur (i.e. a total loss of precision), the
  61. rounded approximate value is silently used. Thus the JSON number
  62. 1.000000000000000005 may, depending on platform, result in the
  63. ``double`` value 1.0.
  64. Signed zeros
  65. ------------
  66. JSON makes no statement about what a number means; however Javascript
  67. (ECMAscript) does state that +0.0 and -0.0 must be treated as being
  68. distinct values, i.e. -0.0 |not-equal| 0.0. Jansson relies on the
  69. underlying floating point library in the C environment in which it is
  70. compiled. Therefore it is platform-dependent whether 0.0 and -0.0 will
  71. be distinct values. Most platforms that use the IEEE 754
  72. floating-point standard will support signed zeros.
  73. Note that this only applies to floating-point; neither JSON, C, or
  74. IEEE support the concept of signed integer zeros.
  75. .. |not-equal| unicode:: U+2260
  76. Types
  77. -----
  78. No support is provided in Jansson for any C numeric types other than
  79. ``json_int_t`` and ``double``. This excludes things such as unsigned
  80. types, ``long double``, etc. Obviously, shorter types like ``short``,
  81. ``int``, ``long`` (if ``json_int_t`` is ``long long``) and ``float``
  82. are implicitly handled via the ordinary C type coercion rules (subject
  83. to overflow semantics). Also, no support or hooks are provided for any
  84. supplemental "bignum" type add-on packages.
  85. Depth of nested values
  86. ----------------------
  87. To avoid stack exhaustion, Jansson currently limits the nesting depth
  88. for arrays and objects to a certain value (default: 2048), defined as
  89. a macro ``JSON_PARSER_MAX_DEPTH`` within ``jansson_config.h``.
  90. The limit is allowed to be set by the RFC; there is no recommended value
  91. or required minimum depth to be supported.