这是由UNIX样式的行尾引起的已记录的行为：
file.tell()返回文件的当前位置，喜欢
stdio的ftell()。注意
：在Windows上，当读取带有Unix样式的行尾的文件时，tell()可以返回非法值（在后面fgets()）。使用二进制模式（’rb’）可以避免此问题。
以上文档取自python2.7.4文档。python3的文档有所更改，因为现在有了处理I /
O的类层次结构，而我找不到这些信息。您的测试表明该行为始终没有改变。同样，python3.3的源代码在调用
XXX Windows supportbelow is likely incomplete的函数之前有一个注释
tell。
与此相关的python bug跟踪器中存在一个问题，Catalin
Iacob的最终评论是：
我试图重现此错误，在磁盘上选择了一个文件，确实得到了一个负数，但是该文件具有Unix行尾。在http://docs.python.org/2/library/stdtypes.html#file.tell中对此进行了记录，
因此，那时可能没有任何事可做。至于msg180145中Armin的报告，即使它不是很直观，也与ftell在Windows上的行为相匹配，如http://msdn.microsoft.com/zh-
cn/library/0ys3hc0b%28v=vs.100的“备注”部分所述。
％29.aspx。文件对象上的tell（）方法已明确记录为与ftell行为匹配：“返回文件的当前位置，如stdio的ftell（）”。因此，尽管它根本不直观，但最好还是保留它。tell（）在python.3和io.open上在Python
2.7上以’a’打开时返回直观的非零位置，因此无论如何它在将来都是固定的。
因此，这似乎是一个“ wontfix”错误。 某人可能应该打开一个问题 （对此 问题进行了
评论），因为在python3文档中根本没有提到这个事实。
根据Antoine Pitrou的说法，
python3根本不使用
ftell()，因此这似乎是一个不同的错误。此外，该错误在python3.2.3中不可重现，并且可能是在解决此问题时引入的（至少，这是我只能
tell()在3.2.3和3.3之间实现的唯一更改）
上次编辑：根据
io模块文档，此
tell方法自文件开头以来
不
返回字节数。返回的值是“不透明数字”，这意味着使用它的唯一方法是将其传递给
seek该位置以返回该位置。其他操作没有意义。在python3.2.3之前返回的值就是您所期望的事实，但这只是实现细节。
请注意，本文档此部分中的信息完全是 错误的 ，希望将来会得到修复。
