【问题标题】：Best Free Text Editor Supporting *More Than* 4GB Files? [closed]支持*超过* 4GB 文件的最佳免费文本编辑器？ [关闭]
【发布时间】：2010-09-11 07:07:16
【问题描述】：

我正在寻找能够将 4+ GB 文件加载到其中的文本编辑器。文本板不起作用。我拥有它的副本并访问过它的支持站点，它就是不这样做。也许我需要新硬件，但这是一个不同的问题。编辑器需要是免费的，或者，如果它要花费我，那么不超过 30 美元。对于 Windows。

【问题讨论】：

好的，我撤回我的答案，因为发布了更好的答案。但我很好奇——为什么你需要一次将整个 4GB+ 的文件加载到编辑器中？
我必须导入非常大的文件，它们是提供给我的，我不知道它们的内容。在与他们合作时，我需要找出文件深处的记录有什么问题。我必须加载整个文件以获取记录号 3,284,992 - 例如。 TextPad 根本无法加载。
好的，这很有道理。我可以建议（假设您处理文本文件）您可能想尝试使用 Gawk 或类似的东西来尝试找到您感兴趣的行。我的意思是您是否可以定义错误的外观并使用 Awk/Gawk 直接找到它？
@PaulTomkiel，2 TB 怎么样？
@Pacerier - 坦率地说，我没有处理过大于 5GB 的文件，所以我不知道它是否能处理 2TB。问题是4GB左右，所以会合适。

标签： editor text-editor text-files large-files

【解决方案1】：

适用于 windows、unix 还是 Mac？在 Mac 或 *nix 上，您可以使用 emacs 或 vim 的命令行或 GUI 版本。

对于 Mac：TextWrangler 可以很好地处理大文件。我对 Windows 环境不够精通，无法提供帮助。

【讨论】：

Op 已声明适用于 Windows

【解决方案2】：

Emacs 可以处理huge file sizes，您可以在 Windows 或 *nix 上使用它。

【讨论】：

我在使用 emacs 处理大文件方面的经验不是很清楚。似乎它试图将整个文件加载到内存中。是否有任何选项可以阻止 emacs 这样做？
这里也一样。它似乎无法处理 1 GB 的文件。
我同意，当文件大小 > RAM 时，emacs 不是一个可行的解决方案
我的 emacs 只是拒绝打开一个 3GB 的文本文件，因为它“太大”

【解决方案3】：

Jeff Atwood 在这里有一篇关于此的帖子：http://www.codinghorror.com/blog/archives/000229.html

他最终选择了 Edit Pad Pro，因为“根据我之前的使用历史，我认为 EditPad Pro 是最合适的：它在处理大型文本文件时速度非常快，具有同类最佳的正则表达式支持，而且它不不要假装自己是 IDE。”

【讨论】：

EditPad Pro 是一款出色的产品。我已经用它打开了几个千兆字节的文本文件。它会立即显示内容，因为 EditPad Pro 使用指针直接访问文件，并且不会做大多数编辑器似乎会做的懒惰的事情，即一次将整个文件读入内存。 EditPad Pro 的唯一问题是它只是 Windows，而且这些天我除了视频游戏之外什么都不使用 Windows。所以我使用 EditPad Pro 来编辑大文件，在轻量级的 Wine 模拟器中运行。
EditPad Pro 在不到一秒的时间内为我打开了一个 4GB 的文件
EditPad Lite（免费）运行速度惊人。在尝试了其他无效的建议（在 Win7 64 位上）之后，很高兴找到了那个。下载到editpadlite.com

【解决方案4】：

这样处理 4G 文件真的很难。我曾经处理较大的文本文件，但我从来没有将它们加载到我的编辑器中。我在以前的公司主要使用 UltraEdit，现在我使用 Notepad++，但我只会得到那些我需要编辑的部分。（大多数情况下，文件不需要编辑）。

你为什么要将这么大的文件加载到编辑器中？当我处理这些大小的文件时，我使用了 GNU Core Utils。我对这些文件执行的最常见操作是 head（获取前 250k 行等）、tail、split、sort、shuf、uniq 等。它真的很强大。

您可以使用 GNU Core Utils 做很多事情。我肯定会推荐这些，而不是新的编辑器。

【讨论】：

