中国DOS联盟

今天在写一个批处理时偶尔发现了一个问题 如下一句： for /f %%i in(a.txt) echo %%i >b.txt 我以为a 文件和b 文件会完全一样的 但实际上b文件比a 文件稍大 哪位能给解释一下 多出来的字节是哪里来的。 谢谢！ ps:实际使用过程中 用的的是 >>b.txt for语句也还有一个 skip=1选项 因为 b 文件还会交给其他程序处理 所以想先确认一下用echo 是否会引起文件内容变化 知道结果不一样后 改用type 和 find 了 [ Last edited by namejm on 2007-2-5 at 12:43 PM ]

Re Denton: 一般情况下，b.txt 会比 a.txt 小，因为 for /f 的字符串解析只输出了 a.txt 每行第一个单词到 b.txt 中。你所遇到的情况，有可能是因为恰好 a.txt 的每行都只有一个单词，也即每行都没有空格。但这只能解释 b.txt 与 a.txt 相等大小，而不能解释 b.txt 比 a.txt 大， 出现这种情况的原因就较为复杂，有可能是行结束符由 0a 扩张为 0d0a，也有可能是其他未知的原因，这只有见到你的 a.txt 才能确定。

※ Batchinger 致 Bat Fans：请访问 [讨论]批处理编程的异类 ，欢迎交流与共享批处理编程心得！

test.bat的内容如下：在命令提示符的窗口中是这个结果，注意在"anything"之后多了一个空格，一个数字“1”。

C:\>echo anything 1>result.txt C:\>pause 请按任意键继续. . .

然而，输出的result.txt的内容却没有“ 1”！

anything

大家试试，看自己的机器上是什么现象。我的是XP下的CMD环境。 [ Last edited by arding on 2006-4-21 at 13:50 ]

有没有其他原因不清楚，至少，你在每行尾部多了一个空格！ for /f %%i in(a.txt) echo %%i >b.txt ------------------------------------------^------------HERE!

不要光看不说呀，大家把自己试验的结果公布一下，“ 1”有or没有？

Re arding: CMD解析批处理时，会将批处理中的每条语句，首先格式标准化之后，再解释执行。 比如上面的echo语句，它意图将echo到标准输出控制台设备的文本内容重定向到文件result.txt中，而CMD的重定向操作需要指向设备的句柄号，而指向默认的标准输出设备的句柄号正是1，CMD会在重定向符号前添加这个句柄号。同时，为了避免1与输出的文本内容混淆，前面会再加上一个空格，以示区分。 同样的我们在echo一些字符串时，也需要注意到一个问题。比如我们想将"3 7 2 1"输出到文件result.txt中，便不能用 echo 3 7 2 1>result.txt 而应该用 echo 3 7 2 1 >result.txt 或者 echo 3 7 2 1 1>result.txt 尤其是在echo某些变量文本时（比如在for中使用echo），必须考虑这个问题。 但是这两个方法都会在文本末尾添加一个多余的空格，这在大多数情况下是可以忽略的细节，但在某些需要进行文本严格匹配的场合中将会出错。目前，我尚在寻找可以在cmd下严格输出类似“3 7 2 1”的文本串的方法，希望大家也可以提出自己的宝贵建议。 [ Last edited by willsort on 2006-4-21 at 14:24 ]

※ Batchinger 致 Bat Fans：请访问 [讨论]批处理编程的异类 ，欢迎交流与共享批处理编程心得！

帅哥 命令错了我做了个简单的测试 a.txt中有字符(以下称a) 1 2 3 3 4 b.txt中的字符一样 但是两个文件确实不一样大 1个是15字节 一个是20字节 然后仔细对比文件 发现存在以下差别 a中每个字符后是回车符,直接换行 而b中为空格加回车符 如果只有1行字符,那么两个文件不存在差别 2行字符则差2个字节 3行差3个字节 写到这里 忽然想起来echo %%i后还有1空格,所以...... 现在明白聊~~ [ Last edited by kcdsw on 2006-4-21 at 20:22 ]

─────────────────　版务记录　───────────────── 执行：Will Sort 操作：合并主题：《20204 - ECHO的怪事，大家试试》 说明：二主题存在上下文的直接联系 处罚：鉴于原主题具有原创性，不予积分处罚 ─────────────────　版务记录　───────────────── Re kcdsw: 没有测试是否“如果只有1行字符,那么两个文件不存在差别”，仅从字面上理解感到不太可能。 另外，类似3 7 2 ^1的用法我最初曾试用过，但是考虑到它只对固定文本串有效，而对动态文本串无效，比如在以上的实例中，是无法使用转义字符“^”的，这才是问题的症结所在。 [ Last edited by willsort on 2006-4-21 at 19:42 ]

※ Batchinger 致 Bat Fans：请访问 [讨论]批处理编程的异类 ，欢迎交流与共享批处理编程心得！

呵呵 sorry 错了 差了一个字节 对动态文本无效么? 刚才测试是有效的哎~~~ 真晕 今天上班的时候出了错 幸亏客户说无所谓 ...... 所以今天一天都神经兮兮的 另外上面的文件是正常的 可以把1或者2转到b中去 刚测试的 且文件大小一致 [ Last edited by kcdsw on 2006-4-21 at 20:21 ]

另外我有个想法 既然1 2啊什么的代表了输出到哪里 我们是不是可以事先把这个转到其他地方去 让1 或者2 或者...恢复一下?

测试一下 ? 我这里是ok的 xp sp2

Re kcdsw: 不知兄所理解的“动态文本”与我预想的是否一致。同样在XPsp2的CMD下，以12楼的代码和6楼的数据测试。在提示下输入“3 7 2 1”后回车，得到的文件a.txt内容如下[1]（十六进制截取），我注意到2后跟了两个空格，除了2后的空格之外，CMD还在重定向前再增加了一个空格，经跟踪才注意到它是你的第二行代码中末尾多添加的那个空格。 将12楼的测试代码略作丰富和修正后，以同样的数据测试，得到代码[2]和数据[3]，据此得出结论，“3 7 2 1”与“^3 7 2 1”一致；“3 7 2 1 ”与“3 7 2 1 1”一致，这符合我最初的猜想。 [1]

00000000h: 33 20 37 20 32 20 20 0D 0A ; 3 7 2 ..

[2][3]

00000000h: 33 20 37 20 32 20 0D 0A 33 20 37 20 32 20 31 31 ; 3 7 2 ..3 7 2 11 00000010h: 0D 0A 33 20 37 20 32 20 31 20 0D 0A 33 20 37 20 ; ..3 7 2 1 ..3 7 00000020h: 32 20 31 20 0D 0A 33 20 37 20 32 20 0D 0A ; 2 1 ..3 7 2 ..

[ Last edited by willsort on 2006-4-22 at 01:03 ]

※ Batchinger 致 Bat Fans：请访问 [讨论]批处理编程的异类 ，欢迎交流与共享批处理编程心得！

很久之前有碰到过这样的问题 willsort兄有帮我解答过一次 只是当时还不大明白 现在好像明白了点

哎,echo好麻烦吖