(10分的看这里) 由于洛谷“早期数据 Bug”而导致的正确代码不能AC

在写这篇文章的时候问题仍存在，希望以后能修复 OAO

太长不看： 此题原始测试数据是在 Windows 里面写的，但是洛谷现在的评测机却用的是 Linux 系统，于是这些数据文件就被直接复制到了 Linux 里面，没有进行必要处理，然后这些 “跨平台” 文件就出现了换行符编码错误的问题，然后导致很多人明明对的却只有 10 分。所以只有 10 分的话，很可能不是你代码的问题，而是因为洛谷特色。当然，略加修改代码后依旧有办法在洛谷上面通过此题，具体怎么改看第一个题解的注释。

正文：
今天看到有一个人在群里问代码哪里错了，说自己测了没问题但是只有 10 分，然后我看了半天愣是没看出来到底哪里错了。（其实确实没问题）

然后我就来着看题解了，然后第一个题解是这么说的

我：“呃？？？怎么可能会有'\n'和'\r'的存在？我怎么记得getline(cin, s)是会自动丢弃换行符的啊……”

于是我呢又查了一下getline，权 威 网 站 cplusplus.com 上面确实说换行符什么的会被自动丢弃。啊这

然后我就不信邪，自己打了一个没有判断是不是空格的代码，和题解写得差不多，毕竟他思路和我一样，长这样

自己测了没问题，交上去同样只有 10 分，第一个数据就挂了。然后我把第一个数据下到了自己的电脑上（Windows）测了一遍，根本没有问题。

然后我就在想是不是因为洛谷评测机用的是 Linux，所以运行结果和我不一样。
于是我又放在 WSL（就是 Linux）里面测了一遍，居然也一点问题都没有，真TM奇葩死了。

然后群里一个佬巨，说可能洛谷在 Windows 里面造数据，然后复制到了 Linux 里测试就出 bug 了。然后我就模拟了一下，把 Windows 上下载下来的数据文件直接拖进 WSL 里面，然后再在 WSL 里面用这个输入数据跑了一遍程序。这下真给说中了，本来那个结果应该输出 31，这么一搞输出结果变成 32 了。

那么这个 bug 到底是怎么回事呢？

首先你得知道所谓 “换行符（LF）” 和 “回车符（CR）” 的区别，而这一切都要从一个老东西 “打字机” 讲起。所以我懒得说了，直接看这个吧 https://blog.csdn.net/lishuoboy/article/details/84768748
然后呢，Windows 保留了每一行结尾是CRLF（相当于'\r' + '\n'）两个字符的传统，但是在 Linux 里面每一行结尾就只是LF（'\n'）一个字符。

那有人就要问了，既然如此，我天天在 Windows 里面写 C++ 代码怎么根本没感受到\r的存在，只用过\n，是怎么回事。这是因为 C++ 在读入和输出时会自动帮你转换当前平台的换行符，这就是为什么你在 Windows 上，输入的CRLF会自动被 C++ 读成'\n'，然后输出的时候又神奇的变成CRLF。

现在回归主线。洛谷的离谱操作就在于，把 Windows 上写的数据文件直接不加处理地复制进了 Linux，于是每一行结尾的\r\n也被错误地保留下来了（其实应该把\r去掉）。然后虽然getline(cin, s)是会扔掉换行符的，但是在 Linux 里面\r不是换行符，于是这个莫名其妙多出来的\r被存进s里面了，最后导致你的程序答案加了一，痛失 90 分，至于为什么不是全错那我也不知道为什么(～￣▽￣)～

不过据传闻，就是一些洛谷十分老的题的数据会有这个bug，所以说你做一些新题是完全不用考虑这些'\r'什么的乱七八糟的玩意的。
我查了一下，洛谷一开始的评测机是 Windows，2015 年后开始改成 Linux 了， 所以有这个 bug 的题应该都是 2015 年或者 2015 年以前上传的题目吧。