-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Some important things are to be known before using jason. Please read carefully below chapters.
Keys, if no mode is set, or if {mode, struct} is used, are utf8 binaries.
For all other modes, keys will be converted to atoms.
However, if key length is more than 255 characters, or containing utf8 characters and local Erlang release < 20.0, key will be kept or converted to binary. This will not be possible for {mode, record} for which key must be atoms, and will raise an error in such case. This case should be rare fortunately.
Values, if no mode is set, or if {mode, struct} is used are utf8 binaries.
For all other modes, values will be converted to string if printable, otherwise kept in utf8 binary.
jason was created initially to handle easily Erlang records from and to JSON.
Erlang records are, finally, only tuples with an atom name as first element. This first element is lost while encoded in JSON, as JSON object are 'anonymous' (except by declaring object name in object itself). The problem is to affect the keys (left side) of JSON entries.
There is two ways to do this :
1- By passing record's key list as option : {records, [{RecordName1, [Field1, ...]}, ...]}
2- By asking jason to extract record info from process abstract code : {records, Pid()}
First way is easy by using built-in ``
Second way is slower, but has interest when many record definition has to be passed to encoding, or when module is dynamically compiled at runtime and record list cannot be known before. First way is recommended when possible for obvious performance reason.
Note : Pid() can be any process, and not necessary self(), the calling process.
jason decode JSON object