This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Nick Barnes, lemburg, vstinner
Date 2008-11-25.13:30:08
SpamBayes Score 1.12306e-09
Marked as misclassified No
Message-id <492BFDDF.4030402@egenix.com>
In-reply-to <1227611516.22.0.455645816232.issue4426@psf.upfronthosting.co.za>
Content
On 2008-11-25 12:11, Nick Barnes wrote:
> New submission from Nick Barnes <Nick.Barnes@pobox.com>:
> 
> UTF-7 decoding raises an exception for any character not in the RFC2152
> "Set D" (directly encoded characters).  In particular, it raises an
> exception for characters in "Set O" (optional direct characters), such
> as < = > [ ] @ etc.  These characters can legitimately appear in
> UTF-7-encoded text, and should be decoded (as themselves).  As it is,
> the UTF-7 decoder can't reliably be used to decode any UTF-7 text other
> than that encoded by Python's own UTF-7 encoder.

Thanks for noticing this. Apparently, the UTF-7 codec is not used
a lot by Python users, since it's been like this for years.

The tests we have do check round-trip safety, but not the special
characteristics of the UTF-7 codec.

Also note that the code for the codec was contributed and is, AFAIK,
not maintained by any of the Python developers.
History
Date User Action Args
2008-11-25 13:30:09lemburgsetrecipients: + lemburg, vstinner, Nick Barnes
2008-11-25 13:30:08lemburglinkissue4426 messages
2008-11-25 13:30:08lemburgcreate