blocks|key|1096731|text|当您使用*nix时，您也可以使用split来获取较小的文件，然后用您喜欢的方式解析它，无论是grep、awk、.|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|entityMap^0|G|5^^$0|@$1|2|3|4|5|6|7|G|8|@$9|H|A|I|B|C]]|D|@]|E|$]]]|F|$]]

When you use *nix, you could also use <code>split</code> to get smaller files and then parse it with whatever you like, be it grep, awk, ...

blocks|key|1096920|text|如果安装了powershell，则可以使用|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1096921|select-string+-pattern+<your_string>+-path+<path_to_file>|offset|length|style|CODE|1096922|它可能不会很快，但不会像find那样窒息，或者findstr可能会。|entityMap^0|0|0|1L|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@$D|M|E|N|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|O|8|@]|9|@]|A|$]]]|J|$]]

If you have powershell installed you could use 

<code>select-string -pattern &lt;your_string&gt; -path &lt;path_to_file&gt;</code>

It probably won't be fast, but won't choke like find or findstr probably will.

blocks|key|1096658|text|使用grep。不会很快的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Use grep. Nothing will be any fast.

blocks|key|5195971|text|不是免费的，但是如果这是一个文本文件，那么BareTailPro可能会完成这项工作。我使用它来搜索日志文件中的文本，因为日志文件太大，无法在内存中使用。一个优点是它不只是显示文本，而且允许您跳入文本文件，这样您就可以在点击之前和之后看到行。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|entityMap|0|LINK|mutability|MUTABLE|url|http://www.baremetalsoft.com/baretailpro/index.php^0|L|B|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@$A|L|B|M|1|N]]|C|$]]]|D|$E|$5|F|G|H|C|$I|J]]]]

Not free, but if this is a text file, then <a href="http://www.baremetalsoft.com/baretailpro/index.php" rel="nofollow noreferrer">BareTailPro </a> might do the job. I have used it to search for text in logfiles which were too large to fit in memory. One advantage is that it does not just show the text, but allows you to jump into the text file, so you can see the lines before and after the hits.

blocks|key|1096678|text|如果您经常这样做，并且文件被分解成逻辑行，您可以将它加载到Splunk中，然后从那里进行搜索。它会给你做索引，让你很快(呃)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

If you do it often enough, and the file is broken into logical lines, you could load it into Splunk and search from there. It'll do indexing for you to be quick(er).

blocks|key|1096709|text|我会在*nix上使用grep，在Windows上使用高级文本编辑器(例如Notepad%2B%2B)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

I'd use grep on *nix, and I'd use a higher end text editor (e.g Notepad++) on Windows.

blocks|key|1096841|text|这取决于应用程序、所需的响应时间以及您愿意做什么来实现这些目标。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1096842|最近，我正在处理一个10%2B+GB，50%2B百万行文本文件，并且需要在每一行中搜索特定的字符串。标准的Unix工具"grep“做到了这一点，但花费了令人无法接受的长时间(多分钟)。我将文本导入postgreslq+(它是一个CSV文件，很容易导入)，一旦在需要搜索的键上进行索引，就需要不到1秒才能找到我的记录。|1096843|当然，我的工作站是单核的，只有4GB内存，一个有4年历史的2+drives，以及一个使用5%2B年老用户PATA驱动器的顶级文件系统(ZFS)。你的里程肯定会有所不同。尽管如此，这两种方法之间的时间差还是惊人的。|1096844|如果您的数据是自由格式的文本，您仍然可以考虑将其导入到支持全文搜索的DB中，并适当地进行索引以支持此类搜索。|1096845|即使您拥有整个文件被缓存的RAM和一台快速机器，对这个大小的文件进行线性搜索也会导致时间效率低下，这取决于应用程序。|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|M|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|N|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|O|8|@]|9|@]|A|$]]]|J|$]]

It depends on the application, the response time needed, and what you're willing to do to meet those goals.

Recently, I was working with a 10+ GB, 50+ million line text file and had a need to search for specific strings in each line. Standard Unix tool "grep" did the trick, but took an unacceptably long time (multiple minutes). I imported the text into a postgreslq DB (it was a CSV file, easily imported), and once indexed on the key I needed to search on, it took under 1 second to find my record.

Granted, my workstation is single-core, with only 4GB RAM, a 4-year-old 2GHz CPU, and a top-heavy filesystem (ZFS) using 5+ year-old consumer PATA drives. Your mileage will certainly vary. Still, the time difference between the two methods is staggering.

If your data is free-form text, you might still consider importing into a DB which supports full-text search and indexes appropriately to support such searches.

Even if you have the RAM to have the entire file cached and a fast machine, doing a linear search of files this size will be time inefficient, depending (once again) on the application.

blocks|key|5196105|text|在Windows提示符下，有两个命令FIND和FINDSTR。它们可能会被这样大小的文件阻塞，或者非常慢，但是您已经有了它们。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|5196106|输入help+findstr和help+find以获取文档。|entityMap^0|I|4|N|7|0|2|C|F|9^^$0|@$1|2|3|4|5|6|7|I|8|@$9|J|A|K|B|C]|$9|L|A|M|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|N|8|@$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]]|H|$]]

At the Windows CMD prompt, there are two commands <code>FIND</code> and <code>FINDSTR</code>. They will probably choke on a file that size or be very slow, but you already have them.

Type <code>help findstr</code> and <code>help find</code> for documentation.

I'm looking for a tool to find a line containing a searced text inside a file that has a size of 4 GB

Tool to search text in big files

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我正在寻找一个工具，可以在一个大小为4GB的文件中找到一个包含搜索文本的行

问在大文件中搜索文本的工具
EN

回答 8

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在大文件中搜索文本的工具EN

回答 8

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问在大文件中搜索文本的工具
EN