From HandWiki - Reading time: 4 min
| Type code | TEXT |
|---|---|
| Type of format | Data interchange |
| Extended from | JSON |
| Website | jsonurl |
JSON→URL is a language-independent data interchange format for the JSON data model[1] suitable for use within a URL/URI query string. It is defined by an open specification,[2] though not through a standards body.
JSON→URL implements the JSON data model:,[1] with support for the following data types[2]
true or falsenull+ or %20.The following example shows a possible JSON→URL representation describing a person.
(firstName:John,lastName:Smith,isAlive:true,age:27,address:(streetAddress:21+2nd+Street,city:New+York,state:NY,postalCode:10021-3100),phoneNumbers:((type:home,number:212+555-1234),(type:office,number:646+555-4567)),children:(),spouse:null)
JSON→URL implements the JSON data model,[1] however, it does not differentiate between an empty object and an empty array. Instead, it defines an empty composite value as ().
JSON→URL exchange in an open ecosystem must be encoded in UTF-8.[2] The encoding supports the full Unicode character set, including those characters outside the Basic Multilingual Plane (U+10000 to U+10FFFF). Unlike JSON, JSON→URL does not define a separate syntax for escaping characters within a string literal. Such characters are simply composed of one or more percent encoded octets.
Numbers in JSON→URL are agnostic with regard to their representation within programming languages. While this allows for numbers of arbitrary precision to be serialized, it may lead to portability issues. For example, since no differentiation is made between integer and floating-point values, some implementations may treat 42, 42.0, and 4.2E+1 as the same number, while others may not. The JSON→URL standard makes no requirements regarding implementation details such as overflow, underflow, loss of precision, rounding, or signed zeros.
While JSON→URL provides a syntactic framework for data interchange, unambiguous data interchange also requires agreement between producer and consumer on the semantics of a specific use of the JSON→URL syntax. One example of where such an agreement is necessary is the serialization of data types local to a specific implementation (e.g. Java, JavaScript) that are not defined in the JSON→URL specification, such as Date.