pythonscsv嗅探器在windows和linux中的不同行为

2020-12-04 15:44:29 发布

您现在位置:Python中文网/ 问答频道 /正文

在wxpython应用程序中,我使用以下代码检测csv文件的“方言”:

pathname = dlg.GetPath()
try:
    self.file = open(pathname, 'r', encoding='utf-8')
except IOError:
    wx.LogError("Cannot open file '%s'." % ntpath.basename(self.file.name))
    return

# check for file format with sniffer
sample = self.file.read(1024)
try:
    dialect = csv.Sniffer().sniff(sample)
except UnicodeDecodeError:
    wx.LogError("Cannot decode file '%s'." % ntpath.basename(self.file.name))
    return
except csv.Error:
    wx.LogError("Cannot determine dialect of '%s'." % ntpath.basename(self.file.name))
    return

我在上面使用的csv文件的第一行是:

^{pr2}$

分隔符应该是“;”和引号字符'”,我知道有很多逗号、分号和引号字符来迷惑嗅探器,但是在windows上用Python3.6运行这段代码时,它可以完美地工作。在Linux上运行它(同样是在Python3.6中)总是会引发csv.错误(也适用于其他具有相同分隔符和引号字符的csv文件)。我尝试过read(1024)、其他值和readline,但总是得到相同的结果。在

对这种不同的行为有什么解释吗?在

2条回答
网友
1楼 ·

默认的记录结束分隔符在windows和linux之间是不同的。通常,在windows上,记录将以一个CR-LF“对”终止,而在*nix上,通常只有一个LF。在这种情况下,您的嗅探器可能会在windows模式下自行修复,并且需要帮助来决定实际的行终止符应该是什么。在

the docs看来,sniffer默认为/r/n,我认为这是windows风格的。它应该能应付交替的线路终端,但也许有什么东西是被迫的。如果数据文件中的记录长度超过1024,或者没有足够的时间对行结束符进行足够的采样以正确猜测格式,那么这可能与此有关。在

网友
2楼 ·

终于找到了这个错误的原因。它与换行符结尾无关。我正在使用python3.6.4,并发现csv.py文件在这个版本中有一个错误:第220行的regex显示:

r'(?P<delim>>[^\w\n"\'])(?P<space> ?)(?P<quote>["\']).*?(?P=quote)(?:$|\n)',  # ,".*?"

但应该是:

^{pr2}$

从python3.6.5开始。这个错误似乎被修复了

相关问题