我不想加载整个文件，但我必须这样做。当 SSIS 告诉我记录号 1,288,982 处存在问题时，我什至无法在 TextPad 中加载文件 - 我想我会问社区他们在做什么。我什至看不到输入文件中的问题。我只知道它在那里。
如果你能得到准确的行号，你可以用核心工具来做这些。 head -n LINECOUNT + 100 originalfile.txt > temp.txt tail -n 100 temp.txt > exactarea.txt 只是一个建议。

【解决方案5】：

您使用的是什么操作系统和 CPU？如果您使用的是 32 位操作系统，则系统上的进程在物理上不能寻址超过 4GB 的内存。由于大多数文本编辑器都试图将整个文件加载到内存中，我怀疑你会找到一个能做你想做的事。它必须是一个非常漂亮的文本编辑器，可以进行核外处理，即。 e.一次加载文件的一部分。

如果您在具有 64 位 CPU 和 64 位操作系统的计算机上使用 64 位文本编辑器，您可能能够加载如此巨大的文件。而且您必须确保您的交换分区或交换文件中有足够的空间。

【讨论】：

我在 2G RAM 上有一个 32 位 (WinXP)。下载了 UltraEdit 演示，它可以工作。只是不知道我现在能不能拿到钱来支付这笔费用。如果您有 4GB 以上的交换空间并且您启动并尝试尽快加载那个巨大的文件，那么交换文件就可以工作。一旦交换文件被破坏 - 它就无法工作。
"具有 32 位内存地址的处理器可以直接访问 4 GB 的字节可寻址内存。" en.wikipedia.org/wiki/32-bit 正如我所说，这可能在 32 位系统上工作的唯一方法是编辑器一次只将文件的一部分加载到内存中。
试试 Emacs 或 VIM。它们既免费又非常复杂。其中一个可能会成功。
只是一个随机评论。 32 位窗口只会为进程分配 ~ 2gb 的“内存”。

【解决方案6】：

我也喜欢notepad++。

【讨论】：

-1 我也是，但不幸的是 Notepad++ 不能处理大文件，因此它不是对 OP 问题的良好回应

【解决方案7】：

为什么要将 4 GB 以上的文件加载到内存中？即使您找到可以做到这一点的文本编辑器，您的机器是否有 4 GB 内存？除非它有超过 4 GB 的物理内存，否则你的机器会变慢很多，并且会疯狂地交换文件。

那么你为什么想要一个 4+ GB 的文件呢？如果您想对其进行转换，或者进行搜索和替换，您最好编写一个小型快速程序来完成它。

【讨论】：

我需要能够看到阻碍我的 SSIS 导入的错误记录。
您可以创建一个快速程序，将文件的最后 20 MB 截断为另一个文件并查看它。除非您允许 SSIS 忽略一定数量的错误，否则该错误将在文件末尾附近。

【解决方案8】：

当我面对一个巨大的日志文件时，我不会尝试查看整个内容，我会使用Free File Splitter

诚然，这是一种解决方法而不是解决方案，而且有时您需要整个文件。但通常我只需要从一个较大的文件中查看几行，这似乎也是你的问题。如果没有，也许其他人会发现该实用程序很有用。

例如，如果您试图将其加载到 Excel 中以使用自动过滤器，那么可以让您查看大量文本文件的查看器并没有多大帮助。由于我们都花一天时间将问题分解成更小的部分以便能够解决它们，因此将相同的原则应用于大文件并没有让我觉得有争议。

【讨论】：

em，我使用了免费文件拆分器，虽然第一个块没问题，但所有后续块都被破坏了。
@Martin，这绝对是一种解决方法而不是解决方案。当我们查看文件时，程序本身应该拆分文件，但它不应该是用户（我们）不得不费心的细节。

【解决方案9】：

Textpad 也可以很好地打开这种大小的文件。当不得不处理 3-5gb 范围内的超大日志文件时，我已经做过很多次了。此外，使用 grep 提取有价值的行，然后查看它们的效果很好。

【讨论】：

我猜我的硬件限制了我？它只是不会打开它。 Textpad 支持论坛也证实了这一点。
非常适合我和我的 4GB SQL 转储文件。不过测试了 64 位版本 - 这似乎可用于 TextPad 7+（自 2014 年以来）。

【解决方案10】：

这个问题需要更多细节。
您只想查看文件（例如日志文件）还是编辑它？
您的内存是否大于或小于您要加载的文件的大小？
例如，TheGun，一个用汇编语言编写的非常小的文本编辑器，声称“没有有效的文件大小限制，可以加载到其中的最大大小取决于可用内存和加载速度文件。[...] 它已针对文件加载和保存进行了速度优化。"

