在0D/0A的上下文中，使用Python 3.6.9时TextIOWrapper.tell（）的奇怪行为

环境：

给定的：

存储在

test.py

中的一个小程序，显示输入位置和输入字符代码，以便连续读取单个字符

fh  = open("tmp.txt", "r")
while 1 + 1 == 2:
    tmp = fh.read(1)
    if not tmp: break
    print(fh.tell(), "%x" % ord(tmp))

在bash中填充

tmp.txt

，以包含一些数据

echo -e "\x41\x42\x3b\x0d\x0a\x0d\x0a" > tmp.txt

输出：

运行

python3 test.py

1 41
2 42
18446744073709551620 3b
5 a
7 a
8 a

问题：

fh.tell（）

的过高值

18446744073709551620

来自何处？有趣的是， 在以下情况下不会发生这种情况

echo -e "\x41\x42\x3b\x0d\x0a" > tmp.txt     # only one 0x0d/0x0a
echo -e "\x42\x3b\x0d\x0a\x0d\x0a" > tmp.txt # no 'A' at the beginning of the file

---

：“以不透明数字返回当前流位置。该数字通常不表示基础二进制存储中的字节数。”正确，尤其是在以文本模式打开文件时。然而，我们应该预期，如果在流中字母Y位于字母X之后，则该位置（Y）>位置（X）。否则，流导航就会变得一团糟。在我看来，TextIOBase.tell似乎返回了的输出（但我不是C程序员，所以请务必验证）。我不知道为什么它是这样实现的：“以不透明的数字返回当前流位置。该数字通常不表示底层二进制存储中的字节数。”正确，尤其是在以文本模式打开文件时。然而，我们应该预期，如果在流中字母Y位于字母X之后，则该位置（Y）>位置（X）。否则，流导航就会变得一团糟。在我看来，TextIOBase.tell似乎返回了的输出（但我不是C程序员，所以请务必验证）。我不知道为什么它是这样实现的。

echo -e "\x41\x42\x3b\x0d\x0a" > tmp.txt     # only one 0x0d/0x0a
echo -e "\x42\x3b\x0d\x0a\x0d\x0a" > tmp.txt # no 'A' at the beginning of the file