On Mon, 13 Jun 2016 11:36 pm, Random832 wrote:
> On Mon, Jun 13, 2016, at 06:35, Steven D'Aprano wrote:
>> But this is a Python forum, and Python 3 is a language that tries
>> very, very hard to keep a clean separation between bytes and text,
>
> Yes, but that doesn't mean that you're right
As
On Mon, Jun 13, 2016, at 19:12, Gregory Ewing wrote:
> They could maybe be made a bit cheaper still by arranging
> some way for a bytes object and an ascii-only str object
> to share underlying storage.
While we're at it, why not allow bytes to share storage with FSR latin-1
strings and the cached
Chris Angelico wrote:
Maybe what Python needs is an "ascii" type that's a subclass of both
str and bytes, and requires that the contents be <0x80. It is text, so
it can be combined with text strings; but it is also bytes, so when
you combine it with bytes strings, it'll behave as most people expe
Michael Torrie wrote:
On 06/12/2016 11:16 PM, Steven D'Aprano wrote:
Squirt it down a wire as bytes? Almost certainly.
Sometimes yes. But not always.
And even when the ultimate destination is a wire, a Python
programmer is more likely to be accessing the wire through
some high-level interf
On Tue, Jun 14, 2016 at 1:15 AM, Michael Torrie wrote:
>> Looking at this from the high-level perspective of Python, that makes it
>> conceptually bytes not text.
>
> I don't see how this is always the case. From a high-level python
> perspective it's definitely text. That's the whole point of b
On 06/12/2016 11:16 PM, Steven D'Aprano wrote:
> "Safe to transmit in text protocols" surely should mean "any Unicode code
> point", since all of Unicode is text. What's so special about the base64
> ones?
>
> Well, that depends on your context. For somebody who cares about sending
> bits over a p
On Mon, Jun 13, 2016, at 06:35, Steven D'Aprano wrote:
> But this is a Python forum, and Python 3 is a language that tries
> very, very hard to keep a clean separation between bytes and text,
Yes, but that doesn't mean that you're right about which side of that
divide base64 output belongs on.
>
On Mon, 13 Jun 2016 03:33 pm, Random832 wrote:
> Why do you say these things like you assume I will agree with them.
Because I gave you the benefit of the doubt that you were a reasonable
person open to good-faith discussion, rather than playing John Cleese's
role in your own personal version of
Random832 :
> base64 characters are *characters*, not *bytes*
Ok, I ran into the same surprise just two days ago. But is this a big
deal?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
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 en
On Mon, 13 Jun 2016 01:20 pm, Random832 wrote:
> 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 spec
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.
On Mon, 13 Jun 2016 04:56 am, Marcin Rak wrote:
> Hi to everyone.
>
> Let's say I have some binary data, be it whatever, in the 'data' variable.
> After calling the following line
>
> b64_encoded_data = base64.b64encode(data)
>
> my b64_encoded_data variables holds, would you believe it, a str
Marcin Rak :
> b64_encoded_data = base64.b64encode(data)
>
> my b64_encoded_data variables holds, would you believe it, a string as
> bytes!.
It doesn't much matter one way or another. The logic is that whenever
you encode objects, you typically want the output as bytes. However,
it's trivial to
En Fri, 31 Jul 2009 18:58:43 -0300, bfrederi
escribió:
So what if I used a different encoding that isn't ASCII? Like UTF-8?
Would that give me lengths that are multiples of 4 based on how the
characters are represented? Or would I still need to pad with '='?
It doesn't matter, a base64-enco
bfrederi wrote:
So what if I used a different encoding that isn't ASCII? Like UTF-8?
Would that give me lengths that are multiples of 4 based on how the
characters are represented? Or would I still need to pad with '='?
I think that when it says Base-64 it's talking about the byte values
used f
So what if I used a different encoding that isn't ASCII? Like UTF-8?
Would that give me lengths that are multiples of 4 based on how the
characters are represented? Or would I still need to pad with '='?
--
http://mail.python.org/mailman/listinfo/python-list
Max Erickson wrote:
MRAB wrote:
Brandon Fredericks wrote:
I did a search within this group, but couldn't find any
information on this.
I am sending base64 encoded data as the content over http using
urllib2 urlopen. When I receive the data and attempt to decode
it, I get an "Incorrect Paddin
MRAB wrote:
> Brandon Fredericks wrote:
>> I did a search within this group, but couldn't find any
>> information on this.
>>
>> I am sending base64 encoded data as the content over http using
>> urllib2 urlopen. When I receive the data and attempt to decode
>> it, I get an "Incorrect Padding" e
Brandon Fredericks wrote:
I did a search within this group, but couldn't find any information on
this.
I am sending base64 encoded data as the content over http using
urllib2 urlopen. When I receive the data and attempt to decode it, I
get an "Incorrect Padding" error. Is there a simple way to f
Brandon Fredericks wrote:
> I did a search within this group, but couldn't find any information on
> this.
>
> I am sending base64 encoded data as the content over http using
> urllib2 urlopen. When I receive the data and attempt to decode it, I
> get an "Incorrect Padding" error. Is there a simp
On Mar 28, 1:56 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Fri, 28 Mar 2008 13:22:06 -0300, Clodoaldo <[EMAIL PROTECTED]>
> escribió:
>
>
>
> > On Mar 28, 12:09 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
> >> En Fri, 28 Mar 2008 10:54:49 -0300, Clodoaldo
> >> <[EMAIL PROTECTED]
En Fri, 28 Mar 2008 13:22:06 -0300, Clodoaldo <[EMAIL PROTECTED]>
escribió:
> On Mar 28, 12:09 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote:
>> En Fri, 28 Mar 2008 10:54:49 -0300, Clodoaldo
>> <[EMAIL PROTECTED]> escribió:
>>
>> > What i need to know is where can an equal char appear in a
On Mar 28, 12:09 pm, "Gabriel Genellina" <[EMAIL PROTECTED]>
wrote:
> En Fri, 28 Mar 2008 10:54:49 -0300, Clodoaldo <[EMAIL PROTECTED]>
> escribió:
>
>
>
> > I'm using a md5 hash encoded with base64.urlsafe_b64encode as a
> > parameter of a URL used to confirm a registration in a site. It has
> > b
En Fri, 28 Mar 2008 10:54:49 -0300, Clodoaldo <[EMAIL PROTECTED]>
escribió:
> I'm using a md5 hash encoded with base64.urlsafe_b64encode as a
> parameter of a URL used to confirm a registration in a site. It has
> been working great.
>
> The url is like this:
>
> http://example.com/ce?i=878&h=kT
EuGeNe Van den Bulke <[EMAIL PROTECTED]> wrote:
> Duncan Booth wrote:
>> However, the decoded text looks as though it is utf16 encoded so it
>> should be written as binary. i.e. the output mode should be "wb".
>
> Thanks for the "wb" tip that works (see bellow). I guess it is
> experience based
Duncan Booth wrote:
> However, the decoded text looks as though it is utf16 encoded so it should be
> written as binary. i.e.
> the output mode should be "wb".
Thanks for the "wb" tip that works (see bellow). I guess it is
experience based but how could you tell that it was utf16 encoded?
> S
EuGeNe Van den Bulke <[EMAIL PROTECTED]> wrote:
> >>> import base64
> >>> base64.decode(file("hebrew.b64","r"),file("hebrew.lang","w"))
>
> It runs but the result is not correct: some of the lines in hebrew.lang
> are correct but not all of them (hebrew.expected.lang is the correct
> file). I g
I don't know whether it is right yet but it dues what I wanted it to
do now so thank you all,
Oh and sorry for my bad grammar.
One last thing though is that I would like to be able to split the
string up into lines of 89 carictors, I have lookd through the split
methods and all I can find is spli
John Machin wrote:
> > base64.encodestring(data) does all that in one step, of course.
>
> and it's tagged as part of the "legacy interface", and gives no control
> over the chuck size, of course :-)
if you read the documentation, it's clear that legacy means "base64 only",
not "deprecated". it
On 13/04/2006 7:22 AM, Fredrik Lundh wrote:
> John Machin wrote:
>
>> *After* encoding it, you can break up the base64 string into
>> bite-size chunks, append a newline (that's "\n", NOT "/n") to each
>> chunk /.../
>
> base64.encodestring(data) does all that in one step, of course.
>
and it's
John Machin wrote:
> *After* encoding it, you can break up the base64 string into
> bite-size chunks, append a newline (that's "\n", NOT "/n") to each
> chunk /.../
base64.encodestring(data) does all that in one step, of course.
--
http://mail.python.org/mailman/listinfo/python-list
On 13/04/2006 4:07 AM, Jay wrote:
> I have bean trying to get my head around reading .GIF files from base64
> strings,
FROM base64? Sounds a tad implausible.
> Basically I need to specify a filename and convert it to base64 then I
> can copy/past the string to wear I want it.
TO base64? That's b
Damir b wrote:
>Hi *!
>
>I found a strange bug in base64.encode and decode, when I try to encode
>- decode a file 1728512 bytes lenth.
>Is somebody meet with this? I don't attach the file because it big, but
>can send to private.
>
>Which solution for transfer file (binary data) via string-only
Damir Hakimov wrote:
> I found a strange bug in base64.encode and decode, when I try to encode
> - decode a file 1728512 bytes lenth.
> Is somebody meet with this? I don't attach the file because it big, but
> can send to private.
I agree the file is too big, but can you show a small
Python prog
It seems unlikely that there is a bug in Python's base64 encode/decode
functions, but it is possible.
For me, a long string of the same length you mention survives an encode/decode
pair (a round-trip):
Python 2.3.3 (#1, May 7 2004, 10:31:40)
[GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] o
Damir Hakimov wrote:
> I found a strange bug in base64.encode and decode, when I try to encode
> - decode a file 1728512 bytes lenth.
does this work on your machine?
>>> import base64
>>> x = base64.encodestring(1728512 * "*")
>>> len(base64.decodestring(x))
1728512
does it work also if you cha
Christopher J. Bottaro wrote:
>>> Python's base64 module encodes and decodes differently than PHP's.
>>
>> really?
>
> Yeah, weird, huh? Actually the problem is that Python puts newlines at
> every 76th char. How do I stop Python from doing that? I just want
> everyone on one line.
did you rea
Christopher J. Bottaro wrote:
>
>
> Fredrik Lundh wrote:
>
>> Christopher J. Bottaro wrote:
>>> Python's base64 module encodes and decodes differently than PHP's.
>>
>> really?
>
> Yeah, weird, huh? Actually the problem is that Python puts newlines at
> every 76th char. How do I stop Python
Fredrik Lundh wrote:
> Christopher J. Bottaro wrote:
>> Python's base64 module encodes and decodes differently than PHP's.
>
> really?
Yeah, weird, huh? Actually the problem is that Python puts newlines at
every 76th char. How do I stop Python from doing that? I just want
everyone on one li
Christopher J. Bottaro wrote:
> Python's base64 module encodes and decodes differently than PHP's.
really?
> Python's docs says that it ahere's to RFC1521 (sept 1993), while PHP's adheres
> to RFC2045 (nov 1996). Is there any Python module that uses the new standard?
> Why is Python using the ol
Christopher J. Bottaro wrote:
> Python's base64 module encodes and decodes differently than PHP's.
> Python's docs says that it ahere's to RFC1521 (sept 1993), while PHP's
> adheres to
> RFC2045 (nov 1996). Is there any Python module that uses the new
> standard? Why is Python using the old stan
42 matches
Mail list logo
