String string VS list encoder
The current encode function places very little burden on the user and performs a fixed conversion over values with little fuss. There is a special case, however, where a list of integer values that just happens to be valid UTF-8 codepoints could be encountered and encoded as a string instead of a list of integers. encode/1
currently picks between lists and strings by checking whether a given io_list validates as "printable unicode" or not according to io_lib:printable_unicode_list/1
.
Erlangers are already familiar with this case because of Erlang's loose definition of strings, but JSON separates lists of integers from strings in a concrete way.
To provide a "strict" encoding route a new function strict_encode/1
is requested. This function will inerpret all lists in value positions as lists regardless their contents (meaning that Erlang strings will be converted to lists of integers) and all binaries will be interpreted as UTF-8 strings. Strings used as map keys will be converted according to the current rules.
This implies, of course, that strict_encode/1
will place the burden of input correctness on the user. Hopefully not too much. The trick will be that all strings will need to be either generated as binaries to begin with or converted from their more edit-friendly forms via unicode:characters_to_binary/1
before being encoded as JSON.