cjson encode table encodes `/`

[ktalebian]

Doing:

cjson.encode({url =  "https://google.com})

prints {"url":"https:\/\/google.com"}. I'm trying to stringify a JSON object here, and don't expect to get the / escaped. Is there any solution?

[dorongold]

We have a similar issue. Can cjson provide an option to disable escaping of forward slashes?

The JSON spec says you CAN escape forward slash, but you don't have to. We have some 3rd-party json clients that consume the output of cjson.encode, but do not work correctly with escaped forward slashes. Also, in many programming languages, json encoders by default do not escape forward slashes.

[eyalleshem]

same issue for me - any work-around for that ?

[Jijun]

https://github.com/mpx/lua-cjson/pull/57

[MorseWayne]

#57

dont expect to much, just do it yourself, this pull request is really helpful

[jesse-greathouse]

If anyone else is troubled by the escaped forward slash, thanks to #57 for showing me the solution, this is what I've been doing to apply the fix before lua-cjson is compiled. My example is in the context of openresty but the operative line is the sed replacement

# Compile and Install Openresty
tar -xzf ${OPT}/openresty-*.tar.gz -C ${OPT}/

# Fix the escape frontslash feature of cjson
sed -i -e s/"    NULL, NULL, NULL, NULL, NULL, NULL, NULL, \"\\\\\\\\\/\","/"    NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,"/g ${OPT}/openresty-*/bundle/lua-cjson-2.1.0.7/lua_cjson.c

cd ${OPT}/openresty-*/
./configure --with-cc-opt="-I/usr/local/include -I/usr/local/opt/openssl/include" \
            --with-ld-opt="-L/usr/local/lib -L/usr/local/opt/openssl/lib" \
            --prefix=${OPT}/openresty \
            --with-pcre-jit \
            --with-ipv6 \
            --with-http_iconv_module \
            --with-http_realip_module \
            -j2 && \
make
make install

[aljungberg]

For what it's worth, openresty's fork of cjson solves this problem: https://github.com/openresty/lua-cjson/#encode_escape_forward_slash

[MEZboy]

For what it's worth, openresty's fork of cjson solves this problem: https://github.com/openresty/lua-cjson/#encode_escape_forward_slash

thanks a lot, this helped me, a huge hug for you~

[mpx]

To help understand the impact a bit better, does anyone have examples where decodes or APIs break with:

• escaped forward slash?
• non-escaped forward slash? If so, which ones?

If there is a clearly better choice we should just do that and avoid adding another configuration option. It sounds like Lua CJSON is an outlier here, and there would be fewer issues if it didn't escape forward slash.