[Ankushkushwaha1]

Description

Fixes #15635

The Adler-32 algorithm is defined over a byte stream. The previous implementation iterated over Unicode code points via ord(char), which produced correct results only for pure-ASCII input. For any non-ASCII character (e.g. '€', '日本語') the checksum silently diverged from every standard Adler-32 implementation, including Python's own zlib.adler32.

Root Cause

# Before (wrong for non-ASCII)
for plain_chr in plain_text:
    a = (a + ord(plain_chr)) % MOD_ADLER  # uses Unicode code point ❌

Fix

Encode the input string to UTF-8 first, then iterate over the resulting bytes — exactly what hashes/crc32.py already does:

# After (correct for all inputs)
for byte in plain_text.encode("utf-8"):
    a = (a + byte) % MOD_ADLER  # uses actual bytes ✅

Verification

>>> from hashes.adler32 import adler32
>>> import zlib
>>> adler32('Algorithms') == zlib.adler32('Algorithms'.encode())
True
>>> adler32('€100') == zlib.adler32('€100'.encode())
True
>>> adler32('日本語テスト') == zlib.adler32('日本語テスト'.encode())
True

Checklist

• All existing doctests still pass ('Algorithms' → 363791387, 'go adler em all' → 708642122)
• Two new doctests added for non-ASCII inputs, verified against zlib.adler32
• No new dependencies introduced