4 ms·
JSON is a much better serialization format since XML was designed as a document format. For example, there is no standardized way to serialize a string with a n
by slaymaker1907 3y ago
JSON is a much better serialization format since XML was designed as a document format. For example, there is no standardized way to serialize a string with a null character even if you escape it (this is allowed in many programming languages). JSON just says do “\0” and calls it a day. I’m not sure if it’s better for users, but it’s certainly easier to work with as a dev.
HTML isn’t trying to serialize abstract data and is doing what XML does best in being a document/GUI format. It doesn’t matter all that much that it can’t represent null characters in a standard way because it isn’t a printable character.
- crabbone 3y agoTry using UTF-8 encoding for XML, and your problems with zero byte encoding will go away. Your understanding of "easier" is oversimplified to the point that it's wrong. It's easier to do the wrong thing in JSON, it's harder to do the right thing in JSON (compared to XML). JSON is a poorly thought-out format. It's problems become progressively more difficult to deal with the more you expect of your program.
- unilynx 3y agoJSON and XML both support UTF-8. Neither supports embedding arbitrary binary data directly, especially if that data is not valid in your current character set
- crabbone 3y agoYou wanted to send zero byte. This is how you send zero byte. You are making unrelated claims now that has nothing to do with your original claim.
- unilynx 3y agoYou can't safely send zero bytes over XML even with UTF-8 encoding. Not in practice: echo '<zero> </zero>' | xmllint - -:1: parser error : xmlParseCharRef: invalid xmlChar value 0 <zero> </zero> ^ printf '<?xml version="1.0" encoding="utf-8"?><zero>\0</zero>' | xmllint - -:1: parser error : Premature end of data in tag zero line 1 <?xml version="1.0" encoding="utf-8"?><zero> ^ And not in theory: https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-formed https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-form... Character Range [2] Char ::= [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ [2a] RestrictedChar ::= [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]
- crabbone 3y agoI explained how to do it, and yet you didn't follow instructions, have done something irrelevant, and are now complaining that it doesn't work... well sucks being you, I guess.
- peoplefromibiza 3y ago> JSON just says do “\0” and calls it a day nope jq "." <<< "\0" parse error: Invalid numeric literal at line 2, column 0 jq "." <<< '{"name": "\0"}' parse error: Invalid escape at line 1, column 13 maybe you mean null, which has a lot of different issues though. jq "." <<< "null" null jq "." <<< '{"name": null}' { "name": null }
- maskros 3y ago"\0" is not a valid JSON string escape sequence. However, "\u0000" is.
- peoplefromibiza 3y agonot according to jq or firefox >> JSON.parse("\u0000") Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data <anonymous> debugger eval code:1 at that point "null" looks like a better more compatible option.
- unilynx 3y agothey're not comparable at all. you can't embed a null into a string \u0000 works fine with firefox with the proper syntax JSON.parse(`"\\u0000"`) "\u0000" and jq supports it too printf '{"null":"\u0000"}' | jq { "null": "\u0000" }
- deleted 3y ago[deleted]
- peoplefromibiza 3y ago> the proper syntax of course! I forgot to quote those quotes! (facepalm) that works. and uses a single byte too. TIL.