Find new encoding schemes to add

[dhondta]

Addition of new encoding schemes to the library.

[dhondta]

Here are new codec ideas that (as of the published “List of codecs” for CodExt / dhondta/python-codext) don’t appear to be covered yet, grouped by theme—no code, just candidates worth adding. CodExt already covers lots of bases (BaseXX variants, classical ciphers like affine/atbash/bacon, morse, braille, dna-1..8, whitespace, resistor, url/html/markdown, etc.). (pypi.org)

1) Modern “human-friendly” base encodings (common in crypto / IDs)

• Bech32 / Bech32m (Bitcoin address-like encoding; strong error detection; popular outside BTC now)
• SS58 (Substrate/Polkadot address encoding; base58check-like but distinct)
• Crockford Base32 with check symbol (beyond just “alphabet”: include optional checksum convention)
• Base32hex (RFC4648) + paddingless strict variants (if not already fully split into strict/lenient modes)
• Z85 (ZeroMQ Base85) vs. generic base85/ascii85 distinctions (Z85 has fixed alphabet & length rules)

Why: widely used, often encountered in CTFs / logs / blockchains; good “codec” fit.

2) Checksummed / framed encodings (base + checksum conventions)

• Base58Check (Bitcoin style) as a first-class codec (if only base58 alphabets exist today)
• Base32Check / Base64Check (generic “payload + checksum” wrapper; useful for copy/paste robustness)
• Luhn mod N (not just decimal) wrapper codec for arbitrary alphabets (IDs)

Why: you already have many bases; adding checksummed variants adds practical value.

3) Integer/ID-centric encodings

• Hashids (popular reversible obfuscation for numeric IDs; “codec” is encode int list ↔ string)
• Sqids (Hashids successor; similar use-case, increasingly adopted)
• Base-N for integers with sign/varint framing (distinct from “text to baseN”)

Why: complements text encodings; common in web apps and tooling.

4) Bit/byte-to-text “classic” formats often seen in tooling

• Intel HEX (record-based ASCII format; decode ↔ binary)
• Motorola S-record (SREC) (same category)
• ASCII armoring families beyond the usual:
  • OpenPGP ASCII armor (header/footer + base64 + CRC24)
  • PEM (strict variants) as a codec flavor (framing rules matter)

Why: these appear frequently in firmware / embedded / security contexts.

5) Escape/quoting codecs (very practical for reversing and pipelines)

• C string escapes (\n, \xNN, \uNNNN, \UNNNNNNNN) strict + permissive modes
• Python escapes / unicode_escape-like but controlled and reversible
• JSON string escaping (focused codec, not full JSON)
• Percent-encoding variants (URL has it, but also:
  • application/x-www-form-urlencoded (+ for space)
  • strict RFC3986 vs. relaxed modes)

Why: often needed in decoding multi-layer payloads; fits your “guess mode” concept.

6) Radix / base families you likely don’t want to fully implement, but can target popular ones

• Ascii armor / yEnc (Usenet/email attachment encoding; niche but recognizable)
• BinHex 4.0 (classic Mac encoding; niche)
• UUencode / XXencode (common-ish; if not already present)

Why: complements base encodings with historically common transports.

7) Language / typography novelty encodings (CTF-friendly, “fun” codecs)

• Leetspeak (bi-directional mapping with ambiguity options)
• NATO phonetic alphabet (text ↔ “Alpha Bravo …”, with configurable separators)
• Tap code / Polybius-square variants (if you don’t already have them; distinct from simple substitution)
• Semaphore flags / Wigwag (symbolic alphabets)
• Pigpen cipher (symbol mapping)

Why: in the same spirit as braille/morse/barbie; fun + CTF utility.

8) Braille adjacent / accessibility symbol systems

• Morse variants (American Morse vs ITU; also “prosigns” handling)
• Braille Grade-2 contractions (much harder; but even partial support could be valuable)
• Tactile sign systems (Moon type) — niche but unique

Why: you already have braille/morse; these extend those areas meaningfully.

9) Compression-as-codec wrappers (careful scope)

If the library’s “codec” concept allows binary transforms:

• zlib / gzip / bz2 / lzma wrappers producing base64/base85 by default (“compress+armor” convenience)
• brotli wrapper

Why: common “encoding layers” encountered in the wild; great for chaining.

10) Error-correcting / robust encodings (storage/transfer oriented)

• Base64 with Reed–Solomon parity blocks (container-like)
• Fountain codes (probably too big, but a simplified “robust chunked text” codec is attractive)

Why: unique differentiator, though more complex.

---

Quick prioritization (highest ROI first)

1. Bech32/Bech32m, Base58Check, Hashids/Sqids
2. C/Python/JSON escape codecs, x-www-form-urlencoded
3. Intel HEX / SREC, OpenPGP armor
4. UUencode/yEnc, then novelty ciphers (tap/pigpen/semaphore)

If you want, I can refine this into a “gap list” against the repo’s actual current codec registry (not just the published PyPI docs), but that requires me to inspect the repository files directly (e.g., codec registration tables) and enumerate what’s truly present today.