在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选项，你可以告诉它是一个新行。