3 ms·

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 "I

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.

aphextron 10y ago
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.
- daenney 10y ago
  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.html http://docs.couchdb.org/en/2.0.0/api/document/attachments.ht... [2]: https://developer.mozilla.org/en-US/docs/Web/API/FileReader/readAsArrayBuffer https://developer.mozilla.org/en-US/docs/Web/API/FileReader/...
mnarayan01 10y ago
He skips all the numbers where the hex-encoding has an A-F as the least significant digit. This makes everything bizarre.
- jwilk 10y ago
  But after 99, they are no longer skipped. Go figure.
emmelaich 10y ago
Perhaps it's UCS-2 not UTF-8. Not interested enough to figure it out :-o

aphextron 10y ago

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.

daenney 10y ago
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.html http://docs.couchdb.org/en/2.0.0/api/document/attachments.ht... [2]: https://developer.mozilla.org/en-US/docs/Web/API/FileReader/readAsArrayBuffer https://developer.mozilla.org/en-US/docs/Web/API/FileReader/...

mnarayan01 10y ago

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

jwilk 10y ago
But after 99, they are no longer skipped. Go figure.

emmelaich 10y ago

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