-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unicode in email.MIMEText and email/Charset.py #42634
Comments
This is the test case that fails in python 2.4.1: And attached is a patch to correct it. |
Your proposed patch doesn't seem to work in Python 2.5, or the trunk (i.e. it won't prevent an exception from occuring). Can you please revise it? |
How about this version? |
It was proposed to rewrite MIMEText in Python 3.1 (and 2.7?) to use |
The patch by maxua works fine with 2.6 too and solves the problem. |
What is the status of this? |
It looks to me like MIMEText doesn't actually support unicode input. . One way to get the example to work is to do this: MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430'.encode('utf-8'), 'plain', 'utf-8') The above call produces valid output from as_string: 'Content-Type: text/plain; charset="utf-8"\nMIME-Version: How you'd get it to use 8bit, I have no idea. Still, I'm inclined to (CF: http://mg.pov.lt/blog/unicode-emails-in-python for a good example Clearly, the documentation of this could be better, but I suspect the |
After applying maxua's patch we do not get the unicode error but as david stated the support is not there. Here is the test. >>> import email
>>> msg = email.MIMEText.MIMEText(u'\u043a\u0438\u0440\u0438\u043b\u0438\u0446\u0430')
>>> msg.set_charset('utf8')
>>> msg.as_string()
'MIME-Version: 1.0\nContent-Transfer-Encoding: 8bit\nContent-Type: text/plain; charset="utf8"\n\n\xd0\xba\xd0\xb8\xd1\x80\xd0\xb8\xd0\xbb\xd0\xb8\xd1\x86\xd0\xb0' This does not seems a viable general solution to the problem. I guess, this issue should be closed and emphasis should be now on development of 'email 6.0'. By the way I mailed Marius, the author of the blog-post http://mg.pov.lt/blog/unicode-emails-in-python , if I can borrow his example for the doc-patch. |
Hi David, + if isinstance(payload, unicode): looks fine enough to me. Are you worried about the /or 'us-ascii'/ part of this patch? IMHO, the patch may prevent the straight forward Exception for which the issue was raised. But on a larger scale, it is advisable to document MIMEText usage wth encoding as you mentioned. |
I don't think either of the previous patches are correct. I found a note in bpo-1685453 that Barry would like for this to work, and after poking around in the code for a bit I think it can be done without breaking anything. Attached is a patch that adds unicode support to MIMEText, including unit tests and docs updates. Note that it is necessary to specify a charset if you have non-ASCII text in your unicode string, since the default charset is us-ascii. The unit tests confirm this behavior. Now the question is, is this a bug-fix or an enhancement? I *think* it is safe to apply and backport, since I think the only behavior it changes is to make unicode input work, whereas before it would give a traceback. But I've been wrong before :( |
Ah, it's not 100% true that it doesn't change "working" behavior. Before the patch, the first example in this ticket doesn't raise an error until the as_string call. After this patch, the error is raised as soon as MIMEText is called without the charset parameter. Since without the patch the code still fails eventually, I think this is an acceptable behavior change for a bug fix, but it does make me a little nervous :) Updated patch with doc change to Message.set_charset attached. |
Committed to 2.7 in r81658 and 2.6 in r81659. I'm leaving this open for the moment because while py3 doesn't have this problem, the tests should still pass and they don't. |
OK, py3k now passes all but one of the tests, and I've disabled that one pending email6 since fixing it would break backward compatibility within the 3.x series. The fix is different, doing the encoding to output_charset just before calling base64mime. This makes me think that quopri in py3k probably isn't working right, but that's a different issue. I did not forward port the doc changes as they are inappropriate for py3k. py3k patched in r81660, 3.1 in r81661. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: