Skip to content

Convert the two UTF-16LE Live_36 raw scripts to UTF-8 (#385) - #389

Open
meketreve wants to merge 1 commit into
OpenPerpetuum:developmentfrom
meketreve:issue-385-utf8-raw-scripts
Open

Convert the two UTF-16LE Live_36 raw scripts to UTF-8 (#385)#389
meketreve wants to merge 1 commit into
OpenPerpetuum:developmentfrom
meketreve:issue-385-utf8-raw-scripts

Conversation

@meketreve

Copy link
Copy Markdown
Contributor

Closes #385.

Converts the two reported files from UTF-16LE to UTF-8:

  • Patches/Live_36/Raw_SQL/17_consolidate_statistics.sql
  • Patches/Live_36/Raw_SQL/37_Market_decoupling_4.sql

Done on the instruction given on Discord on 2026-08-15 — CONTRIBUTING.md says Patches are never to be altered, so this is deliberate and asked for rather than an oversight.

Why these two broke and the others did not

apply_all.bat invokes sqlcmd without -f, so an input file with no byte-order mark is read using the ANSI codepage. UTF-16LE with a BOM is detected; UTF-16LE without one is not. These two had no BOM, which is the one combination that goes wrong.

Verification

Encoding only. Each claim below was measured, not assumed:

Check Result
Content unchanged Decoding each original from UTF-16LE and diffing against the converted file reports no difference
No BOM introduced Both files now begin with the ASCII bytes 55 53 45, not ef bb bf
Line endings untouched Both files were LF-only before and after — 0 CR bytes on each side
Nothing changes for sqlcmd Both files are pure ASCII once decoded, so the bytes sqlcmd reads are identical to before
Size 3808 → 1904 and 8220 → 4110, exactly half, which is what a pure-ASCII UTF-16 → UTF-8 conversion gives

One thing the issue did not cover

Scanning all 58 files in Live_36/Raw_SQL turned up two more UTF-16LE files, which issue #385 does not mention:

  • 16_sp_RecordResourceGathered.sql
  • 20_usp_RefreshAutoMarketOrders.sql

Both carry a BOM, so sqlcmd reads them correctly today and nothing is broken. But they are not UTF-8 either, and the remark that prompted this PR was that everything had been switched back to UTF-8 and these were missed — which would apply to these two as well. Both are pure ASCII once decoded, so converting them carries the same zero risk.

They are not in this PR, because the issue named two files and CLAUDE.md asks for minimal, focused changes. Say the word and they are a one-line addition to this branch.

Fixes the two files reported in issue OpenPerpetuum#385:

- Patches/Live_36/Raw_SQL/17_consolidate_statistics.sql
- Patches/Live_36/Raw_SQL/37_Market_decoupling_4.sql

Both were UTF-16LE with no BOM, which is the combination sqlcmd cannot
detect: apply_all.bat invokes it without -f, so a file with no BOM is
read using the ANSI codepage.

Encoding only. Verified rather than assumed:

- decoding each original from UTF-16LE and diffing against the converted
  file reports no difference, so no character changed
- no BOM was added; both files now start with the ASCII bytes 55 53 45
- line endings are untouched -- both files were LF-only before and after,
  measured as 0 CR bytes on each side
- both files are pure ASCII once decoded, so what sqlcmd reads is
  byte-identical to what it read before

File sizes halve exactly, which is what a pure-ASCII UTF-16 to UTF-8
conversion produces: 3808 to 1904 and 8220 to 4110.

CONTRIBUTING.md states that Patches are never to be altered. This change
is made on an explicit instruction from the maintainers, given on Discord
on 2026-08-15 in answer to issue OpenPerpetuum#385.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.

Two Live_36 Raw_SQL files are UTF-16LE without a BOM and fail under sqlcmd

1 participant