我有两个Perl程序,它们使用相同的库处理文档。它们安装在两个不同的服务器上,一个运行Perl 5.12,另一个运行Perl 5.18。
现在,我将相同的文件作为输入提供给两者,因此我可以比较输出以确保它们匹配。我找到了成百上千个一模一样的匹配。它们通常处理UTF-8文件,我已经注意到正确地处理这种编码。
今天他们都收到了一个二进制文件,我第一次看到了不同之处。我确定一个程序(运行Perl5.18的程序)在输出文件之前从文件内容中剥离了垂直制表符,而另一个程序没有这样做。
我可以把它写成不支持二进制文件,但它们是不同的,这仍然困扰着我。我查看了正在进行处理的库,它包含以下行(它将以这种方式处理文件中的每一行):
$line =~ s/\s//g;有没有可能其中一个Perl认为垂直制表符是空格,而另一个不是?我该怎么检查呢?你觉得我还应该调查什么?
发布于 2018-03-08 10:02:27
从5.18开始,vertical tabs are considered whitespace。
没有人记得为什么
\s不能与垂直标签\cK相匹配。现在它做到了。考虑到这个角色的极端稀缺性,预计几乎不会有什么破坏。也就是说,它的意思是:
正则表达式中的\s现在可以在所有情况下匹配垂直制表符。
使用/x修饰符时,会忽略正则表达式文本中的文本垂直制表符。
在将字符串解释为数字时,单独或与其他空格混合使用的前导垂直制表符现在将被忽略。例如:
$dec =“\cK \t 123";$hex =”\cK \t 0xF";假设0+ $dec;#之前是0,现在是123,表示int $dec;#是0,现在是123,表示oct $hex;#是0,现在是15
这使得Perl与Unicode保持一致,后者认为U+000B行制表又称垂直制表,又称VT,即White_Space字符。
您可以通过用[^\S\x0B]替换\s来恢复原来的行为。
同样值得考虑的是\h,它只匹配水平空格字符。
U+0009 CHARACTER TABULATION Matched by \s & \h
U+000A LINE FEED Matched by \s & \v
U+000B LINE TABULATION Matched by \s & \v
U+000C FORM FEED Matched by \s & \v
U+000D CARRIAGE RETURN Matched by \s & \v
U+0020 SPACE Matched by \s & \h
U+0085 NEXT LINE Matched by \s & \v
U+00A0 NO-BREAK SPACE Matched by \s & \h
U+1680 OGHAM SPACE MARK Matched by \s & \h
U+2000 EN QUAD Matched by \s & \h
U+2001 EM QUAD Matched by \s & \h
U+2002 EN SPACE Matched by \s & \h
U+2003 EM SPACE Matched by \s & \h
U+2004 THREE-PER-EM SPACE Matched by \s & \h
U+2005 FOUR-PER-EM SPACE Matched by \s & \h
U+2006 SIX-PER-EM SPACE Matched by \s & \h
U+2007 FIGURE SPACE Matched by \s & \h
U+2008 PUNCTUATION SPACE Matched by \s & \h
U+2009 THIN SPACE Matched by \s & \h
U+200A HAIR SPACE Matched by \s & \h
U+2028 LINE SEPARATOR Matched by \s & \v
U+2029 PARAGRAPH SEPARATOR Matched by \s & \v
U+202F NARROW NO-BREAK SPACE Matched by \s & \h
U+205F MEDIUM MATHEMATICAL SPACE Matched by \s & \h
U+3000 IDEOGRAPHIC SPACE Matched by \s & \hhttps://stackoverflow.com/questions/49164191
复制相似问题