在C ++中,我们有一个方法来search文件中的文本。 它通过读取文件到一个variables,并使用strstr。 但是当文件变得很大的时候我们遇到了麻烦。
我想我可以通过使用_popen调用find.exe来解决这个问题。 它的作品发现,除非这些条件都是真实的:
要重新创build,你可以这样做:
我也试过这个:
这是一个错误,还是有什么我失踪?
非常有趣的错误。
这个问题让我在XP和Win 7上做了一些实验 – 行为是不一样的。
XP
ANSI – FIND无法读取单行上的1023个字符(1023个字节)。 只要搜索字符串在1024之前匹配,FIND就可以匹配超过1023个字符的行。 匹配行打印输出在1023个字符后被截断。
Unicode – FIND无法在一行中读取超过1024个字符(2048字节)。 只要搜索字符串在1025之前匹配,FIND就可以匹配超过1024个字符的行。 匹配行打印输出在1024个字符后被截断。
我觉得非常奇怪的是,在XP上的Unicode和ANSI的行限制不是相同的字节数,也不是一个简单的倍数。 以字节表示的Unicode限制是ANSI加1的限制的2倍。
注意:截短匹配的长行也会截断换行符,因此下一个匹配行将显示为附加到上一行。 如果你使用/ N选项,你可以告诉它是一个新行。
窗口7
ANSI – 我没有发现可以搜索的最大行长度的限制,(尽管我没有很努力地尝试)。 超过4095个字符(4095个字节)的任何匹配行被截断4095个字符后。 FIND可以成功搜索一行上的4095个字符,但不能全部显示。
Unicode – 我没有发现可以搜索的最大行长度的限制,(尽管我没有很努力地尝试)。 任何超过2047个字符(4094个字节)的匹配行在2047个字符后被截断。 FIND可以成功搜索过去的2047个字符,只是不能显示全部。
由于Unicode字节长度总是2的倍数,并且ANSI可显示长度的最大值是奇数,所以Unicode的最大可显示行长度比ANSI小1倍。
但是,那么也有怪异的Unicode错误。 如果Unicode文件长度是4096字节的精确倍数,则不能搜索或打印最后一个字符。 如果文件包含单行或多行,则无关紧要。 它只取决于文件的总长度。
我觉得有趣的是,4096错误的倍数在最大可打印行长度之内(以字节为单位)。 但是我不知道这些行为之间是否存在关系,或者只是巧合。
注意:匹配长行的截断也会截断任何换行符,因此下一个匹配行将显示为被追加到前一行。 如果你使用/ N选项,你可以告诉它是一个新行。