Some strings fail to translate due to missing leading characters in .po files

[lucasmachine]

Problem Description:
I am using lcftrans to translate the Japanese RPG Maker game "水たまりの彼女" (Water Puddle Girl) (Link: https://w.atwiki.jp/vip_rpg/pages/659.html). I found that several strings remain in Japanese even after being translated in the .po file.
After investigating the issue by converting the map data to XML using lcf2xml, I noticed that the msgid generated in the .po file is missing a specific leading character compared to the original string in the game data. Because of this mismatch, EasyRPG Player cannot find the translation and falls back to the original Japanese text.

Example:

Steps to Reproduce:
1.Use lcftrans -c to generate .po files for "水たまりの彼女".
2.Translate the affected strings in the .po file.
3.Run the game with EasyRPG Player.
4.Observe that the translation does not take effect.
5.Compare the .po's msgid with the actual string extracted via lcf2xml.

Technical Analysis
The root cause is an encoding/extraction discrepancy involving the 0x7F control character (often used in RPG Maker for specific formatting or legacy reasons).
1.Extraction phase: lcftrans strips the 0x7F prefix when generating the .po file, resulting in a msgid like "Text Sample".
2.Runtime phase: The game data still contains "\x7FText Sample".
3.Lookup Failure: EasyRPG Player performs an exact string match. Since "\x7FText Sample" $\neq$ "Text Sample", the translation is never applied.

Environment:
lcftrans version: 1.1
Game Name: 水たまりの彼女 (Mizutamari no Kanojo)
Encoding: Japanese (Shift-JIS)

Expected Behavior:
Modify lcftrans to preserve the 0x7F character (and other similar control codes) within the msgid. This ensures the translation key is an exact binary representation of the original string.
Alternative: If stripping these characters is intentional for readability, the translation engine in EasyRPG Player should be updated to ignore/strip these specific leading control characters during the lookup process to ensure a successful match with the "cleaned" msgid.
Or perhaps there are even better solutions?

Additional Context:
It seems like a potential bug in how lcftrans handles specific Japanese symbols or control characters during the extraction process.