Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

JSON is not binary #68

Closed
mcandre opened this issue Sep 11, 2014 · 4 comments
Closed

JSON is not binary #68

mcandre opened this issue Sep 11, 2014 · 4 comments

Comments

@mcandre
Copy link

mcandre commented Sep 11, 2014

JSON should not be binary?. It is written and stored as plain text, usually ASCII or UTF-8.

BSON is binary.

@mcandre
Copy link
Author

mcandre commented Sep 12, 2014

A Redditor pointed out to me that #binary? in mime-types means something closer to "network transport set to base64".

http://rubydoc.org/gems/mime-types/MIME/Type#binary%3F-instance_method

Does the mime-types library offer another method to access this information?

@halostatue
Copy link
Member

You can get that directly from encoding. This bit of the code may need revisiting, but I'm not sure how people use it (it's part of the original code translated from the Perl about ten years ago).

@halostatue
Copy link
Member

Before I make this sort of change, I really have to look at how people are using mime-types. #71 indicates that people were using the list of extensions to find a preferred extension, and I don’t think I had ever considered that.

@halostatue
Copy link
Member

After further consideration, #ascii? and #binary? will be remaining as-is because the domain usage is accurate. The data contained in this library doesn’t really indicate whether the information is textual, structured textual, or some sort of binary encoding. One thing that was pointed out to me is that the JSON spec does not specify UTF-8 or ASCII as its encoding, but any valid Unicode—so it could be UTF-32, as well.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants