Chinaunix首页 | 论坛 | 博客
  • 博客访问: 170519
  • 博文数量: 64
  • 博客积分: 13
  • 博客等级: 民兵
  • 技术积分: 345
  • 用 户 组: 普通用户
  • 注册时间: 2011-12-20 21:17
文章分类
文章存档

2012年(64)

分类:

2012-07-29 20:14:31

原文地址:回车的传说 作者:百年不亮


    如果你有在windows下编程的经验就会发现windows下敲下回车键会产生两个字符CR和LF,用16进制编辑器打开windows下的文本文件也会看到换行是0D和0A表示的,也就是CR和LF的ASCII编码。而在UNIX类系统中换行只有一个字符LF,所以UNIX中的文本文件在windows中用记事本打开会出现不可解析字符且丢失换行格式,所有字符连成一行。
    因为windows下的记事本读到LF时不知道这就是换行(只有CR和LF连续出现才能解释为换行),于是当作不可打印字符处理,就是一个黑色方框。CR和LF分别表示“回车”(carriage return)和“换行”(line feed),ASCII编码为13和10,在C语言中用\r和\n表示。

    为什么windows下要用两个字符表示换行?这就是今天要讲的故事:《回车的传说》
    在计算机刚刚诞生之时,广泛使用
Teletype公司制造的一种古老的终端(console terminal)电传打字机ASR33。ASR33每秒钟可以打10个字符。但是它有一个问题,就是打完一行换行的时候,打印头从行尾移到行首再下移一行要用去0.2秒,正好可以打两个字符。要是在这0.2秒里面,又有新的字符传过来,那么这个字符将丢失,那时可没有缓冲区暂存。Teletype的研究人员想了个办法解决这个问题,就是在每行后面加两个表示结束的字符。一个叫做“回车”,告诉打字机把打印头定位在左边界;另一个叫做“换行”,告诉打字机把纸向下移一行。这就是“换行”和“回车”的来历,从它们的英语名字上也可以看出一二。

下面是一些参考资料:
History of The Teletype Corporation


The Teletype Corporation ASR 33 Teletype (1967).


( 1968年盖茨在湖滨中学玩的就是这种机器,他们通过这种终端编写BASIC程序。因为
ASR 33只使用大写字母,所以BASIC程序以大写字母为主)

    后来,计算机的史前时代结束了,小型机诞生了,现代文明的键盘也发明了,但回车和换行的概念仍被保留下来。一些计算机设计者认为在每行结尾加两个字符太浪费也没有必要了,加一个就可以。于是就出现了分歧。
    Unix系统里使用表示换行,每行结尾只有一个换行符\n,MSDOS和Windows系统里面每行结尾是<回车><换行>(
<carriage return>)即\r\n,Apple的Mac系统里每行结尾是<回车><carriage return>即\r。一个直接后果是,Unix/Mac系统下的文件在Windows里打开的话,所有文字会变成一行;而Windows里的文件在Unix/Mac下打开的话,某些文本编辑器可能在每行的结尾会多出一个^M符号。

   本人觉得用两个字符表示换行实在有些画蛇添足,但是在网络的世界里这一现象却大量存在,不少网络协议规定报文必须使用CR-LF换行模式。
你怎么看呢?前不久在CU的论坛对这一问题进行了讨论:


这个和编程有关系吗?
有的,但是在标准C里通常情况下是体会不到的,标准C的流提供系统无关抽象层。

可以在windows系统中进行一下实验:
   
程序一:
----------------------------------------------
#include
int main(void)
{
        int i;
        FILE *fp;

        if((fp=fopen("test.txt","w")) == NULL)    
        {
                fprintf(stderr,"open file error\n");
                return 1;
        }
    

        for(i=0;i<100;i++)
                fprintf(fp,"test\n");
        
        fclose(fp);
    
        return 0;
}

程序二:
-------------------------------------------------------------------------------------
#include
int main(void)
{
        int i;
        FILE *fp;

        if((fp=fopen("test.bin","wb")) == NULL)    
        {
                fprintf(stderr,"open file error\n");
                return 1;
        }
    

        for(i=0;i<100;i++)
                fprintf(fp,"test\n");
        
        fclose(fp);
    
        return 0;
}
--------------------------------------------------------------------------------------
程序一输出文件大小是600字节,程序二输出文件大小是500字节,用记事本打开程序一的输出没有什么问题,每行一个test,打开程序二的输出发现所有的test连成一行,test之间是一个黑色方框符号分隔。用UltraEdit-32以16进制编辑模式打开test.bin可以查看到黑色方框符号就是0A也就是\n,打开test.txt则会发现换行是\r\n,这就是两个文件大小相差100字节的原因。Unix类系统用户打开windows中的文件就会遇到这种苦恼。

为什么会有这种区别呢?
    毕竟是源自Unix系统,C语言中使用\n表示换行,而在实际的文件中换行符号需要同操作系统一致,所以当我们在C中使用fopen打开一个文本文件时流实现了实际换行符与C中\n之间的转换。在windows中当我们用fopen打开文本文件,然后从中读到\r\n时流会转换为\n,而当我们往文件中写入\n时流会转换为\r\n。程序一是打开文本文件,程序二打开的是二进制文件,因为流只对文本文件进行换行表示的转换,以二进制模式打开流不会做任何处理。所以当你以二进制模式打开一个文本文件时将产生错乱,你必须亲自将\r\n解释为\n,同样的问题也会出现在以文本模式打开二进制文件的情况.这也解释了为什么Unix类系统中的文件不区分文本文件和二进制文件的原因。
 

当我们使用标准输入输出函数时有这种情况吗? 
再回到我们熟悉的标准输入输出stdin,stdout
    C的控制台程序在加载进内存成为进程运行前C运行时库自动打开三个设备并关联到三个流:标准输入流stdin,标准输出流stdout,标准出错流stderr
    通常在通用计算机中,没有重定向前这三个流对应的设备是:键盘,显示器,显示器。这三个都是字符设备,所以是以文本文件的模式打开的,在windows下当我们在键盘上敲入回车键时产生字符\r\n,但是在OS内核把键盘驱动中读到的字符发送给流的缓冲区时流会将之转换为\n,当我们向控制台输出\n时流将之转换为\r\n再传递至内核,当我们绕过标准输入输出直接调用windows中coredll.lib进行控制台输入输出时就必须面对这一现实,程序员负责实现这一转换。

   
     流stream的背后隐藏着多少不为人知的秘密?下期节目我们将走进流的内心世界,挖掘linux下开源库glibc中的标准输入输出函数到内核终端驱动的秘密,欢迎继续关注下期
的CS八卦旧闻:《流的秘密》(Deep Stream Secrets).
阅读(1451) | 评论(0) | 转发(0) |
0

上一篇:写给刚刚开始LFS的朋友们的一些建议

下一篇:没有了

给主人留下些什么吧!~~