GEDCOM行限制255字符的原因及SQLite读写相关技术疑问

读取GEDCOM导入SQLite时的处理 #

• 完全可以忽略255字符的行限制，直接拼接拆分的行。GEDCOM里超过长度的内容会用CONT/CONC标签拆分，读取时只要把这些标签对应的内容合并回完整文本，就能直接存入SQLite（SQLite对文本长度没有限制）。实际编码时，遍历每行数据，遇到CONT/CONC行就和上一行的字段内容拼接，最终得到完整值再入库即可。

导出GEDCOM到未知家谱程序的要求 #

• 必须拆分长行。很多家谱软件严格遵循GEDCOM规范，遇到超过255字符的行可能直接报错、截断内容或者无法识别。为了保证兼容性，导出时要把超过255字符的内容用CONT/CONC标签拆分，确保每个拆分后的行（包含标签和内容）长度不超过255字符。

255字符行限制的成因 #

• 确实和旧系统的VARCHAR(255)兼容需求有关。GEDCOM在上世纪80年代设计时，当时多数数据库和系统的文本字段默认采用VARCHAR(255)，这个长度是当时的行业惯例（对应ASCII字符的常见最大存储长度，也受早期系统内存、存储容量限制），因此规范里定下了这个行长度上限。

替代GEDCOM的方案是否需要保留行限制 #

• 不需要保留。既然是替换旧规范，核心就是解决GEDCOM的痛点，行长度限制属于过时的设计约束。新方案直接支持任意长度的文本字段即可，毕竟现在的数据库、文件系统和软件都早已摆脱了这类老旧限制。如果需要兼容旧GEDCOM文件，只在导入导出环节处理行的拆分/拼接逻辑就行，新方案本身无需保留这个限制。

内容的提问来源于stack exchange，提问作者Luther