On 31/08/13 15:21, R. David Murray wrote: > If you've read my blog (eg: on planet python), you will be aware that > I dedicated August to full time email package development. [...] The API looks really nice! Thank you for putting this together. A question comes to mind though: > All input strings are unicode, and the library takes care of doing > whatever encoding is required. When you pull data out of a parsed > message, you get unicode, without having to worry about how to decode > it yourself. How well does your library cope with emails where the encoding is declared wrongly? Or no encoding declared at all? Conveniently, your email is an example of this. Although it contains non-ASCII characters, it is declared as us-ascii: --===============1633676851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline which may explain why Stephen Turnbull's reply contains mojibake. -- Steven
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4