This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients christian.heimes, flox, isoschiz, jcea, pitrou, r.david.murray, serhiy.storchaka, sijinjoseph
Date 2013-04-17.15:28:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366212513.57.0.719294791039.issue17618@psf.upfronthosting.co.za>
In-reply-to
Content
After searching a lot of other implementations of this encoding I conclude that there are at least three different variants.

1. The original btoa/atob encoding. 4 zeros are packaged as 'z', last incomplete 4 bytes are padded by zeros, an output is wrapped into several lines and decoder ignores '\n'. There are many implementations of this algorithm in different languages.

2. Adobe version. This is an extended version of (1). The last incomplete 4 bytes produces less then 5 output characters, an output is enclosed in <~ and ~>. Decoder ignores all ascii whitespaces, not only '\n'. There are many implementations of this algorithm in different languages.

3. Git and Mercurial version. This is a very simplified version of (1) with an alternative character set. Zeros are not packed, an output is not broken into several lines and decoder doesn't ignores any whitespaces. I don't know is whether this variant used besides Git and Mercurial.

Some implementations combine (1) and (2) (optionally enclose an output in <~ and ~>, optionally wrap an output into several lines, optionally pad last 4 incomplete bytes).
History
Date User Action Args
2013-04-17 15:28:33serhiy.storchakasetrecipients: + serhiy.storchaka, jcea, pitrou, christian.heimes, r.david.murray, flox, sijinjoseph, isoschiz
2013-04-17 15:28:33serhiy.storchakasetmessageid: <1366212513.57.0.719294791039.issue17618@psf.upfronthosting.co.za>
2013-04-17 15:28:33serhiy.storchakalinkissue17618 messages
2013-04-17 15:28:33serhiy.storchakacreate