为了抽象内存限制，我想可以使用映射内存。但是，如果您需要编辑文件，则应该使用一些巧妙的方法，例如将本地更改存储在内存中，并在保存时逐块应用它们。在某些情况下可能无效（例如大搜索/替换）。

【讨论】：

我会检查的。用 ASM 写的任何东西都值得一看！
“TheGun 没有有效的文件大小限制......它通常可以毫无问题地加载超过 10 兆字节的文件。” - 哈哈。它仍然会将整个内容加载到内存中，因此这对于编辑多 GB 文本文件没有好处。
@Rich TheGun 是一个老项目（甚至 4 年前，当我提到它时），当时 10 MB 是很多内存...... :-) 我报告说“最大大小 [ ...]由可用内存决定”，所以很清楚。它可能是一个 32 位的项目，所以无论如何它可能有一个大约 2 GB 的硬限制。设计时是科幻小说！ :-D
@PhiLho，虽然我同意你的所有观点，但它们都没有解决这样一个事实，即这是对所提问题的糟糕回答。 OP 专门要求“加载 4+ GB 的文件”，而 TheGun 无法做到这一点。您的其余答案含糊地提到了各种编程技术，但没有提供解决方案。
确实如此（这个线程的大多数答案也是如此！）。因此，我对可用内存提出了疑问。当时，我没有一台内存超过 4 GB 的计算机，所以我无法确定... :-) 老实说，当时我可能不清楚 32/64 位和内存限制...

【解决方案11】：

我不得不查看怪物（失控）日志文件（20+ GB）。我使用了hexedit FREE version，它可以处理任何大小的文件。它也是开源的。它是一个 Windows 可执行文件。

【讨论】：

目前为止我使用的大型文本文件的好、最快的程序。

【解决方案12】：

也可以考虑使用glogg，用于不同的用途：

注意事项（Simon Tewsi 在 the comments 中报告，2013 年 2 月）

一个警告 - 有两个搜索功能，Main Search 和 Quick Find。
下一个，我假设是Quick Find，至少比上一个慢一个数量级，后者很快。

【讨论】：

读取大文件的好程序；请注意，它不允许编辑。
我也检查过。我自己创建文件，它们是通过重定向 STDOUT 创建的纯 Windows ANSI 文本，所以我不确定问题出在哪里。我在 HxD 十六进制编辑器中打开了该文件，它看起来很好，并且我测试过的所有其他应用程序都可以毫无问题地找到该字符串，只有 LTV 似乎不起作用。我已经改用 glogg (glogg.bonnefon.org/description.html)，它有更多我正在寻找的功能..
过去使用过但不喜欢 LTV - 不喜欢搜索或有时在页面之间跳转的笨拙方式。这次尝试了glogg。好多了。我喜欢的三个特殊功能： 1) 工具 - 选项允许您将搜索选项设置为正则表达式或简单文本； 2) 搜索速度很快 - 300 MB 文件需要 5-10 秒； 3) 右侧边距有彩条显示每个搜索命中在文件中的位置。一个警告 - 有两个搜索功能，主要搜索和快速查找。下一个，我假设是快速查找，至少比上一个慢一个数量级，后者很快。
glogg 在加载 11GB 文件时崩溃
Glogg 1.0.0 无法打开 4GB 文件。

【解决方案13】：

我在 4G 文件上也遇到了 TextPad 问题。 Notepad++ 很好用。

【讨论】：

Notepad++ 会阻塞 4GB 文件。
我的 Notepad++ 版本只是说文件太大......甚至没有尝试

【解决方案14】：

我没有在编辑器中加载巨大的日志文件，而是使用 Unix 命令行工具（如 grep、tail、gawk 等）将有趣的部分过滤到一个小得多的文件中，然后，我打开那个。

在 Windows 上，试试Cygwin。

【讨论】：

这看起来很有趣。需要我查看大文件的工作已经完成，但是我将对此进行调查以备将来使用！ +1

【解决方案15】：

如果您只想查看一个大文件而不是编辑它，有几个免费软件程序可以一次读取一个块的文件，而不是尝试将整个文件加载到内存中。当我需要阅读大型（> 5 GB）文件时，我会使用它们。

大型文本文件查看器，来自 swiftgear http://www.swiftgear.com/ltfviewer/features.html

