换行符转换

不是工具问题，很可能是复制时编辑器自动保留了原格式。多数代码编辑器（VS Code、Sublime）在粘贴时会自动适配当前文件的换行风格，导致你看到的换行符已经和工具里选的目标格式一致了。建议先在本工具输入区粘贴后，点「查看原始字符」按钮（如果有），确认原始换行符类型；或者用十六进制编辑器看一眼 0x0A/0x0D 的数量再做转换。

会，但变化很小。CRLF 每行末尾多一个 0x0D（回车），文件大小增加约 1 字节/行。如果文件有 10 万行，转换后大约减少 97KB。对于纯文本文件这个差异通常可忽略，但如果你在处理 Git 仓库的换行符统一（autocrlf），这点差异会导致 Git 认为文件被修改了，建议配合 .gitattributes 一起用。

这通常是因为原始文本混用了 CRLF 和 LF 两种换行符（比如从不同操作系统拼接的日志）。本工具按「全局统一替换」处理，不会智能识别每行当前用的哪种。如果你的文本里两种换行符都有，建议先转成 LF（Unix 标准），再从 LF 转成你想要的最终格式；或者先用正则替换工具把零散的 CR 先统一。

不支持。本工具只做 CRLF / LF / CR 三种标准换行符之间的互转，不涉及替换为其他字符。如果你需要把换行符替换成逗号、空格或自定义分隔符，应该使用「文本替换」或「正则替换」类工具。本工具的输出结果在复制后可以直接粘贴到替换工具里做二次处理。

CSV 文件乱行通常不是换行符类型的问题，而是字段内包含换行符（引号包裹的单元格内换行）。本工具只处理行末的换行符，不会触碰引号内的换行。建议先用支持 CSV 解析的工具（如 Notepad++ 的 CSV Lint 插件）检查字段内换行情况；如果字段内确实有换行，需要先用正则把引号内的换行替换为占位符，转换后再替换回来。

跨平台传文本最稳妥的是用 LF（Unix 格式）。Windows 原生用 CRLF，Mac 从 OS X 开始也用 LF，但旧 Mac（System 9 及之前）用 CR。如果你不确定对方用什么系统，统一转成 LF；大部分现代编辑器（VS Code、Sublime、Notepad++）都能正确显示 LF 换行的文件。本工具支持一键把 CRLF 转成 LF，适合做跨平台前的预处理。

不会。本工具标记为 FE 实现，所有换行符转换逻辑都在浏览器本地 JavaScript 里执行，文本不会离开你的电脑。你可以关掉网络再试一次——转换功能依然可用。如果你的文本包含敏感数据（如密钥、密码、个人隐私），可以放心使用，没有上传风险。

这通常是目标网站或输入框对换行符的渲染方式不同。有些网站（如文本编辑器类）会把 LF 渲染成换行，但某些后台系统（如数据库管理面板、旧版 CMS 后台）只认 CRLF。如果你粘贴到特定网站后失效，先确认该网站支持哪种换行符：Windows 服务器通常需要 CRLF，Linux 服务器通常接受 LF。本工具支持三种格式互转，你可以多试一次转成 CRLF 再粘贴。

CR 换行符目前主要用于老旧的 Mac 系统（System 9 及之前）和一些嵌入式设备输出的日志。如果你在处理 2000 年以前的 Mac 文件、某些工业设备（如 PLC、条码扫描器）的导出文本，或者从某些老旧数据库导出的文本，可能会遇到 CR 换行符。日常使用中几乎碰不到，但本工具保留了这个选项，方便处理这类历史遗留数据。