Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #109881
| From | Random832 <random832@fastmail.com> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: base64.b64encode(data) |
| Date | 2016-06-12 23:20 -0400 |
| Message-ID | <mailman.26.1465788060.2288.python-list@python.org> (permalink) |
| References | <ccd85c61-263c-4ebd-b47f-b35fafa3f521@googlegroups.com> <575e18f1$0$1588$c3e8da3$5496439d@news.astraweb.com> <1465788057.2854167.635655857.445F242C@webmail.messagingengine.com> |
On Sun, Jun 12, 2016, at 22:22, Steven D'Aprano wrote: > That's because base64 is a bytes-to-bytes transformation. It has > nothing to do with unicode encodings. Nonsense. base64 is a binary-to-text encoding scheme. The output range is specifically chosen to be safe to transmit in text protocols. > > That is, the b64_encoded_data variable is of type 'bytes' and when > > you peek inside it's a string (made up of what seems to be only > > characters that exist in Base 64). > > If you print or otherwise display bytes, for the convenience of human > beings, those bytes are displayed as if they were ASCII. E.g. the byte > 0x61 is displayed as 'a'. Good idea? Bad idea? I can see arguments > either way, but that's how it is. There's absolutely no rational basis for choosing "0x41-0x5A, 0x61-0x7A, 0x30-0x39, 0x2B, 0x2F" as the output range except for what characters those values represent in ASCII. And if you needed to smuggle some binary data through an EBCDIC system in the same manner, you would naturally wish to convert it to the EBCDIC bytes corresponding to those same characters.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
base64.b64encode(data) Marcin Rak <mrak@sightlineinnovation.com> - 2016-06-12 11:56 -0700
Re: base64.b64encode(data) Marko Rauhamaa <marko@pacujo.net> - 2016-06-12 22:26 +0300
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-13 12:22 +1000
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-12 23:20 -0400
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-13 15:16 +1000
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-13 01:33 -0400
Re: base64.b64encode(data) Marko Rauhamaa <marko@pacujo.net> - 2016-06-13 09:45 +0300
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-13 20:35 +1000
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-13 09:36 -0400
Re: base64.b64encode(data) Steven D'Aprano <steve@pearwood.info> - 2016-06-22 01:56 +1000
Re: base64.b64encode(data) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-06-13 20:20 -0400
Re: base64.b64encode(data) Michael Torrie <torriem@gmail.com> - 2016-06-13 09:15 -0600
Re: base64.b64encode(data) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-14 11:04 +1200
Re: base64.b64encode(data) Chris Angelico <rosuav@gmail.com> - 2016-06-14 03:07 +1000
Re: base64.b64encode(data) Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-14 11:12 +1200
Re: base64.b64encode(data) Random832 <random832@fastmail.com> - 2016-06-13 21:19 -0400
csiph-web