MMD骨骼命名Excel中常见大小写不一致导致模型导入失败？

Question

在MMD模型制作中，常通过Excel批量编辑骨骼命名（如用于PMX格式导出或插件数据映射），但Excel默认不区分大小写且自动标准化格式（如将“UpperBody”转为“upperbody”或首字母大写），导致骨骼名与VMD动作文件、物理刚体定义或MMD插件预设严格匹配的原始大小写（如“IK_Wrist_L”“Eye_L”）不一致。导入时，MMD软件（如MMDPlayer、Blender MMD Tools）因大小写敏感校验失败，引发骨骼未绑定、IK失效、表情失灵或直接报错中断加载。此问题隐蔽性强——Excel界面显示正常，但导出CSV/TSV后实际字符已变更；尤其跨平台（Windows/macOS）或启用“自动更正”“智能大小写”时更易触发。建议：禁用Excel自动格式化、使用纯文本编辑器校验编码与大小写、在Excel中为骨骼列设置“文本”单元格格式并前置单引号（'UpperBody），或改用VS Code+CSV插件进行命名管理。

Answer 1

```html

一、现象层：Excel界面“所见即所得”的错觉

在MMD骨骼命名批量处理中，用户于Excel中输入 "IK_Wrist_L"，单元格显示正常；但导出为CSV后用十六进制编辑器（如HxD或VS Code Hex Editor）查看，发现实际存储为 "ik_wrist_l" 或 "Ik_Wrist_L"。这是因Excel默认启用「自动更正」→「句首大写」+「智能大小写」策略，且对下划线命名（如 Eye_L）无语义识别能力，强制“标准化”为非标准形式。

二、机制层：Excel底层字符串处理与编码陷阱

• 单元格格式未生效场景：即使设置列格式为“文本”，若在格式设置前已输入内容，Excel仍按“常规”解析并缓存原始转换逻辑；
• 跨平台差异：macOS版Excel默认启用「使用智能段落样式」，会将所有含下划线的标识符转为小写；Windows版则依赖Office语言包配置；
• CSV导出隐式编码转换：Excel导出CSV时强制使用系统默认ANSI编码（如Windows-1252），而MMD工具链（如pymmd、mmd_tools）普遍要求UTF-8 BOM或无BOM UTF-8，导致字节级大小写字符被错误映射。

三、验证层：多维度校验流程（推荐工作流）

graph TD
  A[Excel输入 'UpperBody'] --> B{设置单元格格式=文本？}
  B -->|否| C[前置单引号 'UpperBody]
  B -->|是| D[复制至VS Code]
  C --> D
  D --> E[启用CSV Preview插件]
  E --> F[对比Hex View：0x55 0x70 0x70 0x65 0x72 0x42 0x6F 0x64 0x79]
  F --> G[导出前执行Python脚本校验]

四、解决方案层：分级防御体系

层级	方案	适用场景	风险控制点
预防	Excel选项→校对→自动更正选项→取消勾选「句首字母大写」「单词首字母大写」	团队协作初稿阶段	需同步配置模板文件（.xltx）并分发
阻断	VS Code + CSV Edit插件 + 自定义语法高亮规则："IK_[A-Z]+_[LR]"	中大型模型（>200骨骼）命名治理	支持正则匹配+大小写敏感搜索（Ctrl+H → ☑ Match Case）
兜底	Python校验脚本（运行于导出后）： import csv with open('bones.csv', encoding='utf-8') as f:   for i, row in enumerate(csv.reader(f)):     if row[0] != row[0].strip():       print(f'行{i}: 首尾空格异常')     if row[0].lower() in ['upperbody','eye_l']:       print(f'行{i}: 检测到非法小写')	CI/CD流水线集成	可嵌入Blender MMD Tools导出前钩子（hook_pre_export_pmx）

五、工程层：建立MMD命名规范治理体系

建议在项目根目录部署 .mmd-naming-spec.json，定义：

• "case_sensitive": true
• "reserved_prefixes": ["IK_", "FK_", "PHYSICS_", "EYELID_"]
• "regex_validation": "^([A-Z][a-z0-9]*_)*[A-Z][a-z0-9]*[LR]?$"

配合pre-commit hook调用 mmd-namer validate bones.csv CLI工具（基于click开发），实现提交即校验。

六、认知层：超越Excel——为什么专业DCC管线弃用电子表格？

从Maya/Blender的骨架导出器源码可见，其PMX序列化模块直接读取Bone.name属性（Python str对象），而该属性在绑定时参与哈希计算：hash(bone.name)。Excel篡改大小写本质是破坏了字符串的identity hash稳定性，导致同一骨骼在VMD动作帧中查表失败（bone_map.get('Eye_L') → None）。这已不是UI显示问题，而是破坏了整个引用完整性契约。

```