Skip to content

fix: Windows 中文编码修复 - MCP server UTF-8 支持#1291

Closed
hzx945627450-eng wants to merge 2 commits into
MemPalace:developfrom
hzx945627450-eng:develop
Closed

fix: Windows 中文编码修复 - MCP server UTF-8 支持#1291
hzx945627450-eng wants to merge 2 commits into
MemPalace:developfrom
hzx945627450-eng:develop

Conversation

@hzx945627450-eng

Copy link
Copy Markdown

修复 Windows 环境下 MCP server 中文乱码问题。

问题根因:

  • Windows 默认 stdin/stdout 使用 GBK/CP936 编码
  • MCP 协议要求 UTF-8 传输
  • 导致中文字符在 JSON-RPC 通信中损坏

修复方案(mempalace/mcp_server.py):

  1. 第 1889 行:工具返回结果添加 ensure_ascii=False
  2. 第 1949 行:JSON-RPC 响应添加 ensure_ascii=False
  3. main() 函数:Windows 平台强制包装 stdin/stdout 为 UTF-8

跨平台兼容:

  • 使用 sys.platform == 'win32' 检测
  • Linux/macOS 默认 UTF-8,无需包装
  • ensure_ascii=False 对所有平台都有益

测试结果:

  • ✅ Windows: 中文读写完全正常
  • ✅ Linux/macOS: 不受影响,保持原有 UTF-8 行为

What does this PR do?

How to test

Checklist

  • Tests pass (python -m pytest tests/ -v)
  • No hardcoded paths
  • Linter passes (ruff check .)

修复 Windows 环境下 MCP server 中文乱码问题。

问题根因:
- Windows 默认 stdin/stdout 使用 GBK/CP936 编码
- MCP 协议要求 UTF-8 传输
- 导致中文字符在 JSON-RPC 通信中损坏

修复方案(mempalace/mcp_server.py):
1. 第 1889 行:工具返回结果添加 ensure_ascii=False
2. 第 1949 行:JSON-RPC 响应添加 ensure_ascii=False
3. main() 函数:Windows 平台强制包装 stdin/stdout 为 UTF-8

跨平台兼容:
- 使用 sys.platform == 'win32' 检测
- Linux/macOS 默认 UTF-8,无需包装
- ensure_ascii=False 对所有平台都有益

测试结果:
- ✅ Windows: 中文读写完全正常
- ✅ Linux/macOS: 不受影响,保持原有 UTF-8 行为

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@igorls

igorls commented May 1, 2026

Copy link
Copy Markdown
Member

Thanks for this fix.

The stdio reconfigure portion of this PR overlaps with #1259, which addresses the same Windows encoding problem using sys.stdin.reconfigure(encoding="utf-8"). Both approaches work. The reconfigure() idiom is what the other Windows stdio PRs in flight (#1280, #1282) are using, so we are likely to take #1259 to keep the codebase consistent.

That said, the ensure_ascii=False additions on the two json.dumps calls in this PR are independently valuable and not present in #1259. Without them, non-ASCII content in tool results is emitted as \uXXXX escapes, which is verbose and can trip downstream MCP clients that do not unescape correctly.

Would you be willing to open a separate PR with just the ensure_ascii=False change, plus a small test that round-trips a Chinese string through handle_request so the fix has a regression guard? That change can land on its own merits and stay decoupled from the stdio-reconfigure work.

- Add ChromaDB connection warmup
- Add HNSW index health check
- Add Knowledge Graph loading
- Fix datetime import in _log()

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
@hzx945627450-eng

Copy link
Copy Markdown
Author

Thanks for this fix.

The stdio reconfigure portion of this PR overlaps with #1259, which addresses the same Windows encoding problem using sys.stdin.reconfigure(encoding="utf-8"). Both approaches work. The reconfigure() idiom is what the other Windows stdio PRs in flight (#1280, #1282) are using, so we are likely to take #1259 to keep the codebase consistent.

That said, the ensure_ascii=False additions on the two json.dumps calls in this PR are independently valuable and not present in #1259. Without them, non-ASCII content in tool results is emitted as \uXXXX escapes, which is verbose and can trip downstream MCP clients that do not unescape correctly.

Would you be willing to open a separate PR with just the ensure_ascii=False change, plus a small test that round-trips a Chinese string through handle_request so the fix has a regression guard? That change can land on its own merits and stay decoupled from the stdio-reconfigure work.

Thanks for the clear and helpful feedback!

I've split the changes as you suggested into one separate PR:

I'll close this original PR in favor of the split one, to keep things clean and decoupled as you recommended.

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.

2 participants