Repository navigation
fix(corekit): StringField's 'replace' decode fallback raises UnicodeError for codecs such as idna, on every Python #1706
Description
Describe the bug
StringField's decode fallback, pcapkit/corekit/fields/strings.py:209 (ret = value.decode(charset, 'replace')), sits outside any try. It assumes decoding with 'replace' cannot raise. A codec that rejects 'replace', or ignores the handler, therefore lets a UnicodeError escape unpack.
Reproduction
main at 8035434a2, CPython 3.14.8:
from pcapkit.corekit.fields.strings import StringField
StringField(length=1, encoding='idna', errors='ignore').unpack(b'a', {})
# UnicodeError: Unsupported error handling: replace (field.py:587 -> strings.py:209)This affects every Python version: idna supports only strict, so plain ASCII input raises whenever errors is not strict.
A scan of 20 encodings × 3 error modes × 264 inputs found:
| Python | escapes | cause |
|---|---|---|
| 3.8 | 1,056 | all from :209: idna, plus punycode on non-ASCII input |
| 3.14 | 660 | idna only |
punycode stopped escaping in 3.13: encodings/punycode.py no longer hard-codes a strict ASCII decode. The #1693 worker found this; I reproduced the idna case.
Expected behavior
unpack never raises a UnicodeError from pcapkit's own fallback. If even the fallback cannot decode, the field keeps the raw octets the way its other paths do, and a parse→rebuild round trip still gives the original bytes.
Activity
JarryShaw commentedon Oct 14, 2026
Blocked until #1707 merges. It edits the same function in
pcapkit/corekit/fields/strings.py, where the fallback at:209moves to:233.JarryShaw commentedon Oct 14, 2026
#1707 has merged, so this is unblocked. A worker is on it.