Team Walrus 的大文件查看器。

你必须自己找到最后一个的链接，因为作为新手，我最多只能发布一个超链接。

【讨论】：

谢谢。将保留这些以供将来参考。当时我需要在一个巨大的文件深处编辑一个坏记录。

【解决方案16】：

你试过context editor吗？它小而快。

【讨论】：

【解决方案17】：

很抱歉在这么老的帖子上发帖，但我在这里尝试了几个技巧，但没有一个对我有用。

它与文本编辑器略有不同，但我发现 Beyond Compare 可以在我的 Vista 32 位机器上处理超大 (3.6 Gig) 文件。

这是一个 Emacs、大文本文件查看器、HexEdit 和 Notepad++ 都无法使用的文件。

-埃里克

【讨论】：

【解决方案18】：

HxD -- 它是一个十六进制编辑器，但它允许就地编辑，并且不会对大文件产生干扰。

【讨论】：

但它有一个固定的列宽。我们怎样才能让它识别线条？

【解决方案19】：

Tweak 是一个十六进制编辑器，可以处理对非常大的文件的编辑，包括插入和删除。

【讨论】：

【解决方案20】：

我多次偶然发现这篇文章，因为我经常需要处理大文件 (10 Gigas+)。

在厌倦了错误和非常有限的免费软件，并且在试用期结束后不愿意支付昂贵的编辑费用（毕竟不值钱）之后，我刚刚使用了VIM for Windows，并获得了巨大的成功和满足。

它非常适合这种需求，完全可定制，具有处理文本文件时可以想到的所有功能（搜索、替换、阅读等）

我很惊讶没有人回答这个问题（除了之前的答案，但对于 MacOS）......

为了记录，我在this blog post 上偶然发现了它，它明智地建议了它。

【讨论】：

除了基于列的排序或过滤之外，每个人都能想到的功能？

【解决方案21】：

EmEditor 应该处理这个问题。作为他们的site claims：

EmEditor 现在可以通过打开一个大于 248 GB（或 21 亿行） 文件的一部分，带有新的自定义栏 - 大文件控制器。大文件控制器允许您指定起点，结束点和要打开的文件的范围。它还允许您停止打开文件并监控文件的实际大小和可用临时磁盘的大小。

虽然不是免费的..

【讨论】：

“不是免费的”如果甚至没有免费试用版，那将是一场表演。

【解决方案22】：

我发现 FAR 指挥官可以打开大文件（我尝试了 4.2 GB xml 文件）而且它不会将整个文件加载到内存中并且运行速度很快。

【讨论】：

【解决方案23】：

打开 5GB 文件（快速）：

1) 十六进制编辑器 Neo

2) 010 编辑器

【讨论】：

【解决方案24】：

尝试了几次读取 6GB mysqldump 文件后我最喜欢的：

PilotEdit Lite http://www.pilotedit.com/

因为：

内存使用量（不知何故？！）从未超过 25MB，因此对我系统的其余部分基本上没有影响 - 尽管打开需要几分钟。
在那段时间有一个准确的进度条，所以我知道它的进展情况。
打开后，简单的搜索和浏览文件都可以像记事本小文件一样工作。
它是免费的。

我尝试过的其他...

EmEditor Pro 试用版非常令人印象深刻，文件几乎立即打开，但不幸的是对于我的要求来说太贵了。

EditPad Pro 将整个 6GB 文件加载到内存中，让一切变得缓慢。

【讨论】：

如果可以的话+100。在答案中的所有其他建议中，这似乎是我最好的解决方案。非常感谢您的推荐。 30天后不是免费的。不过，我很喜欢它，可以购买它。
@JeffOrris - 只是澄清您对哪个编辑器发表评论... PilotEdit Lite 在我看来是永远免费的。你说的是 EmEditor Pro 试用版吗？
它是 PilotEditLite。我又看了看下载....它确实说免费..每当我打开它时，它说我只剩下 30 天的免费试用期了..也许只是他们的营销策略让我升级....生病报告30 天后回来看看是否仍然免费
这很奇怪——我的根本没有这么说。在帮助 -> 关于 PilotEdit... 我的显示“PilotEdit Lite 版本 8.2.0”与您的匹配吗？
相同...当我打开它时，我得到一个对话框，要求输入名称和序列号...。有 2 个按钮； “买”和“试试”。显然我一直在按“试试看”……不管怎样，我喜欢它