Hi Jakub, On Mon, Mar 30, 2015 at 5:45 PM, Jakub Zelenka <bu...@php.net> wrote:
> On Mon, Mar 30, 2015 at 1:07 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> >> "int" should be fixed also. >> http://3v4l.org/95dHM >> >> > We have already fix for this: JSON_BIGINT_AS_STRING ( > http://3v4l.org/vYXUk ) > Excellent. > > >> So option may be JSON_SCALAR_AS_STRING or >> additional JSON_INT_AS_STRING. >> >> > I was actually thinking about JSON_INT_AS_STRING anyway as it might be > useful for type consistency in decoding (when decoding number that are > close to bigint limit) and allowing safe encoding from 64bit to 32bit. > However this is a bit more controversial so I plan to open a new thread > about it. > There are too many options (4 options to be exact) for JSON to work safely under HTML context currently. If user would not like to loose int/float information, 6 options are needed. Number of options are better to be reduced, so big +1 for string raw data by default. It may be better to have JSON_HEX_HTML_CHARS = JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT also. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
