根本原因是服务端读取XML文件时使用的字符编码与XML声明的encoding属性不一致，如声明UTF-8却用GBK或ISO-8859-1解析；Java中需显式指定编码，避免依赖默认或强制UTF-8解码，应先提取XML声明中的encoding值再动态选择Charset。

XML文件上传后中文变成问号或方块

根本原因是服务端读取文件时使用的字符编码与XML声明的编码不一致。比如XML头写的是 <?xml version="1.0" encoding="UTF-8"?>，但后端用 ISO-8859-1 或系统默认编码（如Windows上的 GBK）去解析字节流，必然乱码。

Java Servlet中读取XML文件必须显式指定编码

Servlet默认用 ISO-8859-1 解析请求体，对含中文的XML文件完全不可用。不能依赖 request.getCharacterEncoding()——它只对表单参数有效，对文件上传的原始字节流无效。

Windows TTS (WSL2)

在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。

下载

• 用 ServletInputStream 读取原始字节，再手动按 UTF-8 构造字符串
• 若用Apache Commons FileUpload，务必在 DiskFileItemFactory 后调用 setHeaderEncoding("UTF-8")，否则文件名可能乱码
• 解析XML前，确认输入源是 InputStream 而非 Reader；用 SAXParser 或 DocumentBuilder 时传入带编码的 InputSource

InputSource source = new InputSource(inputStream);
source.setEncoding("UTF-8");
documentBuilder.parse(source);

Spring Boot + MultipartFile 仍需校验XML声明编码

MultipartFile.getInputStream() 返回的是原始字节流，Spring不做自动编码转换。如果XML里声明了 encoding="GBK"，而你用 new String(bytes, StandardCharsets.UTF_8) 强转，照样乱码。

• 先读取前几百字节，用正则提取 encoding="([^"]+)" 的值
• 根据提取结果选择对应 Charset 解码（注意处理 encoding="utf-8" 和 encoding="UTF-8" 大小写）
• 避免直接用 multipartFile.getString(StandardCharsets.UTF_8) —— 它强制用UTF-8，忽略XML自身声明

Nginx或网关层可能静默转码

某些反向代理（如旧版Nginx + charset utf-8 配置）会对响应头注入 Content-Type: text/xml; charset=utf-8，但实际返回的XML字节仍是GBK编码，浏览器或客户端会按UTF-8解码，导致乱码。

• 检查响应头中的 Content-Type 是否与XML文件实际编码一致
• 用 curl -v 抓包确认原始响应体字节，再用 xxd 或十六进制编辑器比对中文部分的字节序列
• 网关层尽量不要重写 Content-Type，让后端自己控制

XML声明里的编码不是建议，是契约。服务端必须严格按它解码，而不是“统一用UTF-8”图省事——尤其当老系统导出的XML仍用GBK时。