Skip to content

server: decode Windows OEM output to UTF-8 in built-in tools - #26597

Merged
allozaur merged 1 commit into
ggml-org:masterfrom
ServeurpersoCom:fix/windows-tools-encoding
Aug 4, 2026
Merged

server: decode Windows OEM output to UTF-8 in built-in tools#26597
allozaur merged 1 commit into
ggml-org:masterfrom
ServeurpersoCom:fix/windows-tools-encoding

Conversation

@ServeurpersoCom

Copy link
Copy Markdown
Contributor

Overview

Built-in tool output on Windows is decoded from the OEM code page instead of reaching the JSON layer as invalid bytes, which silently replaced every accented character with U+FFFD.

Additional information

Follow-up for #26518 but not only that.

Before

Before

After

Sans titre

Requirements

a child process writes in the OEM code page, which is not UTF-8 on a
western Windows install, so accented output reaches the JSON layer as
invalid bytes and gets replaced there, silently losing the characters

run() spawns without a console, so the child never inherits the console
code page and GetOEMCP is the one that applies

decode with MB_ERR_INVALID_CHARS so a wrong code page returns the text
untouched instead of emitting replacement characters, and pass text that
already decodes as UTF-8 through so a child emitting UTF-8 is never
decoded twice

the check drops an incomplete trailing sequence before validating, since
a streamed chunk can end in the middle of a multi-byte character
@ServeurpersoCom
ServeurpersoCom requested a review from a team as a code owner August 4, 2026 18:12
@github-actions github-actions Bot added the server label Aug 4, 2026
@allozaur
allozaur merged commit 4308a4f into ggml-org:master Aug 4, 2026
19 of 26 checks passed
smalinin pushed a commit to smalinin/llama.cpp that referenced this pull request Aug 4, 2026
…g#26597)

a child process writes in the OEM code page, which is not UTF-8 on a
western Windows install, so accented output reaches the JSON layer as
invalid bytes and gets replaced there, silently losing the characters

run() spawns without a console, so the child never inherits the console
code page and GetOEMCP is the one that applies

decode with MB_ERR_INVALID_CHARS so a wrong code page returns the text
untouched instead of emitting replacement characters, and pass text that
already decodes as UTF-8 through so a child emitting UTF-8 is never
decoded twice

the check drops an incomplete trailing sequence before validating, since
a streamed chunk can end in the middle of a multi-byte character
satindergrewal pushed a commit to satindergrewal/llama.cpp that referenced this pull request Aug 11, 2026
…g#26597)

a child process writes in the OEM code page, which is not UTF-8 on a
western Windows install, so accented output reaches the JSON layer as
invalid bytes and gets replaced there, silently losing the characters

run() spawns without a console, so the child never inherits the console
code page and GetOEMCP is the one that applies

decode with MB_ERR_INVALID_CHARS so a wrong code page returns the text
untouched instead of emitting replacement characters, and pass text that
already decodes as UTF-8 through so a child emitting UTF-8 is never
decoded twice

the check drops an incomplete trailing sequence before validating, since
a streamed chunk can end in the middle of a multi-byte character
satindergrewal pushed a commit to satindergrewal/llama.cpp that referenced this pull request Aug 12, 2026
…g#26597)

a child process writes in the OEM code page, which is not UTF-8 on a
western Windows install, so accented output reaches the JSON layer as
invalid bytes and gets replaced there, silently losing the characters

run() spawns without a console, so the child never inherits the console
code page and GetOEMCP is the one that applies

decode with MB_ERR_INVALID_CHARS so a wrong code page returns the text
untouched instead of emitting replacement characters, and pass text that
already decodes as UTF-8 through so a child emitting UTF-8 is never
decoded twice

the check drops an incomplete trailing sequence before validating, since
a streamed chunk can end in the middle of a multi-byte character
brittlewis12 pushed a commit to brittlewis12/llama.cpp that referenced this pull request Aug 17, 2026
…g#26597)

a child process writes in the OEM code page, which is not UTF-8 on a
western Windows install, so accented output reaches the JSON layer as
invalid bytes and gets replaced there, silently losing the characters

run() spawns without a console, so the child never inherits the console
code page and GetOEMCP is the one that applies

decode with MB_ERR_INVALID_CHARS so a wrong code page returns the text
untouched instead of emitting replacement characters, and pass text that
already decodes as UTF-8 through so a child emitting UTF-8 is never
decoded twice

the check drops an incomplete trailing sequence before validating, since
a streamed chunk can end in the middle of a multi-byte character
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants