行尾转换
统一行尾为 CRLF / LF / CR，自动检测当前行尾并统计各类型数量；跨平台打开脚本报错时常用来救场。
>_ 使用指南 · GUIDE
把文本粘贴进来，工具会自动检测当前行尾类型并统计各类型数量，然后一键统一为 CRLF（Windows） / LF（Unix/macOS） / CR（老 Mac） 之一，输出结果直接复制回去覆盖保存。
行尾（line ending）是每行结束处的隐藏字符：Windows 用回车+换行（\r\n，即 CRLF），Unix/Linux 与新版 macOS 只用换行（\n，即 LF），上古 Mac 用回车（\r，即 CR）。不同系统产生的文件混用这些字符，会导致脚本报错、git diff 显示整行变化、配置文件解析异常。
常见场景：
- 脚本报错：
.sh/.bat或 Python 脚本在跨平台打开后报奇怪的错误，多半是行尾不一致 - 统一提交：团队约定用 LF，把从 Windows 拷来的 CRLF 文件统一转 LF 再入库，避免无谓 diff
- 批量规整：粘贴进含多种行尾混用的内容，先看检测结果再一键统一
转换只处理行结束符，不影响任何文本内容；处理在浏览器本地完成，文件不会上传。
>_ 常见问题 · FAQ
Q1 · CRLF 和 LF 到底有什么区别？
CRLF 是两个字符——回车符 \r（CR）+ 换行符 \n（LF），是 Windows 的行尾约定；LF 只有一个换行符 \n，是 Unix/Linux 和现代 macOS 的约定。它们不可见但真实存在于文件里，混用时会引发各种「换行」问题。多数现代工具都能读写两者，但一个文件内应保持一致。
Q2 · 为什么脚本在 Windows 上写的，拿到 Linux 跑就报错？
Windows 默认生成 CRLF 行尾的脚本，Linux 解释器（尤其是 sh、.py 首行 shebang）会把行尾的 \r 当成命令的一部分，于是报「command not found」或奇怪的语法错。把文件行尾统一成 LF 后通常立即恢复正常。
Q3 · 我该把行尾统一成 CRLF 还是 LF？
看运行/提交环境：主要跑在 Linux/macOS 或 Git 仓库，统一成 LF（Git 默认建议 LF，可配 core.autocrlf 自动转换）；主要给 Windows 记事本/老工具用，统一成 CRLF。现代编辑器和 Git 一般都能自动处理，但入库文件建议统一为 LF 以减小跨平台 diff。
Q4 · 为什么我没改几行，git diff 却显示整个文件都变了？
最典型的原因是行尾被整体改了——某次保存或某个工具把整个文件从 CRLF 换成了 LF（或反之），Git 就把每一行都视为变化。用行尾工具先把文件统一到仓库规范（配合 .gitattributes 或 core.autocrlf），再做真正的修改，就能避免这类「假 diff」。
Q5 · 文本里有多种行尾混在一起怎么处理？
先让工具自动检测并查看各类型数量统计，确认确实混用后，再选择目标行尾一键统一。统一后行与行之间不再有隐藏差异，跨平台打开、提交、解析都会干净得多。