OSS域12_Windows和UNIX下对换行处理不一致造成的问题_new.doc

1 现象：问题描述
话单预处理程序在windows平台调试通过后，在unix平台进行编译。将windows平台下的话单文件ftp到unix测试环境，测试结果确是在windows平台测试的所有正确话单在unix平台全部提示错误，分析错误代码，发现是话单长度错误。
2 关键过程：根本原因分析
程序中对话单格式的定义如下：
typedef  struct  _STCDRField
{
    char  CallingNumber[24];      
    char  CalledNumber[24];       
    …
    char  RoamType[5];
    char  endld[2];  //回车换行符
}STCDRField;
问题就出在兰色字体标识的部分的定义上面，在windows平台，正常的文本行是由0x0D 0x0A结尾的，也就是我们通常所说的回车换行，而在unix平台，文本行仅由0x0A结尾。FTP使用ASC传输方式传输文本文件的过程中，会自动处理文件将0x0D 0x0A变成0x0A，使用BIN传输方式则保持不变，而各种FTP工具缺省传输文本文件都会使用ASC方式。
3 结论：解决方案及效果
解决方法有两个，第一个将话单文件以BIN方式重新进行传输，此时用vi打开话单文件观察，发现每条环境记录结尾都有"^M"的符号，重新处理话单问题解决；
第二个方法就是替换兰色标识程序如下：
#ifdef WIN32
    char  endld[2];  //回车换行符
#else
    char  endld[1];  //换行符
#endif
也能达到解决问题的目的。
4 经验总结：预防措施和规范建议
在跨平台处理文本文件时，要注意这个回车换行的问题。
5 备注

6 考核点
Window平台与Unix平台文本行结束符的区别。
7 试题
#include "stdio.h"
int main(int argc, char* argv[])
{
 FILE *pf;
 char szBuf[16];
 pf = fopen("test.txt","w+");
 sprintf(szBuf,"\n");
 fputs(szBuf,pf);
 fclose(pf);
 return 0;
}
如上程序，如果分别在Unix和Window分别编译运行，test.txt文件用16进制工具打开观察，如下那句结论正确（C）
A、 Unix和Window环境都是0x0D 0x0A
B、 Unix和Window环境都是0x0A
C、 Unix环境下是0x0A而Window环境都是0x0D 0x0A
D、 Unix环境下是0x0D 0x0A而Window环境都是0x0A