换行与 UTF-8 BOM 转换

文本处理

正在载入

正在加载工具

工具代码会在打开时按需载入，请稍候。

本工具的全部运算都发生在你的浏览器中，输入内容不会发送到任何服务器。

关于这个工具

编辑器中的普通行可能来自不同的换行字节。分别检查 LF、CRLF 和单独 CR，再选择保留原样或统一转换，不裁剪文本，也不擅自添加末尾换行。本工具在有界转义预览旁保留完整原文，并单独生成转换结果。UTF-8 文件字节签名与 U+FEFF 文本分开记录，因此移除文件 BOM 不会悄悄删除实际文本字符。请依据接收系统的约定选择输出格式，而不是把某种换行视为永远正确。

常见用途

为明确要求 Windows 换行的系统准备 CRLF 格式 UTF-8 配置样本。
定位文本导出中的混合换行，并在替换文件前比较原文与输出字节数。
移除已知 UTF-8 文件签名，同时保留额外的开头 U+FEFF 及内部 U+FEFF。

使用方法

1.粘贴字面文本或打开本地 UTF-8 文件。严格解码拒绝无效 UTF-8 与 UTF-16/UTF-32 签名；无 BOM 文件只按 UTF-8 解释，不猜测其他编码。文件第一个 EF BB BF 前缀作为签名记录，后续 U+FEFF 保留为文本。
2.选择换行及 BOM 策略后分析。比较原文和输出的分隔符数量、混合状态、逻辑行、UTF-16 单元、码点和 UTF-8 字节。转义预览最多显示 2,000 个源单元及 12,000 个呈现字符；预览截短不改变完整结果。
3.明确审阅后再复制或下载。UTF-8 文件下载保留精确字节和所选签名；ASCII JSON 报告保留完整原文与输出，必须当作包含原始隐私内容的文件。修改输入或策略会使之前的审阅失效。复制仅包含正文，不包含单独记录的签名。剪贴板和接收应用可能改变换行；需要精确字节时请下载 UTF-8 文件。

精确合成转换示例

混合换行转 LF

request (ASCII JSON): {"input":"A\r\nB\nC\rD","source":"paste","bom":false,"newline":"lf","bomPolicy":"preserve"}

{"text":"A\nB\nC\nD","bom":false,"crlf":0,"lf":3,"cr":0,"logicalLines":4,"utf16Units":7,"codePoints":7,"utf8Bytes":7}

三种分隔符成为三个 LF，不添加尾部换行。

LF 转 CRLF 并添加签名

request (ASCII JSON): {"input":"a\nb","source":"paste","bom":false,"newline":"crlf","bomPolicy":"add"}

{"text":"a\r\nb","bom":true,"crlf":1,"lf":0,"cr":0,"logicalLines":2,"utf16Units":4,"codePoints":4,"utf8Bytes":7}

CRLF 正文为四字节，单独的签名再增加三字节。

转换为旧式 CR

request (ASCII JSON): {"input":"a\r\nb\n","source":"paste","bom":false,"newline":"cr","bomPolicy":"remove"}

{"text":"a\rb\r","bom":false,"crlf":0,"lf":0,"cr":2,"logicalLines":3,"utf16Units":4,"codePoints":4,"utf8Bytes":4}

一个 CRLF 与一个 LF 各变为一个 CR，原有末尾分隔符保留。

保留混合正文

request (ASCII JSON): {"input":"a\r\nb\rc\n","source":"paste","bom":false,"newline":"preserve","bomPolicy":"preserve"}

{"text":"a\r\nb\rc\n","bom":false,"crlf":1,"lf":1,"cr":1,"logicalLines":4,"utf16Units":7,"codePoints":7,"utf8Bytes":7}

每个分隔符均保留，包括尾部 LF 和末尾空逻辑行。

只移除文件签名

request (ASCII JSON): {"input":"\ufeffA\r\n","source":"file","bom":true,"newline":"lf","bomPolicy":"remove"}

{"text":"\ufeffA\n","bom":false,"crlf":0,"lf":1,"cr":0,"logicalLines":2,"utf16Units":3,"codePoints":3,"utf8Bytes":5}

文件原有签名后还有文本 U+FEFF；移除签名后仍保留该文本。

保留粘贴的 U+FEFF

request (ASCII JSON): {"input":"\ufeffA","source":"paste","bom":false,"newline":"preserve","bomPolicy":"remove"}

{"text":"\ufeffA","bom":false,"crlf":0,"lf":0,"cr":0,"logicalLines":1,"utf16Units":2,"codePoints":2,"utf8Bytes":4}

粘贴开头的 U+FEFF 是文本，移除策略不会删除它。

保留 Unicode 分隔字符

request (ASCII JSON): {"input":"a\u0085b\u2028c\u2029d\n","source":"paste","bom":false,"newline":"crlf","bomPolicy":"preserve"}

{"text":"a\u0085b\u2028c\u2029d\r\n","bom":false,"crlf":1,"lf":0,"cr":0,"logicalLines":2,"utf16Units":9,"codePoints":9,"utf8Bytes":14}

只有末尾 LF 变为 CRLF；NEL、LS、PS 不变，也不增加逻辑行。

