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

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

在阅读《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' 字符在最后一行结尾。那么现在文件中应该一共有８个字符，我们使用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;
}

结果是９。

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

为什么呢？

解答：

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

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

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

延伸阅读

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

• Why should text files end with a newline?

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

• How to stop Gedit, Gvim, Vim, Nano from adding End-of-File newline char?

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

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