umgeher/jsx
0
Fork 0
Code Issues Pull requests Activity

tighter language in README

Browse source
This commit is contained in:
alisdair sullivan 2012-05-27 20:29:48 -07:00
parent 424d615994
commit 6f15acaf5d
1 changed files with 4 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

8
README.markdown
View file

@ -143,7 +143,7 @@ here is a table of how various json values map to erlang:
the utf8 restriction means improperly paired surrogates are explicitly disallowed. `u+d800` to `u+dfff` are allowed, but only when they form valid surrogate pairs. surrogates encountered otherwise result in errors
json string escapes of the form `\uXXXX` will be converted to their equivalent codepoints during parsing. this means control characters and other codepoints disallowed by the json spec may be encountered in resulting strings, but codepoints disallowed by the unicode spec will not be. in the interest of pragmatism there is an option for looser parsing. see [options](#option)
json string escapes of the form `\uXXXX` will be converted to their equivalent codepoints during parsing. this means control characters and other codepoints disallowed by the json spec may be encountered in resulting strings, but codepoints disallowed by the unicode spec will not be. in the interest of pragmatism there is an [option](#option) for looser parsing
all erlang strings are represented by *valid* `utf8` encoded binaries. the encoder will check strings for conformance. noncharacters (like `u+ffff`) are allowed in erlang utf8 encoded binaries, but not in strings passed to the encoder (although, again, see [options](#option))
@ -166,7 +166,7 @@ here is a table of how various json values map to erlang:
jsx handles incomplete json texts. if a partial json text is parsed, rather than returning a term from your callback handler, jsx returns `{incomplete, F}` where `F` is a function with an identical API to the anonymous fun returned from `decoder/3`, `encoder/3` or `parser/3`. it retains the internal state of the parser at the point where input was exhausted. this allows you to parse as you stream json over a socket or file descriptor, or to parse large json texts without needing to keep them entirely in memory
however, it is important to recognize that jsx is greedy by default. jsx will consider the parsing complete if input is exhausted and the json text is not unambiguously incomplete. this is mostly relevant when parsing bare numbers like `<<"1234">>`. this could be a complete json integer or just the beginning of a json integer that is being parsed incrementally. jsx will treat it as a whole integer. the option `explicit_end` can be used to modify this behaviour. see [options](#option)
however, it is important to recognize that jsx is greedy by default. jsx will consider the parsing complete if input is exhausted and the json text is not unambiguously incomplete. this is mostly relevant when parsing bare numbers like `<<"1234">>`. this could be a complete json integer or just the beginning of a json integer that is being parsed incrementally. jsx will treat it as a whole integer. the [option](#options) `explicit_end` can be used to modify this behaviour
## data types ##
@ -451,7 +451,7 @@ is_json(MaybeJSON, Opts) -> true | false
returns true if input is a valid json text, false if not
what exactly constitutes valid json may be altered per the [options](#option)
what exactly constitutes valid json may be [altered](#option)
#### `is_term/1,2` ####
@ -466,7 +466,7 @@ is_term(MaybeJSON, Opts) -> true | false
returns true if input is a valid erlang representation of json, false if not
what exactly constitutes valid json may be altered per the [options](#option)
what exactly constitutes valid json may be [altered](#option)
## callback exports ##