为什么文件含有的字符数多了一?

为什么文件含有的字符数多了一?

在阅读《The C Programming Language》(2nd Edition)(俗称K&R)时,动手实现了书中的部分示例代码,结果出现了一个问题,在Stackoverflow上进行了问询才得到了解决,由于原题是英文,故翻译成博文与大家分享。

原文链接:Why does the file created using a text editor contain one byte more than expected?

问题描述:

Vim中创建一个文件如下:

a v

bb

e

并且在创建文件的末尾一行时,输入e之后,没有按回车键。

那么分析一下这个文件应该含有那些字符呢?

第一行应该有这样四个字符:'a',' ','v','\n'

第二行应该有这样三个字符:'b','b','\n'

第三行应该有一个字符:'e'

注意我们分析的依据是:创建文件的末尾一行时,输入e之后,没有按回车键。 故没有\n' 字符在最后一行结尾。那么现在文件中应该一共有8个字符,我们使用K&R中的计数字符数量的示例代码进行计数:

#include<stdio.h>

/* count characters in input; 1st version */
int main()
{
    long nc;

    nc = 0;
    while (getchar() != EOF) {
        ++nc;
    }
    printf("%ld\n", nc);

    return 0;
}

结果是9。

甚至我们可以使用bash命令wc 来进行计数,最后的结果还是9.

为什么呢?

解答:

在计算机科学的传统中,我们倾向于让文件中的每一行都以一个'\n' 字符结尾,也因此,许多流行的,常用的文本编辑器,如Vim, Gvim, Nano, Gedit都会自动在文件结尾加入一个'\n' 字符,无论文件的最后是不是'\n'字符。这也就解释了为什么字符数量是9.因为Vim自动增加了一个'\n'字符。

想要真正的可视化一个文件中的所有字符,我们可以在Linux下使用hexdump -C命令,如下

$ hexdump -C test
00000000  61 20 76 0a 62 62 0a 65  0a                       |a v.bb.e.|
00000009
延伸阅读

这个网站是解释为什么我们倾向于让文件每行以'\n'字符结尾

接下来就是知道如何使得文中提到的编辑器不再自动再文件尾增加换行符

这两篇文章都是英文,由于时间原因,未能翻译,见谅!

本文中的翻译,如果各位觉得有问题,可以评论,谢谢!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值