改动内容在这儿，没有测试过，看起来没问题。
到目前位置，市面上所有的Android设备，都存在这个这个小问题：
在Linux/Mac上执行adb命令输出什么东西时，就算是二进制输出，那么LF(0x0a)字符会被转换成CR(0x0d) + LF。Windows上更可笑，会变成CR+CR+LF。
这个很好验证:
从Android上抓一个文件下来，例如/default.prop, 看看里面应该只有LF(0x0a)，而没有CR(0x0d)的。
adb pull /default.prop local_output_file1
然后在通过adb shell cat命令输出到本地，看看文件里是不是多了好多CR(0x0d)了。
adb shell cat /default.prop > local_output_file2
这个不是简单的因为Windows OS的缘故，Linux也出毛病。
解决方法一大堆，例如上述的pull，或者通过socket输出到PC。
其实还有方法可以完全不需要转换，也不需要pull,socket什么的。首先总结原因是两个：
-
Android那边首先做了LF->CR+LF的转换。具体的在代码里有，adbd用了pty这东西来做输入输出。很古老的东西，没什么兴趣说，。
-
Windows OS这边的adb工具更额外做了一层LF->CR+LF的转换。这个到是Windows的默认风格。
解决方法有两个步骤(Linux/Mac只要第一个步骤就行了)
1. 在android那边设定stty -onlcr来禁止发自android那边的转换。
这个也有两个方法，一个是借助于外部工具stty(从busybox里来的)，那么
预先把工具放到android里：
adb push busybox /data/local/tmp/adb shell chmod 755 /data/local/tmp/busybox
然后，那就是在执行自己的命令之前执行busybox stt -onlcr。例如
adb shell '/data/local/tmp/busybox stty -onlcr; cat /default.prop' > local_output_file2
还有一种方法就是自己的C代码里，执行这一段：
#includeif (isatty(STDOUT_FILENO)) { struct termios term; tcgetattr(STDOUT_FILENO, &term); cfmakeraw(&term); tcsetattr(STDOUT_FILENO, TCSANOW, &term);}
2. Windows这边才需要这个步骤。那就是不直接使用adb工具了，而是直接和adb工具所服务的5037端口打交道，发送命令，取得结果，这个具体的说起来有点啰嗦，如果是nodejs，那么用好了，其他的我没多看，大致就是
1. 向localhost:5037 发送host:transport:设备序列号 得到回答，如果是OKAY四个字那就到step2，否则就错误。 2. 继续向上述port发送shell:命令内容 得到回答，如果是OKAY四个字那就到step2，否则就错误。 然后从这个连接里能够读到原始的输出。