如何用唯一的方法对任意编码文本文件进行高效分行？

处理几GB的大型文本文件时，不可能将整个文件加载到内存中。必须采用分块读取的方式，但这立即带来一个技术挑战：如何在字节流中准确定位行边界？

不同编码的复杂性让这个问题变得棘手。ASCII编码中每个字符占用一个字节，相对简单。但UTF-8采用变长编码（1-4字节），UTF-16使用2字节码元（某些字符需要代理对），传统的GBK、GB2312等多字节编码又有各自的规则。如果不正确处理字符边界，就可能将多字节字符的中间部分误识别为换行符。

常规思路是先将字节流解码为Unicode字符，定位换行符，再反推字节偏移量。但这种方法需要大量内存开销和复杂的解码逻辑。

编码特点分析

深入研究各种编码标准的技术规范后，可以将主流编码按其结构特点分为几类：

1. 单字节编码类
这类编码每个字符固定占用一个字节，包括ASCII、Latin-1、Windows-1252等。换行符0x0A在字节流中具有唯一性，直接扫描即可。

2. UTF-8变长编码类
UTF-8的关键设计约束是：所有多字节序列的后续字节都在0x80-0xBF范围内，首字节大于0xC0。这确保了ASCII字符（0x00-0x7F）在字节流中的唯一性。当遇到0x0A字节时，它必然是换行符，不可能是其他字符的组成部分。

3. 固定长度Unicode编码类
UTF-16和UTF-32属于这一类。换行符具有可预测的字节序列：UTF-16中是0A 00（LE）或00 0A（BE），UTF-32中是0A 00 00 00（LE）或00 00 00 0A（BE）。可以按对应的数据类型直接扫描。

4. 传统多字节编码类
这类包括中文的GB2312、GBK、Big5，日文的Shift-JIS，韩文的EUC-KR等。这是最让人担心的一类，因为理论上多字节字符的任何一个字节都可能与0x0A冲突。

让我们仔细分析几个典型编码的字节分布规律。GB2312的编码规则是第一字节0xA1-0xFE，第二字节0xA1-0xFE。等等，0xA1的十进制是161，远大于0x0A（十进制10）。看起来第一字节不会有问题，第二字节也是从0xA1开始，同样避开了0x0A。

GBK的情况稍复杂，第一字节范围是0x81-0xFE，第二字节分为两个范围：0x40-0x7E和0x80-0xFE。第一字节0x81开始，大于0x0A。第二字节的第一个范围从0x40开始，0x40是64，仍然大于0x0A。第二个范围0x80-0xFE更是远离0x0A。

Shift-JIS的第一字节是0x81-0x9F和0xE0-0xEF，都大于0x0A。第二字节是0x40-0x7E和0x80-0xFC，最小值0x40仍然大于0x0A。

Big5的第一字节0xA1-0xFE，第二字节0x40-0x7E和0xA1-0xFE，模式相同。

观察规律

仔细检查这些数字后，发现了一个有趣的规律：所有这些传统多字节编码的字节取值都避开了0x0A。不管是作为第一字节还是第二字节，0x0A都不会出现在任何多字节字符中。

我又查看了更多编码的详细规范。EUC-JP（日文扩展Unix编码）的第一字节是0x8E、0x8F或0xA1-0xFE，第二字节是0xA1-0xFE，同样没有0x0A。韩文的EUC-KR，第一字节0xA1-0xFE，第二字节0xA1-0xFE，依然如此。繁体中文的CNS 11643，第一字节0xA1-0xFE，第二字节0xA1-0xFE，情况相同。

也就是说，当我们在这些编码的文件中遇到0x0A字节时，它肯定是换行符，而不是某个字符的一部分。这个观察结果对于我查阅过的所有传统多字节编码都成立。

这种一致性让问题变得简单了。原本担心的"需要先解码再找换行符"的复杂流程其实完全不必要。不管是什么编码，我们都可以直接在字节层面扫描特定的模式来找到换行符。

统一处理策略

现在问题变得出奇简单。所有主流编码都可以通过字节级模式匹配来定位换行符：

1. 单字节编码和UTF-8：直接扫描0x0A字节
2. UTF-16：扫描0A 00（LE）或00 0A（BE）
3. UTF-32：扫描0A 00 00 00（LE）或00 00 00 0A（BE）
4. 传统多字节编码：直接扫描0x0A字节

