Skip to content

fix: correct Jet Unicode compression decoding for CJK text fields - #38

Open
ilolita945 wants to merge 1 commit into
claroty:masterfrom
ilolita945:fix/jet-unicode-compression
Open

fix: correct Jet Unicode compression decoding for CJK text fields#38
ilolita945 wants to merge 1 commit into
claroty:masterfrom
ilolita945:fix/jet-unicode-compression

Conversation

@ilolita945

Copy link
Copy Markdown

Summary

Fix Jet Unicode compression decoding for CJK text fields.

Problem

When BOM (\\xff\\xfe) is present in TEXT fields, the database uses Jet Unicode compression. The format stores text as 0x00-separated runs alternating between UTF-16LE pairs and compressed ASCII (single bytes expanded to 0x00XX in UTF-16LE).

The original code called get_decoded_text() for BOM-marked fields, which tried UTF-8 then Latin-1 decoding. This produced garbled CJK text (e.g. Chinese characters displayed as garbled ASCII).

Solution

  • Added decompress_jet_text() function that correctly handles the Jet compression format
  • Modified parse_type() BOM branch to use it when leading 0x00 is present
  • Added CJK ratio heuristic for non-compressed BOM text to distinguish UTF-16LE from plain ASCII

Testing

Tested with real-world Chinese archive management MDB files containing mixed CJK and ASCII text fields.

Related

Closes #21, Closes #26

When BOM (\xff\xfe) is present in TEXT fields, the data uses Jet Unicode
compression: 0x00-separated runs alternating between UTF-16LE and compressed
ASCII (single bytes expanded to 0x00XX in UTF-16LE).

Previously get_decoded_text() was called for BOM-marked fields, which tried
UTF-8 then Latin-1 decoding. This produced garbled CJK text.

Added decompress_jet_text() to properly handle the Jet compression format,
and modified parse_type() to use it when leading 0x00 is present.

Fixes claroty#21, claroty#26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Character encoding problems in table names and field values TYPE_TEXT - Unicode Decoding

1 participant