doc/conformance.rst

   1 .. _rfc-conformance:
   2
   3 ***************
   4 RFC Conformance
   5 ***************
   6
   7 JSON is specified in :rfc:`4627`, *"The application/json Media Type
   8 for JavaScript Object Notation (JSON)"*. This chapter discusses
   9 Jansson's conformance to this specification.
  10
  11 Character Encoding
  12 ==================
  13
  14 Jansson only supports UTF-8 encoded JSON texts. It does not support or
  15 auto-detect any of the other encodings mentioned in the RFC, namely
  16 UTF-16LE, UTF-16BE, UTF-32LE or UTF-32BE. Pure ASCII is supported, as
  17 it's a subset of UTF-8.
  18
  19 Strings
  20 =======
  21
  22 JSON strings are mapped to C-style null-terminated character arrays,
  23 and UTF-8 encoding is used internally. Strings may not contain
  24 embedded null characters, not even escaped ones.
  25
  26 For example, trying to decode the following JSON text leads to a parse
  27 error::
  28
  29     ["this string contains the null character: \u0000"]
  30
  31 All other Unicode codepoints U+0001 through U+10FFFF are allowed.
  32
  33 Numbers
  34 =======
  35
  36 Real vs. Integer
  37 ----------------
  38
  39 JSON makes no distinction between real and integer numbers; Jansson
  40 does. Real numbers are mapped to the ``double`` type and integers to
  41 the ``int`` type.
  42
  43 A JSON number is considered to be a real number if its lexical
  44 representation includes one of ``e``, ``E``, or ``.``; regardless if
  45 its actual numeric value is a true integer (e.g., all of ``1E6``,
  46 ``3.0``, ``400E-2``, and ``3.14E3`` are mathematical integers, but
  47 will be treated as real values).
  48
  49 All other JSON numbers are considered integers.
  50
  51 When encoding to JSON, real values are always represented
  52 with a fractional part; e.g., the ``double`` value 3.0 will be
  53 represented in JSON as ``3.0``, not ``3``.
  54
  55 Overflow, Underflow & Precision
  56 -------------------------------
  57
  58 Real numbers whose absolute values are too small to be represented in
  59 a C double will be silently estimated with 0.0. Thus, depending on
  60 platform, JSON numbers very close to zero such as 1E-999 may result in
  61 0.0.
  62
  63 Real numbers whose absolute values are too large to be represented in
  64 a C ``double`` type will result in an overflow error (a JSON decoding
  65 error). Thus, depending on platform, JSON numbers like 1E+999 or
  66 -1E+999 may result in a parsing error.
  67
  68 Likewise, integer numbers whose absolute values are too large to be
  69 represented in the ``int`` type will result in an overflow error (a
  70 JSON decoding error). Thus, depending on platform, JSON numbers like
  71 1000000000000000 may result in parsing error.
  72
  73 Parsing JSON real numbers may result in a loss of precision. As long
  74 as overflow does not occur (i.e. a total loss of precision), the
  75 rounded approximate value is silently used. Thus the JSON number
  76 1.000000000000000005 may, depending on platform, result in the
  77 ``double`` value 1.0.
  78
  79 Signed zeros
  80 ------------
  81
  82 JSON makes no statement about what a number means; however Javascript
  83 (ECMAscript) does state that +0.0 and -0.0 must be treated as being
  84 distinct values, i.e. -0.0 |not-equal| 0.0. Jansson relies on the
  85 underlying floating point library in the C environment in which it is
  86 compiled. Therefore it is platform-dependent whether 0.0 and -0.0 will
  87 be distinct values. Most platforms that use the IEEE 754
  88 floating-point standard will support signed zeros.
  89
  90 Note that this only applies to floating-point; neither JSON, C, or
  91 IEEE support the concept of signed integer zeros.
  92
  93 .. |not-equal| unicode:: U+2260
  94
  95 Types
  96 -----
  97
  98 No support is provided in Jansson for any C numeric types other than
  99 ``int`` and ``double``. This excludes things such as unsigned types,
 100 ``long``, ``long long``, ``long double``, etc. Obviously, shorter
 101 types like ``short`` and ``float`` are implicitly handled via the
 102 ordinary C type coercion rules (subject to overflow semantics). Also,
 103 no support or hooks are provided for any supplemental "bignum" type
 104 add-on packages.