Base64 decoder (see binascii.a2b_base64(), base64.b64decode(), etc)
no longer ignores excess data after the first padded quad in non-strict
(default) mode. Instead, in conformance with RFC 4648, it ignores the
pad character, "=", if it is present before the end of the encoded data.
Add base32 encoder and decoder functions implemented in
C to the binascii module and use them to greatly improve the
performance and reduce the memory usage of the existing
base32 codec functions in the base64 module.
* Add the alphabet parameter in functions b2a_base64(), a2b_base64(),
b2a_base85(), and a2b_base85().
* And a number of "*_ALPHABET" constants.
* Remove b2a_z85() and a2b_z85().
Add Ascii85, Base85, and Z85 encoders and decoders to binascii,
replacing the existing pure Python implementations in base64.
This makes the codecs two orders of magnitude faster and consume
two orders of magnitude less memory.
Note that attempting to decode Ascii85 or Base85 data of length 1 mod 5
(after accounting for Ascii85 quirks) now produces an error, as no
encoder would emit such data. This should be the only significant
externally visible difference compared to the old implementation.
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Fix an edge case in `binascii.a2b_base64` strict mode, where
excessive padding was not detected when no padding is necessary.
Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
When compiled with `USE_ZLIB_CRC32` defined (`configure` sets this on POSIX systems), `binascii.crc32(...)` failed to compute the correct value when the input data was >= 4GiB. Because the zlib crc32 API is limited to a 32-bit length.
This lines it up with the `zlib.crc32(...)` implementation that doesn't have that flaw.
**Performance:** This also adopts the same GIL releasing for larger inputs logic that `zlib.crc32` has, and causes the Windows build to always use zlib's crc32 instead of our slow C code as zlib is a required build dependency on Windows.
The binhex module, deprecated in Python 3.9, is now removed. The
following binascii functions, deprecated in Python 3.9, are now also
removed:
* a2b_hqx(), b2a_hqx();
* rlecode_hqx(), rledecode_hqx().
The binascii.crc_hqx() function remains available.
* Renamed assertLeadingPadding function to match logic
* Added a separate error message for discontinuous padding
* Updated the tests for discontinuous padding
binascii.a2b_base64 gains a strict_mode= parameter. When enabled it will raise an
error on input that deviates from the base64 spec in any way. The default remains
False for backward compatibility.
Code reviews and minor tweaks by: Gregory P. Smith <greg@krypto.org> [Google]
Deprecate binhex4 and hexbin4 standards. Deprecate the binhex module
and the following binascii functions:
* b2a_hqx(), a2b_hqx()
* rlecode_hqx(), rledecode_hqx()
* crc_hqx()
* bpo-22385: Support output separators in hex methods.
Also in binascii.hexlify aka b2a_hex.
The underlying implementation behind all hex generation in CPython uses the
same pystrhex.c implementation. This adds support to bytes, bytearray,
and memoryview objects.
The binascii module functions exist rather than being slated for deprecation
because they return bytes rather than requiring an intermediate step through a
str object.
This change was inspired by MicroPython which supports sep in its binascii
implementation (and does not yet support the .hex methods).
https://bugs.python.org/issue22385
Improvements:
1. Include the number of valid data characters in the error message.
2. Mention "number of data characters" rather than "length".
https://bugs.python.org/issue34736
I have compared output between pre- and post-patch runs of these tests
to make sure there's nothing missing and nothing broken, on both
Windows and Linux. The only differences I found were actually tests
that were previously *not* run.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r78678 | benjamin.peterson | 2010-03-04 21:07:59 -0600 (Thu, 04 Mar 2010) | 1 line
set svn:eol-style
........
r78680 | benjamin.peterson | 2010-03-04 21:15:07 -0600 (Thu, 04 Mar 2010) | 1 line
set svn:eol-style on Lib files
........
r78682 | benjamin.peterson | 2010-03-04 21:20:06 -0600 (Thu, 04 Mar 2010) | 1 line
remove the svn:executable property from files that don't have shebang lines
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77528 | antoine.pitrou | 2010-01-16 18:45:56 +0100 (sam., 16 janv. 2010) | 4 lines
Followup to #7703: a2b_hqx() didn't follow the new buffer API (neither in trunk
nor in py3k). Patch by Florent Xicluna as well as additional tests.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77506 | antoine.pitrou | 2010-01-15 01:18:00 +0100 (ven., 15 janv. 2010) | 4 lines
Issue #7701: Fix crash in binascii.b2a_uu() in debug mode when given a
1-byte argument. Patch by Victor Stinner.
........
a backport.
Merged revisions 77497 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
........
r77497 | antoine.pitrou | 2010-01-14 17:27:09 +0100 (jeu., 14 janv. 2010) | 5 lines
Issue #7703: Add support for the new buffer API to functions of the
binascii module. Backported from py3k by Florent Xicluna, with some
additional tests.
........
No detailed change log; just check out the change log for the py3k-pep3137
branch. The most obvious changes:
- str8 renamed to bytes (PyString at the C level);
- bytes renamed to buffer (PyBytes at the C level);
- PyString and PyUnicode are no longer compatible.
I.e. we now have an immutable bytes type and a mutable bytes type.
The behavior of PyString was modified quite a bit, to make it more
bytes-like. Some changes are still on the to-do list.
Change binascii.Error to derive from ValueError
and raise binascii.Error everywhere where values are bad
(why on earth did the old code use TypeError?!?).
