I just needed a quick solution to dump the database and reload it in
another environment. So I made some changes to multipart.py to get pass
this utf-8 thing. It did work.
However, I understand that other parts are using multipart.py too. This
probably won't fit the MIME standard. If I have time, I'll investigate
further and provide a patch that does satisfy the MIME standard.
Attachments:
utf-8_dump_load.patch 1.1 KB
Confirm. There is also invalid test case about how multipart module works
with unicode data: StringIO could handle mixed "str" and "unicode" values,
but files requires only "str" one.
Sorry, I was wrong about tests - StringIO confused me(: Don't rush, sit
down and think about...yes(:
There is no needs to fix multipart module, only dump tool due to it pass
unicode document id to multipart writer. This is about dump-tool.patch.
dump-tool-2.patch solves same problem, but with respect of Content-Type
header and his charset. I suppose, that would a more correct solution.
Attachments:
dump-tool.patch 648 bytes
dump-tool-2.patch 1.5 KB
Ah, that's much smarter. Thanks!
Hmm... another thing. I was under the impression that utf-8 encoded strings
aren't valid ascii. Currently, isn't multipart.py expecting strict ascii
strings as header?
Actually, only first 128 chars of utf-8 encoding are valid ascii. Problem
was not in what characters in headers, but in type of string multipart
tries to write into output stream. Files and streams doesn't expects pure
unicode strings, but favors stings called as "bytes" in Python 3
terminology and multipart module expects this behavior.
But there was a "hack" which adds to headers document id which used by
couchdb-load tool to help create document with same id value. Since
document id could be unicode, this "hack" breaks expectations and makes
multipart crash.
You could try revert patch and replace in dump.py default value of output
argument in dump_db function from sys.stdout to StringIO.StringIO and error
wouldn't be occurred because StringIO could handle both str and unicode
values.
IMO the correct way to have non-ASCII strings in MIME headers would be to
use RFC 2047 encoding for any non-ascii header values.
Correct, but looks like an overhead in such case, because it would applied
only to one header while others should follow RFC 822. Wouldn't be better
to use base64 encoding?
Hmm... I'd like to make a note here that kxepal's dump-tool-2.patch
actually generated some invalid multipart boundaries.