如何跨平台存储UTF-8文本文件的元数据？

针对跨平台存储光标位置、选区这类轻量元数据的需求，以下是几种实用方案，按通用性和可靠性排序：

一、配套外部元数据文件（最推荐） #

这是兼容性最强的跨平台方案，完全不修改原UTF-8文件内容，避免破坏文件可读性或引发工具兼容问题。

命名与格式最佳实践 #

• 文件命名：
  • 关联原文件名：比如原文件为document.txt，元数据文件可命名为document.txt.myapp.meta（明确关联关系）；若想隐蔽存储，可使用点前缀.document.txt.myapp.meta（Windows/macOS/Linux均支持隐藏文件）。
  • 统一目录存储：也可将所有元数据集中放在应用专属目录，比如~/.myapp/metadata/，用原文件的绝对路径哈希值作为元数据文件名，避免重名冲突，但需额外处理文件移动、重命名后的关联更新。
• 文件格式：优先用JSON，跨平台解析工具完善，可读性强，适合存储光标位置、选区这类结构化数据；简单键值对场景也可选用INI格式。

注意事项 #

• 同步元数据生命周期：原文件被重命名、移动、删除时，需同步处理对应元数据文件。
• 添加校验机制：可在元数据中存储原文件的哈希值，确保元数据与文本文件的对应关系准确。

二、基于通用UTF-8格式的嵌入式元数据 #

如果可以接受对原文件做轻微格式扩展，可选择自带元数据支持的通用UTF-8格式，兼顾可读性和跨平台兼容性：

推荐格式 #

• Markdown YAML Front Matter：
  在文件开头用---包裹YAML格式的元数据块，绝大多数Markdown编辑器（VS Code、Typora、Obsidian等）都会识别该区域，不会将其当作正文内容显示，示例：

  ---
  cursor_pos: 156
  selection_start: 100
  selection_end: 120
  ---
  这是UTF-8文本正文内容...
  

• Org Mode 属性：适合结构化笔记场景，支持自定义属性字段，跨平台有Emacs、VS Code插件等工具支持，但受众相对较窄。

局限性 #

仅适用于可转换为对应格式的文本文件，若需严格保持纯无格式UTF-8文本，此方案不适用。

三、纯文本文件末尾添加特殊标记（慎用） #

可以在文件末尾添加独特标记包裹元数据，但兼容性风险较高：

实现方式 #

使用多数纯文本编辑器会忽略的注释类标记，比如自定义分隔符### MYAPP_META_START ###和### MYAPP_META_END ###，内部用JSON存储元数据，示例：

这是UTF-8文本正文内容...

### MYAPP_META_START ###
{"cursor_pos": 156, "selection_start": 100, "selection_end": 120}
### MYAPP_META_END ###

局限性 #

• 若用户用其他编辑器打开并删除标记块，元数据会直接丢失。
• 部分命令行文本工具（如grep、wc）会将元数据当作正文的一部分处理，导致统计结果异常。

总结 #

• 若需严格保持纯UTF-8文本格式：优先选择配套外部元数据文件，兼容性和可靠性最优。
• 可接受格式扩展：Markdown YAML Front Matter是兼顾易用性和跨平台支持的选择。
• 临时存储场景：可尝试嵌入式标记方案，但需告知用户元数据存在丢失风险。

内容的提问来源于stack exchange，提问作者Eric '3ToedSloth'