f



bug with unpack('m') / pack('m') ?

Having a strange ruby encoding encounter:

ruby-1.9.2-p180 :618 > s = "a8dnsjg8aiw8jq".ljust(16,'=')
 => "a8dnsjg8aiw8jq=="
ruby-1.9.2-p180 :619 > s.size
 => 16

ruby-1.9.2-p180 :620 > s.unpack('m0')
ArgumentError: invalid base64
    from (irb):631:in `unpack'

ruby-1.9.2-p180 :621 > s.unpack('m')
 => ["k\xC7g\xB28<j,<\x8E"]
ruby-1.9.2-p180 :622 > s.unpack('m').first.size
 => 10

ruby-1.9.2-p180 :623 > s.unpack('m').pack('m')
 => "a8dnsjg8aiw8jg==\n"
ruby-1.9.2-p180 :624 > s.unpack('m').pack('m') == s
 => false

Any idea why this is not symmetric!? And why is 'm0' (decode64_strict)
not working at all? The input string is padded out to a multiple of 4
characters in the base64 alphabet. Here it's 14 x 6 bits = 84 bits
which is 10 1/2 8-bit bytes, i.e. 11 bytes. But the decoded string
seems to drop the last nybble?

Am I missing something obvious or is this a bug? Workaround? cf.
http://www.ietf.org/rfc/rfc4648.txt

http://stackoverflow.com/questions/7063737/ruby-base64-encode-decode-unpackm-troubles
0
m8388 (1)
8/15/2011 10:58:01 AM
comp.lang.ruby 48885 articles. 0 followers. Post Follow

1 Replies
676 Views

Similar Articles

[PageSpeed] 10

tribalvibes <m@tribalvibes.com> wrote:
>
>Having a strange ruby encoding encounter:
>
>ruby-1.9.2-p180 :618 > s = "a8dnsjg8aiw8jq".ljust(16,'=')
>...
>ruby-1.9.2-p180 :620 > s.unpack('m0')
>ArgumentError: invalid base64
>    from (irb):631:in `unpack'
>ruby-1.9.2-p180 :623 > s.unpack('m').pack('m')
> => "a8dnsjg8aiw8jg==\n"
>ruby-1.9.2-p180 :624 > s.unpack('m').pack('m') == s
> => false
>
>Any idea why this is not symmetric!?

Sure.  Do you see that the last character of your string is different from
the last character of the "packed" string?  You have a lower case Q (cue)
where the pack call produced a lower case G (gee).

Your string is, as the library says, not valid base64.  It is not possible
to have a base64 quartet with two pad bytes where the second character is
larger than "g".
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
0
timr (1409)
8/16/2011 10:03:49 PM
Reply: