From: "adacosta (Alan Da Costa)" Date: 2013-04-18T09:47:17+09:00 Subject: [ruby-core:54419] [ruby-trunk - Bug #8286] Can't decode non-MIME Base64 Issue #8286 has been updated by adacosta (Alan Da Costa). My confusion on this issue might have stemmed from a client sending Base64 without padding, and decode64 not managing to decode the base64, for example: > Base64.decode64 "TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2NpbmcgZWxpdC4" => "Lorem ipsum dolor sit amet, consectetur adipiscing eli" Using python base64.b64decode('TG9yZW0gaXBzdW0gbase64Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2NpbmcgZWxpdC4') TypeError: Incorrect padding Using node.js > new Buffer("TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2NpbmcgZWxpdC4", 'base64').toString('ascii') 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.' This was an old issue for me. My problem seems to have been the padding is not necessary to decode the string. I suppose the behavior of how this is handled is not explicit. I don't expect Ruby to magically figure out the issue, but its behavior seems to be different from other languages in that it doesn't raise an error or succeed with the output. What are your thoughts on this? Are there other common language implementations that won't decode the "t." ? ---------------------------------------- Bug #8286: Can't decode non-MIME Base64 https://bugs.ruby-lang.org/issues/8286#change-38685 Author: adacosta (Alan Da Costa) Status: Rejected Priority: Normal Assignee: Category: Target version: ruby -v: 2.0.0-p0 Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN =begin In https://github.com/ruby/ruby/blob/trunk/lib/base64.rb#L42 , RFC 2045 is mentioned for encode64/decode64 support, which is the MIME RFC. I don't believe this is the correct RFC to reference, as RFC 4648 is the correct RFC for Base64. Further, RFC 4648 has an explicit section about Line Feeds in Encoded Data, http://tools.ietf.org/html/rfc4648#section-3.1 . This section states: MIME [4] is often used as a reference for base 64 encoding. However, MIME does not define "base 64" per se, but rather a "base 64 Content- Transfer-Encoding" for use within MIME. As such, MIME enforces a limit on line length of base 64-encoded data to 76 characters. MIME inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating that it is "virtually identical"; however, PEM uses a line length of 64 characters. The MIME and PEM limits are both due to limits within SMTP. Implementations MUST NOT add line feeds to base-encoded data unless the specification referring to this document explicitly directs base encoders to add line feeds after a specific number of characters. In my case, I have a separate implementation that has not added line feeds to the Base64 (non-MIME) and as a result, Base64.decode64 can not decode the non-MIME encoded data. I believe this also indicates Base64#encode64 has the wrong behavior of MIME encoding Base64. I have an example of the issue at https://github.com/adacosta/base64_compatible/blob/master/test/test_coding.rb#LC25 . =end -- http://bugs.ruby-lang.org/