实现方案就是统一的字节级扫描：首先检测文件编码（通过BOM标记或启发式方法），然后根据编码类型选择对应的扫描模式，建立行起始位置的字节偏移索引，最终实现随机行访问。

这种方法的优势是内存占用与文件大小无关，只需存储行偏移索引。处理速度比完整字符解码快数倍，还可以利用SIMD指令进一步优化字节模式匹配。需要注意的是要处理不同系统的行结束符变体（LF、CRLF、CR）。

原本看似需要针对每种编码写复杂解析逻辑的问题，最终通过简单的字节级操作就解决了。这种方法完全跳过了字符解码环节，直接在字节流中定位行边界。

代码实现（TypeScript）

这里给出基于typescript的实现，其它语言类似

/**
 * buildLineStartIndex
 *
 * 作用
 * - 读取整个文件，按给定编码仅以 LF('\n', U+000A) 分隔，返回每行的起始“字节偏移”索引（Uint32Array）。
 * - 第 1 个索引恒为 0。
 *
 * 原理（关键点）
 * - 仅匹配 LF 的“码元值”，无需完整解码：
 *   - 1 字节编码/UTF-8：LF = 0x0A
 *   - UTF-16：LE = 0x000A，BE = 0x0A00（在宿主端序视角下的数值）
 *   - UTF-32：LE = 0x0000000A，BE = 0x0A000000
 * - 使用与码元宽度一致的 TypedArray（Uint8/16/32），直接 indexOf(LF) 扫描，避免 DataView 的端序开销。
 *
 * 使用范围
 * - encoding ∈ {'utf8','single','utf16le','utf16be','utf32le','utf32be'}
 * - 仅识别 LF 为换行；CR/CRLF 不特殊处理（'\r' 视为普通字符）。
 * - 缓冲区长度需为码元大小整数倍（UTF-16 偶数字节，UTF-32 为 4 的倍数）。
 */
export async function buildLineStartIndex(
  file: File,
  encoding: 'utf8' | 'single' | 'utf16le' | 'utf16be' | 'utf32le' | 'utf32be'
): Promise<Uint32Array> {
  const bytes = new Uint8Array(await file.arrayBuffer());

  // 编码配置：选用合适的 TypedArray、单位字节数、以及“在宿主端序下应匹配的 LF 值”
  const configs = {
    utf8:     { ArrayType: Uint8Array,  unitSize: 1 as const, LF: 0x0A },
    single:   { ArrayType: Uint8Array,  unitSize: 1 as const, LF: 0x0A },
    utf16le:  { ArrayType: Uint16Array, unitSize: 2 as const, LF: 0x000A },
    utf16be:  { ArrayType: Uint16Array, unitSize: 2 as const, LF: 0x0A00 },
    utf32le:  { ArrayType: Uint32Array, unitSize: 4 as const, LF: 0x0000000A },
    utf32be:  { ArrayType: Uint32Array, unitSize: 4 as const, LF: 0x0A000000 }
  } as const;

  const cfg = configs[encoding];
  if (!cfg) throw new Error(`Unsupported encoding: ${encoding}`);

  if (bytes.byteLength % cfg.unitSize !== 0) {
    throw new Error(`Buffer length must be a multiple of ${cfg.unitSize} for ${encoding}`);
  }

  const starts: number[] = [0];
  const view = new cfg.ArrayType(bytes.buffer, bytes.byteOffset, bytes.byteLength / cfg.unitSize);

  for (let i = 0; ; ) {
    const p = (view as any).indexOf(cfg.LF, i);
    if (p === -1) break;
    starts.push((p + 1) * cfg.unitSize); // 累加下一个行起始的字节偏移
    i = p + 1;
  }

  return new Uint32Array(starts);
}

附：不同编码特点

关键结论（已体现在备注中）：

• 🟢 大多数编码中 LF 与普通字符不重叠。
• 🔵 UTF-8、ASCII 最稳妥，跨平台与工具链支持最佳。
• 🟠 GBK/Shift_JIS/ISO-2022-JP 等多字节或状态机编码在解析上更复杂，但 LF 依然不与普通字符重叠。
• 🔴 SCSU/BOCU-1 处于历史/实验地位，现实使用极低，不建议采用。