你从 Windows 传上 Linux 服务器的一个test.sh一执行就报$\r: command not found反过来你把 Linux 下生成的 CSV 发给同事用 Excel 打开结果全挤成了一行。这两种经典场面指向同一个根源行尾符不同。而这个根源在命令行层面的标准解法就是unix2dos以及它的兄弟dos2unix。我最早碰到这个命令是在处理一批老式 Windows 程序导出的业务数据时整个团队被文件末尾的^M搞得头大最后查出最稳最快的处理方式就是先跑一遍行尾转换。这篇文章会把unix2dos相关的原理、参数、坑以及我在实际维护服务器时的经验全部写出来给正在跟行尾符搏斗的同学一份可以直接照做的行动方案。1. 行尾符的历史与 unix2dos 的定位1.1 回车、换行和那台老式电传打字机要理解unix2dos在干什么先得看行尾符本身。文本文件里的“换行”并不是一个天然统一的概念在计算机早期至少有过三种表达方式LFLine Feed换行ASCII 码0x0A也就是平时说的\nCRCarriage Return回车ASCII 码0x0D也就是\rCRLF两个字符连续出现0x0D 0x0A即\r\n。这套符号来自电传打字机。老式设备要开始新的一行需要先把打印头移回行首这个动作叫回车CR再让纸向上走一行这个动作叫换行LF。当时有些设备只做一个动作就能继续打印有些设备必须两个都做后来各家操作系统沿用了不同的习惯。Unix 和现代 Linux、macOS 使用 LF 作为行结束符Windows 以及更早的 DOS 使用 CRLF而更早的老 Mac 系统还用过单独一个 CR。现在你看unix2dos这个名字就是“Unix 格式转 DOS 格式”的缩写它做的事情就是在只剩下 LF 的行尾补上 CR让文件变成 CRLF。这里很多人会有一个误解以为“换行”是某种不可见的玄学格式。其实用十六进制看一眼就明白。一个内容为hello的 Unix 文件末尾通常是这样68 65 6c 6c 6f 0a换成 CRLF 之后是这样68 65 6c 6c 6f 0d 0a区别就一个字节0d。但就是这一个字节能让终端、编辑器、脚本解释器做出完全不同的反应。Linux 下命令里常见的\r在终端中会被当作回车而不是换行于是整个输出逻辑都可能乱掉。作为经常要在 Windows 和 Linux 之间来回拷贝文件的人行尾概念是绕不过去的基础课。1.2 行尾不一致会引出哪些实际故障行尾符看起来是小问题但在真实工作里引发的故障一点都不小。我挑几个高发场景说一下。第一个是 shell 脚本。在 Windows 上编辑过的脚本传到 Linux 后直接执行经常看到这样的报错bash: ./test.sh: line 2: $\r: command not found原因是脚本里的每一行其实都是#!/bin/bash\r\nLinux 的 bash 把\r也当成了命令的一部分。执行到空行时bash 试图执行一个只有回车字符的“命令”于是报了这么个莫名其妙的错误。第二个是配置文件解析失败。Linux 下很多服务对配置文件的结尾要求很敏感。有人在 Windows 上打开/etc/nginx/nginx.conf或者其他应用配置顺手保存了一下再传回服务器服务重启时就开始报格式错误。排查了半天最后发现是行尾被改成了 CRLF。此类问题在cron定时任务、环境变量文件、systemd的 unit 文件里也经常出现。第三个是版本控制里的“炸 diff”。如果团队中有人用 Windows有人用 Linux仓库里的行尾一会是 LF 一会是 CRLF每次提交都会看到整文件被标记为改动代码评审体验极其痛苦。第四个是数据文件处理。CSV、日志、脚本导出文件如果从一个系统拿到另一个系统用 Excel 打开或直接用 grep、awk 处理时经常出现行不识别、字段错乱、末尾多了^M的情况。cat -A能看到这种隐藏字符但大多数业务同事并不知道这是什么。unix2dos这类工具存在的意义就是用一条命令把这些问题在源头处理干净。它不修改文件内容只统一行尾风险小见效快。2. 工具家族unix2dos、dos2unix 与安装方法2.1 两个命令其实是一家人先澄清一个最常见的困惑unix2dos和dos2unix到底是什么关系它们来自同一个开源工具包安装后通常会同时提供unix2dos和dos2unix两个命令本质是同一套代码的两个入口。unix2dos把 Unix 行尾 LF 转换成 DOS/Windows 行尾 CRLFdos2unix反向操作把 CRLF 转回 LF。除了这两个包里还提供了mac2unix、unix2mac处理旧时代 Mac 的单独 CR 行尾不过现在很少用了。记住方向有个很简单的方法看名字的最后一部分代表目标格式。unix2dos是“到 dos”输出的是 Windows 能顺畅读取的 CRLFdos2unix是“到 unix”输出的是 Linux 环境下的 LF。所以如果你的 Linux 脚本在 Windows 上编辑后坏了要让它重新能在 Linux 运行应该执行dos2unix如果你手里的 Linux 生成文件要发给 Windows 用户用 Excel、记事本打开则执行unix2dos。方向搞反不但不能解决问题还会让文件更乱。在实际项目里我见到太多人搞反方向。有人明明要处理 Windows 传到 Linux 的脚本结果执行了unix2dos把 CRLF 继续加料脚本直接更没法跑。因此我强烈建议在任何批量操作之前先执行一次file 文件名查看格式file会明确显示“with CRLF line terminators”还是“ASCII text”再决定使用哪个命令。2.2 各大发行版的安装方式在包管理比较完善的发行版上安装这个工具非常简单。包名统一叫dos2unix虽然你要用的命令叫unix2dos但不要因为包名里没有unix2dos就犹豫。Debian / Ubuntu 系sudo apt-get update sudo apt-get install -y dos2unixRHEL / CentOS 7 等使用 yum 的系统sudo yum install -y dos2unixCentOS 8 / Fedora 这类使用 dnf 的系统sudo dnf install -y dos2unixArch Linuxsudo pacman -S dos2unixopenSUSEsudo zypper install dos2unixAlpine Linux容器场景常用apk add dos2unix如果你在完全没有外网的环境也可以从源码编译。dos2unix的源码不复杂下载解压后直接make sudo make install安装完成后验证工具是否可用which unix2dos unix2dos --version我一般在容器镜像里使用 Debian 系的apt-get安装一条命令装完镜像版本也比较新。需要注意的是有些极简镜像可能没有预装file命令如果你的工作流里习惯了先用file判断行尾可以顺带装上file包。3. unix2dos 核心用法参数、批处理与自动化3.1 基础语法与原地转换模式unix2dos的基本语法非常简单unix2dos [选项] [文件 ...]默认情况下它直接修改原文件把文件里的 LF 行尾改成 CRLF。例如unix2dos -o report.txt这里的-o是--oldfile的缩写表示原地转换也是默认行为。多数场景下你只需要这样一条命令就能完成工作。如果你想保留原始文件另存一个新文件使用-n参数unix2dos -n report.txt report_win.txt-n需要成对给出输入文件和输出文件而且输出文件不能和输入文件是同一个。它的好处是转换前可以留一个原始备份适合在跑批数据之前先做验证。我实际最常用的组合是unix2dos -k -o file.txt-k是--keepdate保留文件的时间戳。很多系统脚本会拿文件 mtime 做增量判断如果不加-k转换一次文件后 mtime 更新可能触发不必要的下游任务。这个参数在归档、备份场景下尤其重要。3.2 高频参数速查为了让大家快速上手我把日常用到的高频参数整理成一个表方便查阅参数作用典型使用场景-o原地转换修改原文件默认动作大部分单文件处理-n转换到新文件需要备份或同时保留两个版本-k保留文件时间戳脚本、归档、增量同步场景-f强制转换二进制文件文件被误判为二进制时谨慎使用-c指定转换模式如 ascii、7bit、iso、mac处理非 UTF-8 或特殊字符集文件-s静默模式减少输出信息批量处理时避免刷屏-h/--help显示帮助信息快速查看所有可用参数这里特别注意-f。unix2dos在转换前会判断文件是否为文本如果一个文件里有很多不可打印字节工具会认为它是二进制文件并跳过转换。这是保护机制防止你误伤可执行程序或图片。但比如某些配置文件里就是包含非常规字节工具判定错误时可以用-f强制转换。强制转换有风险转换前最好手动file检查确认它本质还是文本。-c参数在中文环境中比较常见。比如处理一些老的 ISO-8859-1 编码文件时可以指定-c iso让工具按 ISO 编码模式去理解字节。日常处理 UTF-8 文件用默认的ascii模式就够了。如果你在大量自动化脚本里需要保持输出干净记得加-s避免每次转换都打印一行说明。3.3 批量处理与自动化场景单个文件用unix2dos很简单难点在于成百上千个文件的批量统一。好在它天然支持多个文件参数unix2dos -k *.txt *.csv一次传多个文件工具会逐个处理。如果有目录嵌套需要配合find。比如我要把当前目录下所有.conf后缀的配置文件统一转成 Windows 行尾find . -type f -name *.conf -print0 | xargs -0 unix2dos -k -o或者更直观地使用-execfind . -type f -name *.conf -exec unix2dos -k -o {} \;如果你在 Windows 编辑过一批.sh脚本传到 Linux 后想统一恢复成 LF则反向操作find . -type f \( -name *.sh -o -name *.py -o -name *.conf \) -exec dos2unix -k -o {} \;自动化运维时我常把行尾转换作为部署流水线的一步。代码从 Windows 同事的本地仓库 push 到服务器后先执行一次dos2unix再启动服务可以少掉很多因为行尾导致的诡异问题。在 CI 里甚至可以加一个专门的 lint 阶段检查即将提交的文件是否混用了行尾。4. 编码、BOM 与边界情况确保“转完不坏文件”4.1 unix2dos 到底会不会改编码很多人担心运行unix2dos会改变文件编码这个担心可以放下大半。工具的核心任务只是在合适的行尾位置插入0d或者去掉0d它不会主动把 UTF-8 改成 GBK也不会反过来。真正需要留意的是那些“行尾字符恰好容易和编码字节混淆”的场景。举个例子UTF-16 编码的文本文件里ASCII 字符的字节是xx 00 xx 00这种形态直接按单字节扫描很容易把0a 00这类数据误认为是换行。这种情况下unix2dos的默认模式可能做出错误判断。工具提供了-c转换模式来应对比如unix2dos -c UTF-16LE file。在实际情况中这类转换我建议先用file确认编码再用合适的模式处理不要盲目套默认参数。另一个容易踩的点是 BOM。Windows 记事本保存 UTF-8 文件时默认会在开头写入 BOM即EF BB BF三个字节。一些老程序只有在看到 BOM 时才认为是 UTF-8。unix2dos只处理行尾不会帮你加 BOM 或去 BOM。因此如果你要用 PowerShell 或记事本处理来自 Linux 的文件可能需要额外处理 BOM。可以用sed在文件开头插入 BOMsed -i 1s/^/\xef\xbb\xbf/ file.txt要去掉 BOMsed -i 1s/^\xef\xbb\xbf// file.txt如果文件本身就是 UTF-8没有 BOMWindows 新版记事本通常也能正确识别。但在比较老的生产环境里我一般建议显式处理。4.2 文件编码与行尾转换的配合当文件同时存在编码和行尾两个问题时推荐先转码再转行尾。比如一个老系统导出的 GBK 编码 CSV要交给 Windows 同事用 Excel 打开如果只执行unix2dosExcel 打开后还是会乱码。正确流程是iconv -f GBK -t UTF-8 source.csv source_utf8.csv unix2dos -k -o source_utf8.csv如果担心临时文件太多可以用管道加进程替换的方式但要注意不同平台的unix2dos对标准输入的支持略有差异。为了稳定我更推荐写一个简单的临时文件方案。这里顺便提一句“解压文件乱码”。网上下载的 zip 包尤其是从 Windows 机器打的包解压到 Linux 后经常出现中文文件名乱码。这通常不是行尾问题而是 zip 包内编码标记不统一文件名用了 GBK 但工具按 UTF-8 解码。行尾转换解决不了这个你需要用支持编码猜测的解压工具或者在 Windows 打包时就统一成 UTF-8。很多新手会把这两类问题混在一起最后既没解决解压乱码又顺手把所有文件的行尾改乱。4.3 一个综合案例整理 GBK 报文并交付给 Windows 用户我分享一个当时在数据对接项目里的实际操作。客户从老系统导出一批 GBK 编码的日志要找我们统计里面的关键字分布但 Excel 打不开。我当时的处理步骤第一步先看文件格式file old.log输出是ISO-8859 text, with CRLF line terminators说明编码不是 UTF-8行尾还是 DOS 格式。这类文件其实已经能直接在 Windows 打开但我们内部工具是 Linux需要先转到 Linux 环境。第二步转码并统一成 Unix 行尾iconv -f GBK -t UTF-8 old.log | dos2unix -o - new.log这里使用管道需要注意版本但在这台服务器上实测是稳定的。转换后再用xxd或file验证file new.log xxd new.log | tail -2一切正常后再把需要交付给客户的那份转成 Windows 格式unix2dos -k -o new_deliver.log整个过程下来客户拿到文件直接双击打开字段、中文、行数全部正常。这类流程现在已经成为我在处理跨系统文本时的标准动作先file识别再iconv转码再unix2dos或dos2unix调整行尾最后xxd抽查。5. 常见问题排查那些年我在生产环境踩过的坑5.1 脚本报$\r: command not found该用哪个方向这是最经典的场景。报错信息里出现了\r说明脚本原来是 CRLF 行尾在 Linux 下执行时 bash 把回车当成了命令。正确的处理方向是dos2unix不是unix2dos。诊断方法很简单file test.sh cat -A test.shcat -A如果显示行尾是^M$就说明是 CRLF纯 LF 只会看到$。执行修复dos2unix -k -o test.sh修复后再cat -A查看确认所有^M消失脚本就能跑了。我的经验是遇到这种报错先别急着改脚本内容更别用sed粗暴删除所有\r。有些文件可能同时在内容里有需要保留的回车字符老老实实用dos2unix做行尾转换最安全。5.2 转换后文件无法执行或显示异常有人执行unix2dos后发现原本能运行的 Linux 脚本反而不行了转而怀疑工具坏了。其实方向又搞反了。unix2dos本来就是给 Windows 环境准备文件不是给 Linux 执行准备的。如果你想在 Linux 上运行脚本如果你猜到了方向错误直接用dos2unix转回来即可。还有一种是编辑器打开了转换后的文件看到每行后面多个^M。这是正常的因为^M就是 CR 字符的显示形式在 Windows 记事本里是无感的在 Linux 的vi或less里就会暴露出来。如果你需要临时查看 CRLF 文件可以用vi打开后执行:set fileformatdos :set list这样视觉上会友好一些。5.3 二进制文件被误判或损坏unix2dos对二进制文件默认是拒绝转换的。它内部有一套判断逻辑当文件包含太多非常规字符时会自动跳过。但跳过时如果你没有看输出可能以为转换成功了其实文件没动。这时候加-f可以强制转换但强制转换是危险的。我遇到过一次某个程序生成的二进制配置里包含固定长度的0a字节恰好在判断规则边界附近工具把它当文本处理硬插入了多个0d文件直接损坏。从那以后我对-f特别谨慎。强制转换之前务必确认这个文件本质确实是文本只是部分字节让工具产生了误判。一个更稳妥的做法是批量操作时先在一个副本上测试用diff或cmp对比转换前后确认业务解析正常后再铺开全量处理。5.4 转换后 git 看到大量 diff行尾不统一在 git 里是个老问题。如果你在仓库里批量执行unix2dos或dos2unixgit status 会显示大量文件变更。这本身不是 bug但团队协作时需要统一策略。推荐在仓库根目录放一份.gitattributes明确不同类型文件的行尾要求* textauto *.sh text eollf *.bat text eolcrlf *.py text eollf *.cs text eolcrlf配上git config core.autocrlf的设置后git 在检出和提交时会自动处理行尾转换手动批量转换的需求会少很多。不过一旦历史文件已经被混用仍然需要借助unix2dos或dos2unix做一次性的整理再让.gitattributes维持后续状态。5.5 转换后时间戳变化影响增量同步这是一个非常隐蔽但影响很大的问题。默认转换时输出文件的时间会被更新为当前时间。如果你的备份或同步脚本依赖 mtime 判断文件是否有变化那么即使内容只多了几个字节时间戳变化也会导致后续流程认为文件被修改。解决方式就是加-k。我维护的服务器上有台机器会定期从 Windows 同事的共享目录拉取配置文件拉取后自动跑unix2dos -k -o。第一次没加-k后续监控系统报告一堆文件在反复同步排查很久才发现是 mtime 变了。加-k后问题立刻消失。6. 不用 unix2dos 时的替代方案与个人经验6.1 sed、awk、vi 都能改行尾unix2dos不是唯一方案很多文本工具也能做同样的工作但各有优劣。最经典的是sed。把 Unix 文件转成 DOSsed s/$/\r/ input.txt output.txt这样会在每一行末尾追加 CR。注意如果输入文件已经是 CRLF这个命令会把原本的 CRLF 变成 CRCRLF所以它会制造问题。转回去删除行尾 CRsed s/\r$// input.txt output.txtawk也可以awk { sub(/$/, \r); print } input.txt output.txt用vi手动操作也是可行的。vi打开文件后:set fileformatdos :wq这样会把文件保存成 CRLF。反向操作就是:set fileformatunix。但这些替代方案都有局限。sed很容易误判已经带有 CR 的行批量处理时很容易造成重复转换。vi不适合大量文件。综合比较下来处理文本行尾转换还是优先用专门的unix2dos和dos2unix它们对边界情况处理得更完善也不是简单字符串替换。6.2 图形化工具与跨编辑器协作如果你在 Windows 上开发协调同事的行为可能更实用。VSCode 右下角状态栏可以看到当前行尾是 LF 还是 CRLF点击即可切换。Notepad 的“编辑”菜单里有“行尾转换”Windows 新版记事本也支持查看和保存 LF 文件。然而图形界面工具永远代替不了命令行工具的场景是批量处理。一批 1000 个文件用 Notepad 逐个改是不现实的。所以我的建议是个人编辑器按自己习惯设置跨系统批量交接一律用命令行工具同时在 Git 仓库里用.gitattributes定义好规则这样最省事。6.3 我给新人的一个小建议如果你刚接触 Linux遇到文件打开异常、脚本执行报错、日志 grep 结果奇怪先别盯着内容分析用file命令看一眼行尾和编码用cat -A看一眼隐藏字符。养成这个习惯后很多“玄学问题”其实一眼就能定位。unix2dos虽然只是个简单的小工具但它在跨系统协作里扮演的角色绝对比表面看起来重要得多。我自己现在处理任何文本交接都会下意识把行尾转换这一步放进流程里而不是等出问题再回头排查。