从 PlaintextCorpusReader 获取句子时出现 NLTK AssertionError答案

【问题标题】：NLTK AssertionError when taking sentences from PlaintextCorpusReader从 PlaintextCorpusReader 获取句子时出现 NLTK AssertionError
【发布时间】：2016-10-10 04:31:39
【问题描述】：

我正在使用 PlaintextCorpusReader 来处理来自 Project Gutenberg 的一些文件。它似乎可以毫无问题地处理单词标记化，但是当我请求句子或段落时会窒息。

我首先将a Gutenberg book (in UTF-8 plaintext) 下载到当前目录。那么：

>>> from nltk.corpus import PlaintextCorpusReader
>>> r = PlaintextCorpusReader('.','Dracula.txt')
>>> r.words()
['DRACULA', 'CHAPTER', 'I', 'JONATHAN', 'HARKER', "'", ...]
>>> r.sents()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.5/dist-packages/nltk/util.py", line 765, in __repr__
    for elt in self:
  File "/usr/local/lib/python3.5/dist-packages/nltk/corpus/reader/util.py", line 296, in iterate_from
    new_filepos = self._stream.tell()
  File "/usr/local/lib/python3.5/dist-packages/nltk/data.py", line 1333, in tell
    assert check1.startswith(check2) or check2.startswith(check1)
AssertionError

我尝试过以各种方式修改这本书：去掉标题、删除换行符、在末尾添加句点以完成最后一个“句子”。错误仍然存在。难道我做错了什么？还是我遇到了 NLTK 的一些限制？

（在 Ubuntu 上运行 Python 3.5.0、NLTK 3.2.1。问题也出现在其他 Python 3.x 版本中。）

编辑：自省在异常点显示以下本地人。

>>> pprint.pprint(inspect.trace()[-1][0].f_locals)
{'buf_size': 63,
 'bytes_read': 75,
 'check1': "\n\n\n CHAPTER I\n\nJONATHAN HARKER'S JOURNAL\n\n(_Kept i",
 'check2': '\n'
           '\n'
           ' CHAPTER I\n'
           '\n'
           "JONATHAN HARKER'S JOURNAL\n"
           '\n'
           '(_Kept in shorthand._)',
 'est_bytes': 9,
 'filepos': 11,
 'orig_filepos': 75,
 'self': <nltk.data.SeekableUnicodeStreamReader object at 0x7fd2694b90f0>}

换句话说，check1 不知何故丢失了一个初始换行符。

【问题讨论】：

不知道可能是什么问题，所以尝试一些方法来缩小范围：(a) 与您的脚本在同一文件夹中是否有文件Dracula.txt？ (b) r.raw() 有效吗？ (c) 尝试加载包含在 nltk 中的古腾堡语料库子集，如下所示：nltk.download("gutenberg"); nltk.corpus.gutenberg.words()。发生什么了？ (d) 如果上述所有方法都有效，并且您可以访问 3.5 以外的 Python 版本，请尝试一下。
(a) 文件确实存在。 (b) 确实如此。 (c) 内置语料库完美运行。 (d) 3.4 和 3.3 出现同样的问题；我没有任何其他版本的工作 NLTK。我最好的猜测是那个文件有问题，但我不知道是什么。

标签： python nlp nltk

【解决方案1】：

该特定文件的开头有一个 UTF-8 字节顺序标记 (EF BB BF)，这让 NLTK 感到困惑。手动删除这些字节，或者将整个文本复制粘贴到一个新文件中，可以解决问题。

我不确定为什么 NLTK 不能处理 BOM，但至少有一个解决方案。

【讨论】：

很酷，你找到了它。我怀疑这有什么好处，但是根据 Unicode 标准，UTF-8 文件不应该有 BOM——这不是必需的。但是 Windows 喜欢在任何地方添加它，所以我很惊讶它如此容易地绊倒 NLTK。让我们希望有一个错误报告...

【解决方案2】：

在编码中使用“utf-8-sig”而不是默认的“utf8”...

【讨论】：