他们用什么来生成那个文件?在
他们正在使用一些JavaExcelAPI(见下文,link here),可能在IBM大型机或类似的主机上使用。在
从堆栈跟踪中,writeaccess信息无法解码为Unicode,因为@字符。在
有关XLS文件格式的写访问信息的详细信息,请参见5.112 WRITEACCESS或Page 277。在
此字段包含保存文件的用户的用户名。在import xlrd
dump = xlrd.dump('thefile.xls')
跑步xlrd.转储在原始文件上
^{pr2}$
在用Excel或LibreOffice Calc重新保存后,写访问信息会被如下内容覆盖36: 005c WRITEACCESS len = 0070 (112)
40: 04 00 00 43 61 6c 63 20 20 20 20 20 20 20 20 20 ?~~Calc
56: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
72: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
88: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
104: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
120: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
136: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
基于被编码为40的空格,我认为编码是EBCDIC,当我们将d1 81 a5 81 40 c5 a7 83 85 93 40 c1 d7 c9 40 40转换为EBCDIC时,我们得到Java Excel API。在
所以是的,在bif8和更高版本的情况下,文件是以有缺陷的方式编写的,它应该是unicode字符串,而在BIFF3到BIFF5中,它应该是代码页信息中编码的字节字符串152: 0042 CODEPAGE len = 0002 (2)
156: 12 52 ?R
1252是Windows CP-1252(拉丁语I)(BIFF4-BIFF5),它不是EBCDIC_037。在
xlrd试图使用unicode,这意味着它将文件的版本确定为BIFF8。在
在这种情况下,您有两个选择在用xlrd打开文件之前修复它。您可以使用dump来检查一个非标准输出的文件,如果是这样,您可以用覆盖writeaccess信息xlutils.save.保存或者另一个图书馆。
修补程序xlrd以处理您的特殊情况,在handle_writeaccess中添加一个try块,并在unpack\unicode失败时将strg设置为空字符串。
下面的片段def handle_writeaccess(self, data):
DEBUG = 0
if self.biff_version < 80:
if not self.encoding:
self.raw_user_name = True
self.user_name = data
return
strg = unpack_string(data, 0, self.encoding, lenlen=1)
else:
try:
strg = unpack_unicode(data, 0, lenlen=2)
except:
strg = ""
if DEBUG: fprintf(self.logfile, "WRITEACCESS: %d bytes; raw=%s %r\n", len(data), self.raw_user_name, strg)
strg = strg.rstrip()
self.user_name = strg
与workbook=xlrd.open_workbook('thefile.xls',encoding_override="cp1252")
似乎已成功打开文件。在
如果没有编码覆盖,它会抱怨ERROR *** codepage 21010 -> encoding 'unknown_codepage_21010' -> LookupError: unknown encoding: unknown_codepage_21010