为什么 wc -w 和 Python 的 len(text.split()) 给出不同的结果？答案

【问题标题】：Why do wc -w and Python's len(text.split()) give a different result?为什么 wc -w 和 Python 的 len(text.split()) 给出不同的结果？
【发布时间】：2019-07-29 17:57:14
【问题描述】：

在什么情况下 Unix 命令行实用程序 'wc' 和 Python 的 len(text.split()) 会给出不同的结果？

一点上下文，虽然它不应该是相关的，因为我们在这里做的唯一事情就是计算单词/标记（即用空格分隔的字符集）。我正在处理 IWSLT 2014 语料库的德语文件，并且已经使用 script 对它们进行了标记（即标点符号应该已经标记化等）。对于测试和验证集，wc 和 Python 给出相同数量的单词（分别为 125754 个单词和 140433 个单词）。对于训练集，他们没有。使用 Python 3，我得到以下结果：

python3 $ text = open('train.de','r').read()
python3 $ len(text.split())
3100720

使用 wc 实用程序时：

$ wc -w train.de 
3100699 train.de

请注意，差异非常细微，但足以引起问题。大约 310 万字的文本中只有 21 个字的差异。

会发生什么？我已经检查了这两个文档，两个功能应该是等效的。

提前致谢。

编辑：关于我的本地环境的附加信息。带有区域设置的 Ubuntu 16.04 提供以下输出：

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=es_ES.UTF-8
LC_TIME=es_ES.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=es_ES.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=es_ES.UTF-8
LC_NAME=es_ES.UTF-8
LC_ADDRESS=es_ES.UTF-8
LC_TELEPHONE=es_ES.UTF-8
LC_MEASUREMENT=es_ES.UTF-8
LC_IDENTIFICATION=es_ES.UTF-8
LC_ALL=

【问题讨论】：

wc 结果可能取决于您的语言环境变量。
如果您想追踪结果不同的特定行，这种情况下二等分算法会非常方便。将文件分成两半；这两个部分中至少有一个仍然有增量；选择其中一个，再次拆分，重复直到有一行。
我使用的是默认设置的 Ubuntu 16.04。我应该提供哪些附加信息？谢谢。
我想知道您是否需要LC_ALL=de_DE.UTF-8 之类的。如果您采用二等分路线来隔离两个来源不同的某些特定行，则会更容易；提供该内容意味着我们可以自己重现问题并测试建议的修复。
按照@CharlesDuffy 和@ffejrekaburb 的建议，我将尝试对文本进行切片。

标签： python split tokenize wc

【解决方案1】：

不确定是否是您的情况，但它可能对某人有用。在我使用 python 3.6 的系统上，split() 在不间断空间 (\xa0) 上分割，而wc -w 没有。

【讨论】：