Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #109881

Re: base64.b64encode(data)

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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