CLI shell uses GBK encoding by default, causing Chinese characters garbled; want to set default encoding to UTF-8 #30055

Activity

1. github-actions

   assigned

   Hona

   on May 31, 2026
2. github-actions commented on May 31, 2026

   

   github-actionsBot

   on May 31, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Windows: bash tool cannot correctly handle cmd.exe GBK output #26882: Windows bash tool cannot correctly handle cmd.exe GBK output (same GBK encoding issue on Windows)
   • fix: CJK characters garbled in TUI on Windows with non-UTF8 locale #14768: CJK characters garbled in TUI on Windows with non-UTF8 locale (same garbling symptoms)
   • fix: PowerShell output encoding for non-ASCII characters on Windows #23636: PowerShell output encoding for non-ASCII characters on Windows (related encoding issue on Windows)
   • Fix CJK character display issues in Windows terminals #10491: Fix CJK character display issues in Windows terminals (related CJK display issue)

   If your issue is not covered by any of the above, please let us know what makes your case different.
3. Astro-Han commented on Jun 3, 2026

   

   Astro-Han

   on Jun 3, 2026

   Last edited by Astro-Han

   More actions

   The root cause here is the Windows active code page (ACP), not the shell choice. On zh-CN Windows the ACP is 936 (GBK), and a spawned child process inherits it for both stdin and stdout. So when a tool writes UTF-8 bytes, the parent reads them back through a GBK decoder and you get mojibake. Switching cmd to PowerShell or back won't fix it on its own, because both inherit the same ACP.

   Two layers usually have to be handled together:

   1. Force the child's console code page to UTF-8 before the command runs.

      • cmd: prefix with chcp 65001 >nul & ...
      • Windows PowerShell 5.1: $OutputEncoding = [Console]::OutputEncoding = [Text.UTF8Encoding]::new($false); ... (PowerShell 7+ already defaults to UTF-8, so detect the host before injecting this)

   2. Stop assuming the byte encoding on the Node side. Read stdout as a Buffer rather than a string, detect the real code page (e.g. via chcp), and decode with iconv-lite. If you hardcode utf8 you just move the mojibake onto the GBK-only tools; if you hardcode gbk you break everything else.

   A couple of env vars help the common subtools emit UTF-8 in the first place: PYTHONUTF8=1 and PYTHONIOENCODING=utf-8 for Python. Leaving LANG/LC_ALL unset is usually safer than forcing a POSIX locale that the native Windows tools don't honor.

   The reason this only bites on Windows is that macOS and Linux default to a UTF-8 ACP, so the inherited-code-page path is invisible there.
   For reference, PawWork (a desktop fork targeting Windows/macOS) ended up combining chcp 65001 injection with Buffer-based reading on the Node side — the dual approach is the only thing that held up across cmd, PowerShell 5.1, and 7.
4. Thalynor

   closed this as completedon Jun 7, 2026