本次现场测试针对的是 Node.js。
相关问题是 Node.js #22448：
https://github.com/nodejs/node/issues/22448
公开的拉取请求在此处：
https://github.com/nodejs/node/pull/63789
报告的问题涉及逐行读取模块在遇到 Unicode 行分隔符时拆分输入。
默认情况下，Node 的逐行读取行为将 \u2028 和 \u2029 视为行分隔符。
这对于一般文本处理可能很有用，但对于 JSONL 等格式会造成问题，因为在这些格式中，记录可能包含这些 Unicode 字符作为实际行内容的一部分。
有用的诊断边界是：
逐行读取行解析 → Unicode 分隔符处理 → 面向记录的输入完整性
这一点很重要，因为逐行读取不仅仅是一个便利的应用程序接口。
它通常被用作原始输入与结构化记录处理之间的边界。
如果逐行读取在文件格式视为有效内容的字符处进行拆分，解析器可能会在应用程序看到完整行之前破坏调用者的记录边界。
用通俗的话来说：
输入流仍然包含一个逻辑记录，但逐行读取可能过早地将其拆分为多行
这是文本行便利行为与面向记录的输入真实性之间的边界失效。
修复措施特意保持狭窄范围。
它不改变默认行为。
它不移除对 Unicode 行分隔符的支持。
它添加了一个选项：
unicodeLineSeparators
默认值仍为 true，因此保留了现有行为。
当设置为 false 时，readline.createInterface() 和 readlinePromises.createInterface() 仅在回车符、换行符和回车换行符处拆分。在该模式下，\u2028 和 \u2029 保留在行内容内部。
这为调用者提供了一种清晰的方法来保持面向记录的输入，同时不会破坏依赖当前行为的现有用户。
该补丁更新了逐行读取实现、公开的应用程序接口文档以及回归测试覆盖。
以下验证已通过：
- Node 构建
- 聚焦于逐行读取行分隔符的测试
- 针对聚焦测试的 Node 测试运行器
- 对所触及文件的 JavaScript 代码风格检查
- 对所触及文档的 Markdown 格式检查
- 差异对比规范性
现场测试 #017
- 项目：Node.js
- 问题类型：逐行读取 Unicode 行分隔符行为
- 边界：文本行解析与面向记录的输入完整性
- 结果：开启了包含应用程序接口选项、文档和回归测试的公开拉取请求
- 状态：拉取请求已开启；待审查
本次现场测试很重要，因为它位于一个基础运行时应用程序接口内部。
该错误并非网络应用故障。
它也不是特定于框架的边缘情况。
它是一个影响程序如何消费输入的运行时边界。
调用者可能正在读取 JSONL、日志、流式记录或其他面向行的数据。如果运行时在应用程序的格式边界得到保持之前就拆分了输入，应用程序接收到的数据结构将不再真实反映源数据。
修复措施的重要部分在于，它没有将一种解释强加给所有人。
相反，它使边界变得明确。
默认行为保持不变。
面向记录的调用者可以选择启用更严格的仅基于回车符/换行符的行拆分。
这正是 Scarab 旨在揭示的那种修复：
不是大规模重写，
不是行为中断，
而是狭窄的边界修正，让运行时能够保持调用者实际依赖的真实性。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
