<p>让我们仔细检查错误消息:</p>
<p>“UnicodeDecodeError:'utf8'编码解码器无法解码位置8-13中的字节:不支持的Unicode代码范围”</p>
<p>请注意,上面写着“位置8-13的字节”--这是一个<strong>6字节的UTF-8序列。这在黑暗时代可能是有效的,但是由于Unicode被冻结在21位,最大值是4字节。UTF-8验证和错误报告<a href="http://bugs.python.org/issue8271">were tightened up recently</a>;有趣的是,您运行的究竟是哪一版本的Python?</p>
<p>至少有了2.7.1和2.6.6,这个错误就变得更有用了。。。无法解码位置8中的字节XXXX:无效起始字节“,其中,如果旧消息建议使用6字节序列,则XXXX只能是0xfc或0xfd。在ISO-8859-1或cp1252中,0xfc表示带分音符的U+00FC拉丁文小写字母U(又名U-umlaut,可能是嫌疑人);0xfd表示带锐音符的U+00FD拉丁文小写字母Y(可能不是)。</p>
<p>问题不在于源文件中的<code>if line.startswith(u"Fußnote"):</code>语句。如果不是正确的UTF-8,那么在编译时就会收到一条消息,并且该消息将以“SyntaxError”开头,而不是“UnicodeDecodeError”。无论如何,该字符串的UTF-8编码只有8个字节长,而不是14个字节长。</p>
<p>问题在于(正如@Mark Tolonen所指出的那样)无论“行”指的是什么。它只能是str对象。</p>
<p>为了更进一步,你需要回答马克的问题(1)改变<code>print repr(line)</code>(2)<code>site.py</code>的结果。</p>
<p>在这个阶段,清除混合<code>str</code>和<code>unicode</code>对象的空气是个好主意(在许多操作中,不仅仅是<code>a.startswith(b)</code>)。</p>
<p><em>除非定义操作以生成<code>str</code>对象,否则它不会强制<code>unicode</code>对象成为<code>str</code>。</em>这不是<code>a.startswith(b)</code>的情况。它将尝试使用默认(通常是“ascii”)编码解码<code>str</code>对象。</p>
<p>示例:</p>
<pre><code>>>> "\xff".startswith(u"\xab")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)
>>> u"\xff".startswith("\xab")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xab in position 0: ordinal not in range(128)
</code></pre>
<p>此外,<em>说“Mix and you get UnicodeDecodeError”是不正确的。</em>很有可能<code>str</code>对象以默认编码(通常为“ascii”)进行有效编码——不会引发异常。</p>
<p>示例:</p>
<pre><code>>>> "abc".startswith(u"\xff")
False
>>> u"\xff".startswith("abc")
False
>>>
</code></pre>