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


Groups > comp.lang.python > #109888

Re: base64.b64encode(data)

From Random832 <random832@fastmail.com>
Newsgroups comp.lang.python
Subject Re: base64.b64encode(data)
Date 2016-06-13 01:33 -0400
Message-ID <mailman.28.1465795996.2288.python-list@python.org> (permalink)
References (1 earlier) <575e18f1$0$1588$c3e8da3$5496439d@news.astraweb.com> <1465788057.2854167.635655857.445F242C@webmail.messagingengine.com> <mailman.26.1465788060.2288.python-list@python.org> <575e4198$0$1588$c3e8da3$5496439d@news.astraweb.com> <1465795993.2881334.635716385.023A423E@webmail.messagingengine.com>

Show all headers | View raw


On Mon, Jun 13, 2016, at 01:16, Steven D'Aprano wrote:
> Suppose instead it returned the Unicode string 'AUERFg=='. That's all
> well and good, but what are you going to do with it? You can't
> transmit it over a serial cable, because that almost surely is going
> to expect bytes, so you have to encode it. You can't embed it in an
> email, because that also expects bytes.

Unless you're using a library that expects to receive strings and encode
them itself. Such as, in the example you so helpfully provide, a file
opened in text mode.
 
> You could write it to a file. If the file is opened in binary mode,
> you have to encode the Unicode string to bytes before you can write
> it. If the file is opened in text mode, Python will accept your
> Unicode string and encode it for you, which could introduce non-
> base64 characters into the file. Consider if the file was opened
> using UTF-16:
> 
> \x00A\x00U\x00E\x00R\x00F\x00g\x00=\x00=
> 
> hardly counts as base64 in any meaningful sense.

Why do you say these things like you assume I will agree with them. It
doesn't, in fact, introduce non-base64 characters because base64
characters are *characters*, not *bytes* and UTF-16 (or EBCDIC or
whatever) is a perfectly valid encoding of those *characters*, and the
recipient will, naturally, open that file in text mode in the same
encoding, and receive the same string, which it can then decode as
base64.

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