根本原因是表单提交链路中字符编码不一致；需统一HTML文件保存为UTF-8（非BOM）、声明、避免用记事本编辑、正确配置enctype与后端解码逻辑。
radio 单选框本身不产生乱码，乱码只出现在它提交的 value 值里——根本原因是整个表单提交链路中字符编码不一致，不是 radio 特有问题。
检查 HTML 文件实际保存编码是否为 UTF-8
VS Code 默认用 UTF-8 保存，但 Windows 自带记事本、某些老旧 IDE（如早期 Eclipse）可能默认用 GBK 或 ANSI。一旦文件以 GBK 保存，而页面又声明了 <meta charset="UTF-8">，浏览器会按 UTF-8 解析 GBK 字节，中文 value="男" 就变成 。
- 在 VS Code 右下角查看当前编码，点击后选择「Save with Encoding」→「UTF-8」（注意不是 UTF-8 with BOM）
- 用 Sublime Text 打开，菜单栏 → File → Reopen with Encoding → UTF-8，再 Save
- 别用 Windows 记事本编辑含中文
value的 HTML，它保存时不会提示编码，极易踩坑
确认表单提交方式与 enctype 是否干扰编码解析
enctype 不决定字符集，但它改变数据打包方式，间接影响后端能否正确拿到原始字节。特别是 enctype="multipart/form-data" 会完全忽略 accept-charset，且要求后端用 multipart 解析器读取字段，否则直接丢弃或乱解。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 普通 radio 表单用默认
enctype="application/x-www-form-urlencoded"即可，无需显式写 - 如果用了
enctype="multipart/form-data"（比如同时上传文件），后端必须调用request.getPart()（Java）、req.file或multer（Node.js）来提取文本字段，不能用req.body.xxx直接读 -
accept-charset="UTF-8"只在非 multipart 表单中起作用，且必须写成带短横线的"UTF-8"，"utf8"无效
验证后端接收逻辑是否匹配前端编码
即使前端全设对了，后端若没按 UTF-8 解码请求体，照样乱码。重点看两处：
立即学习“前端免费学习笔记（深入）”；
- Servlet 中，
request.setCharacterEncoding("UTF-8")必须在request.getParameter()之前调用，且仅对application/x-www-form-urlencoded有效；对 multipart 请求无效 - Spring Boot 默认已设好，但如果加了自定义
CharacterEncodingFilter，要确认encoding和forceEncoding都设为"UTF-8" - Node.js + Express：需用
body-parser的urlencoded({ extended: true })，并确保没手动覆盖Content-Type头
最易被忽略的一点：radio 的 value 是纯字符串，不经过 HTML 实体转义。如果写 value="上海"，文件保存为 GBK，页面 meta 声明 UTF-8，那提交过去的就是 GBK 字节流，后端再用 UTF-8 解，必然错。所以第一步永远是统一文件编码，而不是堆配置。
