Hacker News new | past | comments | ask | show | jobs | submit login

> In Go if you get a list of all the filenames in the current directory, it's a list of strings, and the fact that those aren't actually text is your problem, you will need to explicitly take care of this or you can't emit valid JSON.

You'll still emit valid json. The encoding/json doc says:

> String values encode as JSON strings coerced to valid UTF-8, replacing invalid bytes with the Unicode replacement rune.




The original filenames will be lost though, if they weren't utf-8.


But to be fair if we're sending them as UTF-8 in a JSON file we can't do anything about that.

I've had situations where I am obliged to write output to XML, and clients are like, "You can't lose this weird data in our text". That's not me, that's XML, in XML 1.0 most of the ASCII Control Characters are banned (not like "You must escape this character" they are banned if you write them as text, escaped or not, that's not a valid XML file and some parsers won't read it). You can either admit you want binary data maybe wrapped as Base64 inside the XML or you can accept that in XML those characters are toast. I would turn all the banned characters into U+FFFD in XML.

JSON doesn't have that defect, but it still can't magically make non-text into text, and some filenames are not text. So this feels fair enough. Chances are if your JSON format is so capable that you can write "Here's a Non-text filename" and have that work almost all the people parsing it ignore that case and you didn't really improve interoperability at all.


Aha, useful. Good catch.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: