Hacker News Reader

Comment by cornstalks | Hacker News Reader

Am I the only one struggling to understand the hex dump? The author says "0x79 is the z in the ASCII table." That's wrong. 'z' is 0x7a.

The author also says "In UTF-8 all characters after 0x79 are at least two bytes long." That's also wrong. All characters after 0x7f get encoded as two or more bytes.

View on HN

He skips all the numbers where the hex-encoding has an A-F as the least significant digit. This makes everything bizarre.

But after 99, they are no longer skipped. Go figure.

Yeah it doesn't make a lot of sense. I feel like the author must be doing something wrong with CouchDB in the first place if his binary uploads are being converted to UTF-8. Not to mention that that kind of thing should always be checked application side anyways.

If you want to place binary data in CouchDB that's entirely possible. However, you have to create a document and then add an attachment to it. Attachments themselves can have multiple revisions.

When PUTing[1] the attachment the appropriate Content-Type header is required to be set. If both of these things are done properly I see no obvious reason as to why they'd run into the encoding issue mentioned. Which makes me suspect it's not properly using the attachment feature or not correctly setting the MIME type.

Or they're doing something weird when grabbing the binary data from the user, like not using FileReader.readAsArrayBuffer()[2] from their JS code and instead getting it as text. readAsArrayBuffer is specifically designed to deal with binary data, usually used with images in web context.

[1]: http://docs.couchdb.org/en/2.0.0/api/document/attachments.ht...

[2]: https://developer.mozilla.org/en-US/docs/Web/API/FileReader/...

Perhaps it's UCS-2 not UTF-8. Not interested enough to figure it out :-o

Reply on news.ycombinator.com