Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #109888
| 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> |
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 | 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