Bare UTF-16 / UTF-32 string encodings ignore the XTCE byteOrder attribute

[medley56]

Follow-up from review of #291. Pre-existing on main; not introduced by that PR.

StringDataEncoding._supported_encodings includes the bare UTF-16 and UTF-32 spellings alongside the explicitly-endian UTF-16BE / UTF-16LE / UTF-32BE / UTF-32LE. For the bare spellings, Python's codec decides endianness from a byte-order mark, and defaults to little-endian when there is no BOM.

XTCE carries endianness in the byteOrder attribute instead, and packet buffers do not carry a BOM. So a big-endian document that declares encoding="UTF-16" with byteOrder="mostSignificantByteFirst" decodes little-endian — the byteOrder attribute is accepted and then ignored.

from space_packet_parser.xtce import encodings

# byteOrder says big-endian; the bare UTF-16 codec decodes little-endian anyway
enc = encodings.StringDataEncoding(
    encoding="UTF-16",
    byte_order="mostSignificantByteFirst",
    fixed_raw_length=32,
)

Fix

Resolve byte_order to an explicit BE/LE codec at construction time when the declared encoding is a bare UTF-16 / UTF-32, so the attribute is honored.

This changes decoded values for any existing definition using a bare spelling, which is why it is filed separately rather than folded into #291.

Note on a related review claim

A review comment on #291 suggested that constructing a bare-codec encoding raises UnicodeDecodeError before the terminator search runs. That is not the case and was verified against the branch — b"\x00\x00".decode("UTF-16") is "\x00", a single character, which passes the constructor's single-character terminator check, and the relevant tests pass. The endianness gap above is the real residual issue.

🤖 Generated with Claude Code