VRML 1.0 和 2.0 文件必须用专用解析器或手写状态机区分版本解析，因语法、节点、字段格式及编码差异极大，混用会导致崩溃或静默丢弃；libvrml97 是较省力的 C++ 解析库，但需注意其不处理纹理与坐标系转换。
VRML 1.0 和 2.0 文件不能用标准 C++ 库直接解析——必须借助专用解析器或手写有限状态机，且需严格区分版本，否则节点字段解析会崩溃或静默丢弃。
VRML 文件版本决定解析策略
VRML 1.0（基于 SGML 风格）和 VRML 2.0（即 ISO/IEC 14772-1:1997，实际是文本化 Scene Graph 描述）语法差异极大：#VRML V1.0 ascii 和 #VRML V2.0 utf8 不只是注释，而是整个解析器入口开关。混用会导致字段名识别失败（如 VRML 2.0 的 Transform 节点在 1.0 中不存在），甚至使 DEF/USE 引用逻辑错乱。
- 检查文件头前两行，优先匹配
#VRML V[12]\.正则，而非只读第一行 - VRML 1.0 使用
Separator、Material等节点，字段用空格分隔；VRML 2.0 使用Shape、Appearance，字段用中括号[]包裹，支持嵌套 - UTF-8 编码仅对 VRML 2.0 有效；VRML 1.0 实际为 ASCII，遇到非 ASCII 字节应报错而非跳过
用 libvrml97 解析 VRML 2.0 最省力
libvrml97 是少数仍可编译的开源 C++ VRML 2.0 解析库（GitHub 可搜到维护分支），它将文件转为内存中的节点树，每个节点对应一个 C++ 类（如 VrmlScene、VrmlTransformNode）。但注意：它不处理纹理路径加载，也不做坐标系转换。
- 编译时需定义
VRML97_NO_OPENGL宏避免链接 OpenGL 依赖 - 调用
VrmlScene::readFile(const char* path)后，用VrmlNode::getTypeName()判断节点类型，再dynamic_cast<VrmlTransformNode*>(node)提取字段 - 字段值通过
VrmlField子类访问：位置是VrmlSFFloat或VrmlSFVec3f，旋转是VrmlSFRotation；直接调getValue()前务必isDefined()检查
手写简易解析器要避开三个坑
若只需提取基础几何体（如 Box 尺寸、Coordinate 点列表），可跳过完整库，但必须规避常见崩坏点：
立即学习“C++免费学习笔记（深入）”；
- 注释不止
#开头：VRML 2.0 允许行内注释（size [1, 2, 3] # comment），需在词法分析阶段切掉#后全部内容 -
USE引用必须延迟解析：先遍历所有DEF建立名称→节点指针映射表，第二遍再替换USE，否则引用未定义就解引用 - 浮点数格式陷阱：VRML 支持
1e-3、.5、-0.0，C++std::stof()能处理，但sscanf("%f")对.5返回 0；建议统一用std::from_chars()（C++17）或std::stringstream
坐标与单位必须手动校验
VRML 默认单位是米，但文件本身不强制约束；WorldInfo 节点的 info 字段可能含 "units:m"，但这只是提示，解析器不会自动缩放。更麻烦的是 Y-up 和 Z-up 混用：VRML 规范用 Y 向上，但很多导出器（如 Blender 插件）默认输出 Z 向上，导致模型倒置。
- 读取
WorldInfo { info ["units:m"] }仅作日志，不改变数值 - 若后续要转 OpenGL，需在顶点着色器或加载时翻转 Y/Z：对每个
Coordinate的point字段，执行vec3(z, y, x)或vec3(x, z, -y)，具体取决于源工具链 - 没有
Unit节点（VRML 2.0 并无该节点），别在代码里预留解析逻辑
真正难的不是读出字段，而是搞清那个 Rotation 字段的四元数顺序——VRML 用 axis x y z, angle rad，不是 w-x-y-z，也不是 x-y-z-w；传给 glm::quat 之前必须自己转。这点文档极少提，但一错就是模型疯狂自旋。
