3.0 KiB
文本编码与地区边界
UTF-8 不限定地区
Value::Text 与 EndorStringObject 使用 Rust String，始终是有效 UTF-8。日文假名、汉字、中文和 emoji 都可以保存在同一字符串中；运行在日本地区并不要求 VM 改成另一套内部编码。Rust String。
地区、编码、字体和语言规则是不同层面：LC_CTYPE 不决定已有 Rust String 里字符的含义；字体缺失会影响显示，不会把 UTF-8 内容变成另一种文本。
不同编码的外部数据
日本的旧系统或文件可能使用 Shift_JIS／Windows CP932，也可能使用 UTF-8；不能仅根据所在地推断文件编码。Windows 的代码页表中列有日文 932，见 Microsoft 代码页说明。
| 输入或输出 | 边界处理 |
|---|---|
| 已是 Rust String／明确 UTF-8 JSON | 保持 UTF-8，可直接传入当前 VM |
| Shift_JIS／CP932 等外部字节 | 由宿主 I/O 适配器按明确编码解码成 Unicode，再交给 VM |
| 非法 UTF-8 却声明为 UTF-8 | 使用严格解码返回错误，不默默替换字符 |
| 必须与旧系统交换文本 | 宿主显式选择目标编码；遇到目标编码不能表示的字符时明确报错或由业务另行选择策略 |
| 操作系统路径 | 使用 PathBuf／OsString 保留系统表示，不先强转成 VM 文本 |
String::from_utf8 验证字节；它不会自动识别 Shift_JIS，也不会自动转换编码。某些错误编码字节可能恰好仍是合法 UTF-8，因此“能通过 UTF-8 校验”也不能代替输入协议。from_utf8 文档。
EndorReader 提供严格 UTF-8 文件／流读取和宿主 URI provider 适配，输出带来源的 SourceUnit；frontend 将其文本交给 lexer/parser。CLI parse 文件和 stdin 都经过阅读器，见 阅读器。当前仍无通用文件／网络文本加载器或 Shift_JIS 解码器；以上非 UTF-8 转换由宿主显式提供，不是已有内置转码能力。无需修改全局 locale 来处理单个文件。
其他日文文本差异
当前按 Unicode 标量值访问字符，不按人眼字形簇。预组合的“ガ”和“カ”加组合浊点可显示相似，但标量数量和序列不同；当前没有自动规范化或全角／半角转换。字符串和字典按当前内容语义处理，不为了所在地悄悄改写数据。前端当前采用的名称字符分类与源码位置规则见 源码前端，名称同样不自动规范化。
宿主基础信息以 UTF-8 JSON 写入；控制键的 ASCII 命名限制属于文件信息协议，值可保存日文，详见 宿主信息。配置与 locale 见 配置，返回 运行时索引。