统计辅助平面表情

request (ASCII JSON): {"input":"\ud83d\ude00\r\n","source":"paste","bom":false,"newline":"lf","bomPolicy":"preserve"}

{"text":"\ud83d\ude00\n","bom":false,"crlf":0,"lf":1,"cr":0,"logicalLines":2,"utf16Units":3,"codePoints":2,"utf8Bytes":5}

表情占两个 UTF-16 单元、一个码点和四个 UTF-8 字节。

为空文本添加签名

request (ASCII JSON): {"input":"","source":"paste","bom":false,"newline":"lf","bomPolicy":"add"}

{"text":"","bom":true,"crlf":0,"lf":0,"cr":0,"logicalLines":0,"utf16Units":0,"codePoints":0,"utf8Bytes":3}

正文仍为空、逻辑行为零，只输出三字节签名。

在 JSON 保留孤立代理项

request (ASCII JSON): {"input":"A\ud800\r\n","source":"paste","bom":false,"newline":"lf","bomPolicy":"preserve"}

{"text":"A\ud800\n","bom":false,"crlf":0,"lf":1,"cr":0,"logicalLines":2,"utf16Units":3,"codePoints":3,"utf8Bytes":null}

禁止 UTF-8 原始导出，ASCII JSON 精确保留 U+D800 单元。

转义拼写保持字面含义

request (ASCII JSON): {"input":"a\\r\\nb","source":"paste","bom":false,"newline":"lf","bomPolicy":"preserve"}

{"text":"a\\r\\nb","bom":false,"crlf":0,"lf":0,"cr":0,"logicalLines":1,"utf16Units":6,"codePoints":6,"utf8Bytes":6}

反斜杠转义拼写是普通 ASCII，工具不会执行或解释它。

常见换行与 BOM 误区

把 CRLF 算作两个换行。
把粘贴开头的 U+FEFF 都当作可删除的签名。
凭视觉预览认定字节完全相同，或假定复制不会改变换行。
认为字节数相同就表示文本相同。
期待 NEL、LS、PS 自动变为 LF。
把完整 ASCII 报告当作脱敏文件分享。

限制与说明

仅转换 CRLF、LF 和 CR，CRLF 计为一个分隔符。NEL（U+0085）、LS（U+2028）、PS（U+2029）、空格、制表符和其他文本原样保留。空文本为 0 个逻辑行；非空文本为分隔符数 + 1，包含尾部分隔符后的空行。不增删末尾换行。
BOM 策略保留、添加或移除一个三字节 UTF-8 文件签名，绝不移除文本 U+FEFF。粘贴的 U+FEFF 属于文本，无法还原原始文件编码或签名。在文本 U+FEFF 前添加签名会有意产生连续两个 EF BB BF。浏览器粘贴或剪贴板可能在工具外改变换行。输出文本以 U+FEFF 开头。即使没有单独添加签名，UTF-8 字节仍以 EF BB BF 开头，其他解码器可能将其作为签名吞掉。移除这些字节会删除保留的文本字符。
UTF-8 字节数包含单独记录的签名；UTF-16 单元和码点只统计正文。辅助平面字符占两个 UTF-16 单元和一个码点。码点不是字素簇或显示列。孤立代理项保留用于诊断，计为一个异常码点，没有有效 UTF-8 长度；阻止原始导出，而不是替换为 U+FFFD。
处理上限为输入 100,000 个 UTF-16 单元、文件 400,003 字节、输出 200,000 单元和 800,003 字节、ASCII 报告 2,000,000 字符。超限明确失败，不提供不完整下载。全程本地处理，不上传、不联网、不持久存储、不执行文本。工具不是编码猜测器、Unicode 规范化器、空白清理器或安全过滤器。
ASCII JSON 无损保留原文和输出的所有 UTF-16 单元，包括孤立代理项。转义是可逆表示，不是脱敏、匿名化或加密；报告包含完整原文及可能存在的秘密。UTF-16、UTF-32 文件需先通过单独的明确编码转换流程再导入。

常见问题

移除 BOM 会删除全部 U+FEFF 吗？

不会。只有文件首个 EF BB BF 前缀是签名元数据。之后的开头及内部 U+FEFF 都是文本。所有粘贴的 U+FEFF 都保留，即使位于第零个位置。输出文本以 U+FEFF 开头。即使没有单独添加签名，UTF-8 字节仍以 EF BB BF 开头，其他解码器可能将其作为签名吞掉。移除这些字节会删除保留的文本字符。

保留策略能恢复粘贴时改变的换行吗？

不能。它保留工具实际接收到的字符串。浏览器或剪贴板可能已经统一换行；需要精确输入字节时，请导入原始 UTF-8 文件。

为什么以换行结束时多一个逻辑行？

逻辑行按 CRLF、LF 或 CR 分隔后的片段计数，尾部分隔符会产生一个空片段。空文本单独约定为零行。

能转换任意字符编码吗？

不能。无效 UTF-8 及 UTF-16/UTF-32 签名会被拒绝。无 BOM 字节必须能严格解码为 UTF-8；解码成功并不证明作者原本想使用哪种编码。