>>>>> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes:
Martin> Stephen J. Turnbull wrote:
Bengt> The characters in b could be encoded in plain ascii, or
Bengt> utf16le, you have to know.
>> Which base64 are you thinking about? Both RFC 3548 and RFC
>> 2045 (MIME) specify subsets of US-ASCII explicitly.
Martin> Unfortunately, it is ambiguous as to whether they refer to
Martin> US-ASCII, the character set, or US-ASCII, the encoding.
True for RFC 3548, but the authors of RFC 2045 clearly had the
encoding in mind, since they depend on RFC 822.
Martin> It appears that RFC 3548 talks about the character set
Martin> only:
OK, although RFC 3548 cites RFC 20 (!) as its source for US-ASCII,
which clearly has bytes (though not necessarily octets) in mind, it
doesn't actually restrict base encoding to be a subset of US-ASCII.
On the other hand, RFC 3548 doesn't define "base64" (or any other base
encoding), it simply provides a set of requirements that a conforming
implementation must satisfy. Python can therefore choose to define
its base64 as a bytes->bytes codec, with the alphabet drawn from
US-ASCII interpreted as encoding.
I would definitely prefer that, as png_image = unicode.encode('base64')
violates MAL's intuitive schema for the method.
Martin> For an example where base64 is *not* necessarily
Martin> ASCII-encoded, see the "binary" data type in XML
Martin> Schema. There, base64 is embedded into an XML document,
Martin> and uses the encoding of the entire XML document. As a
Martin> result, you may get base64 data in utf16le.
I'll have to take a look. It depends on whether base64 is specified
as an octet-stream to Unicode stream transformation or as an embedding
of an intermediate representation into Unicode. Granted, defining the
base64 alphabet as a subset of Unicode seems like the logical way to
do it in the context of XML.
P.S. My apologies for munging your name in the To: header. I'm
having problems with my MUA.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
