# 文本编码与地区边界

## UTF-8 不限定地区

Value::Text 与 EndorStringObject 使用 Rust String，始终是有效 UTF-8。日文假名、汉字、中文和 emoji 都可以保存在同一字符串中；运行在日本地区并不要求 VM 改成另一套内部编码。[Rust String](https://doc.rust-lang.org/std/string/struct.String.html#utf-8)。

地区、编码、字体和语言规则是不同层面：LC_CTYPE 不决定已有 Rust String 里字符的含义；字体缺失会影响显示，不会把 UTF-8 内容变成另一种文本。

## 不同编码的外部数据

日本的旧系统或文件可能使用 Shift_JIS／Windows CP932，也可能使用 UTF-8；不能仅根据所在地推断文件编码。Windows 的代码页表中列有日文 932，见 [Microsoft 代码页说明](https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers)。

| 输入或输出 | 边界处理 |
| --- | --- |
| 已是 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 文档](https://doc.rust-lang.org/std/string/struct.String.html#method.from_utf8)。

EndorReader 提供严格 UTF-8 文件／流读取和宿主 URI provider 适配，输出带来源的 SourceUnit；frontend 将其文本交给 lexer/parser。CLI parse 文件和 stdin 都经过阅读器，见 [阅读器](reader.md)。当前仍无通用文件／网络文本加载器或 Shift_JIS 解码器；以上非 UTF-8 转换由宿主显式提供，不是已有内置转码能力。无需修改全局 locale 来处理单个文件。

## 其他日文文本差异

当前按 Unicode 标量值访问字符，不按人眼字形簇。预组合的“ガ”和“カ”加组合浊点可显示相似，但标量数量和序列不同；当前没有自动规范化或全角／半角转换。字符串和字典按当前内容语义处理，不为了所在地悄悄改写数据。前端当前采用的名称字符分类与源码位置规则见 [源码前端](frontend.md)，名称同样不自动规范化。

宿主基础信息以 UTF-8 JSON 写入；控制键的 ASCII 命名限制属于文件信息协议，值可保存日文，详见 [宿主信息](https://gitea.entroia.com/Zayden-Jung/endorphin-hestia-server/src/branch/main/docs/operations/host-information.md)。配置与 locale 见 [配置](../operations/configuration.md)，返回 [运行时索引](README.md)。