<p>“。。。GB18030。我想这是个解决办法,因为它能通读前几个文件,并能很好地解码。”“”——请解释一下你的意思。对我来说,成功解码有两个标准:第一,原始字节。解码(“某些编码”)没有失败,第二,在特定语言中显示的结果unicode有意义。当用<code>latin1</code>即<code>iso_8859_1</code>解码时,宇宙中的每个文件都将通过第一个测试。东亚语言中的许多文件都通过了第一个<code>gb18030</code>测试,因为汉语、日语和朝鲜语中最常用的字符大多使用相同的两字节序列块进行编码。你第二次考试做了多少?</p>
<p>不要纠结于在IDE或文本编辑器中查看数据。在web浏览器中查看它;它们通常能更好地检测编码。</p>
<p>你怎么知道这是一个欧元字符?通过查看文本编辑器的屏幕,该编辑器使用什么编码来解码原始字节?cp1252?</p>
<p>你怎么知道里面有汉字?你确定不是日本人吗?韩国人?你从哪儿弄来的?</p>
<P>香港、台湾、澳门、大陆等地方的中文文件使用{{CD4>}或^ {CD5>}编码——试试看。</p>
<p>在任何情况下,接受马克的建议并指出<code>chardet</code>;<code>chardet</code>如果文件足够大并且正确编码了中文/日文/韩文,通常可以很好地检测所使用的编码—但是如果有人使用单字节字符集在文本编辑器中手动编辑文件,则一些非法字符可能会导致其他99.9%字符未检测到的编码。</p>
<p>您可能想对文件中的5行执行<code>print repr(line)</code>,并将输出编辑为您的问题。</p>
<p>如果该文件不是机密文件,您可以将其提供给下载。</p>
<p>文件是在Windows上创建的吗?你是怎么用Python阅读的?(显示代码)</p>
<p><strong>评论后更新:</strong></p>
<p>记事本等不试图猜测编码;“ANSI”是默认值。你得告诉它该怎么做。您所称的欧元字符是编辑器使用您的环境的默认编码解码的原始字节“\x80”——通常怀疑是“cp1252”。不要用这样的编辑器来编辑你的文件。</p>
<p>早些时候你说的是“最初的几个错误”。现在你说你总共有5个错误。请解释一下。</p>
<p>如果该文件确实几乎是正确的gb18030,您应该能够逐行解码该文件,当您得到这样一个错误时,捕获它,打印错误消息,从消息中提取字节偏移量,打印repr(两个坏字节),然后继续。我对<code>\x80</code>出现的两个字节中的哪一个非常感兴趣。如果它根本没有出现,“欧元字符”不是你问题的一部分。注意<code>\x80</code>可以有效地出现在gb18030文件中,但只能作为以<code>\x81</code>到<code>\xfe</code>开头的2字节序列的第2字节。</p>
<p>在你试图解决问题之前,最好先知道你的问题是什么。试图通过在“ANSI”模式下用记事本等来修复它不是一个好主意。</p>
<p>你一直很害羞,你如何决定,结果的gb18030解码有意义。特别是我会仔细检查gbk失败但gb18030“有效”的行——其中一定有一些极其罕见的汉字,或者可能有一些非中文的非ASCII字符。。。</p>
<p>这里有一个更好的方法来检查损坏:用<code>raw_bytes.decode(encoding, 'replace')</code>解码每个文件,并将结果(用utf8编码)写入另一个文件。按<code>result.count(u'\ufffd')</code>计算错误。查看输出文件,无论您用什么来确定gb18030解码是有意义的。U+FFFD字符应该显示为黑色菱形内的白色问号。</p>
<p>如果你决定不可编码的片段可以被丢弃,最简单的方法是<code>raw_bytes.decode(encoding, 'ignore')</code></p>
<p><strong>在获得更多信息后更新</strong></p>
<p>所有这些都令人困惑。似乎“获取字节”涉及<code>repr(repr(bytes))</code>,而不仅仅是<code>repr(bytes)</code>。。。在交互提示下,执行<code>bytes</code>(将得到隐式repr())或<code>print repr(bytes)</code>(将不会得到隐式repr())</p>
<p>空白处:我假设您的意思是<code>'\xf8\xf8'.decode('gb18030')</code>是您解释为某种全宽空间的内容,并且解释是通过使用一些不可测量的查看器软件进行可视化检查来完成的。是这样吗?</p>
<p>实际上,<code>'\xf8\xf8'.decode('gb18030')</code>->;<code>u'\e28b'</code>。U+E28B位于Unicode PUA(专用区域)中。“空白”可能意味着浏览器软件在使用的字体中没有U+E28B的字形。</p>
<p>也许文件的来源是故意使用PUA来处理不在标准gb18030中的字符,或者用于注释,或者用于传输伪机密信息。如果是这样的话,你就需要求助于解码手鼓,这是最近俄罗斯研究的一个分支。</p>
<p>备选方案:cp939香港特别行政区理论。根据香港政府的资料,香港特别行政区第五大类密码FE57曾映射到U+E28B,但现在已映射到U+28804。</p>
<p>“euro”:你说“”,因为我不能共享整行数据,但我所说的euro字符是在:“\xcb\xbe\x80\x80”[我假设从一开始就省略了<code>\</code>,而<code>"</code>是字面的]。当“欧元字符”出现时,它总是在我不需要的同一列中,所以我希望只使用“忽略”。不幸的是,由于“euro char”就在文件中的引号旁边,有时“ignore”会去掉euro字符和引号,这给csv模块确定列带来了问题</p>
<p>如果你能显示这些<code>\x80</code>字节相对于引号和汉字出现的位置的模式,那将有很大的帮助——通过显示十六进制保持可读,并隐藏机密数据,例如,使用C1 C2表示“两个字节,我确信这两个字节代表一个汉字”。例如:</p>
<pre><code>C1 C2 C1 C2 cb be 80 80 22 # `\x22` is the quote character
</code></pre>
<p>请提供以下示例:(1)“未被‘替换’丢失”或“忽略”(2)报价丢失。在您迄今为止的唯一示例中,“不会丢失:</p>
<pre><code>>>> '\xcb\xbe\x80\x80\x22'.decode('gb18030', 'ignore')
u'\u53f8"'
</code></pre>
<p>向您发送一些调试代码的提议(请参阅下面的示例输出)仍处于打开状态。</p>
<pre><code>>>> import decode_debug as de
>>> def logger(s):
... sys.stderr.write('*** ' + s + '\n')
...
>>> import sys
>>> de.decode_debug('\xcb\xbe\x80\x80\x22', 'gb18030', 'replace', logger)
*** input[2:5] ('\x80\x80"') doesn't start with a plausible code sequence
*** input[3:5] ('\x80"') doesn't start with a plausible code sequence
u'\u53f8\ufffd\ufffd"'
>>> de.decode_debug('\xcb\xbe\x80\x80\x22', 'gb18030', 'ignore', logger)
*** input[2:5] ('\x80\x80"') doesn't start with a plausible code sequence
*** input[3:5] ('\x80"') doesn't start with a plausible code sequence
u'\u53f8"'
>>>
</code></pre>
<p><strong>Eureka:</strong>--有时丢失引号字符的可能原因--</p>
<p>似乎在<code>gb18030</code>解码器替换/忽略机制中有一个错误:<code>\x80</code>不是有效的gb18030前置字节;当检测到它时,解码器应尝试与下一个字节重新同步。然而,它似乎忽略了<code>\x80</code>和以下字节:</p>
<pre><code>>>> '\x80abcd'.decode('gb18030', 'replace')
u'\ufffdbcd' # the 'a' is lost
>>> de.decode_debug('\x80abcd', 'gb18030', 'replace', logger)
*** input[0:4] ('\x80abc') doesn't start with a plausible code sequence
u'\ufffdabcd'
>>> '\x80\x80abcd'.decode('gb18030', 'replace')
u'\ufffdabcd' # the second '\x80' is lost
>>> de.decode_debug('\x80\x80abcd', 'gb18030', 'replace', logger)
*** input[0:4] ('\x80\x80ab') doesn't start with a plausible code sequence
*** input[1:5] ('\x80abc') doesn't start with a plausible code sequence
u'\ufffd\ufffdabcd'
>>>
</code></pre>