Le Thu, 25 Apr 2013 08:38:12 +0200, Lennart Regebro <rege...@gmail.com> a écrit : > On Thu, Apr 25, 2013 at 7:43 AM, Antoine Pitrou <solip...@pitrou.net> > wrote: > > On Thu, 25 Apr 2013 04:19:36 +0200 > > Lennart Regebro <rege...@gmail.com> wrote: > >> On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull > >> <step...@xemacs.org> wrote: > >> > RFC 4648 repeatedly refers to *characters*, without specifying an > >> > encoding for them. > > [...] > >> > >> Base64 is an encoding that transforms between 8-bit streams. > > > > No, it isn't. What Stephen wrote above. > > Yes it is. Base64 takes 8-bit bytes and transforms them into another > 8-bit stream that can be safely transmitted over various channels that > would mangle an unencoded 8-bit stream, such as email etc. > > http://en.wikipedia.org/wiki/Base64
I don't see anything in that Wikipedia page that validates your opinion. The Wikipedia page does talk about *text* and *characters* for the result of base64 encoding. Besides, I would consider a RFC more authoritative than a Wikipedia definition. > > By the same argument, we should suppress any > > encoding which isn't able to represent all possible unicode strings. > > No, if you explicitly use such an encoding it is because you need to > because you are transferring data to a system that needs the encoding > in question. Unicode errors are unavoidable at that point, not an > unexpected surprise because a conversion happened implicitly that you > didn't know about. I don't know what "implicit conversion" you are talking about. There's no "implicit conversion" in a scheme where the result of base64 encoding is a text string. Regards Antoine. _______________________________________________ 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
