支持*超过* 4GB 文件的最佳免费文本编辑器？
我正在寻找一个能够加载 4+ GB 文件的文本编辑器。 文本板不起作用。 我拥有它的副本并访问过它的支持网站，但它就是不这样做。 也许我需要新硬件，但这是另一个问题。 编辑器需要是免费的，或者，如果要花我的钱，那么不超过 30 美元。 对于Windows。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（24）
如果您只想查看大文件而不是编辑它，有一些免费软件程序可以一次读取文件的一部分，而不是尝试将整个文件加载到内存中。 当我需要阅读大型（> 5 GB）文件时，我会使用它们。
swiftgear 的大型文本文件查看器 http://www.swiftgear.com/ltfviewer/features.html< /a>
Team Walrus 的大文件查看器。
您必须自己找到最后一个链接，因为作为新手，我最多只能发布一个超链接。
f you just want to view a large file rather than edit it, there are a couple of freeware programs that read files a chunk at a time rather than trying to load the entire file in to memory. I use these when I need to read through large ( > 5 GB) files.
Large Text File Viewer by swiftgear http://www.swiftgear.com/ltfviewer/features.html
Big File Viewer by Team Walrus.
You'll have to find the link yourself for that last one because the I can only post a maximum of one hyperlink being a newbie.
HxD——它是一个十六进制编辑器，但它允许就地编辑，并且不会在大文件上崩溃。
HxD -- it's a hexeditor, but it allows in place edits, and doesn't barf on large files.
Tweak 是一个十六进制编辑器，可以处理对非常大的文件的编辑，包括插入和删除。
Tweak is a hex editor which can handle edits to very large files, including inserts and deletes.
EmEditor 应该处理这个问题。 正如他们的网站声明：
虽然不是免费的..
EmEditor should handle this. As their site claims:
Not free though..
我发现 FAR Commander 可以打开大文件（我尝试了 4.2 GB xml 文件）
而且它不会将整个文件加载到内存中并且运行速度很快。
I found that FAR commander could open large files ( I tried 4.2 GB xml file)
And it does not load the entire file in memory and works fast.
使用以下命令（快速）打开 5GB 文件：
1) 十六进制编辑器 Neo
2) 010编辑器
Opened 5GB file (quickly) with:
1) Hex Editor Neo
2) 010 editor
文本板也可以很好地打开这种大小的文件。 当我不得不处理 3-5GB 范围内的极大日志文件时，我已经这样做过很多次了。 另外，使用 grep 取出有价值的行，然后查看这些行，效果很好。
Textpad also works well at opening files that size. I have done it many times when having to deal with extremely large log files in the 3-5gb range. Also, using grep to pull out the worthwhile lines and then look at those works great.
这个问题需要更多细节。
您只想查看文件（例如日志文件）还是编辑它？
您的内存是否大于或小于要加载的文件的大小？
例如，TheGun，一个用汇编语言编写的非常小的文本编辑器，声称“没有有效的文件大小限制，可以加载的最大大小由可用内存和文件的加载速度决定。[...]它已针对文件加载和加载速度进行了速度优化保存。”
为了抽象内存限制，我想可以使用映射内存。 但是，如果您需要编辑文件，则应该使用一些巧妙的方法，例如将本地更改存储在内存中，并在保存时逐块应用它们。 在某些情况下可能无效（例如大搜索/替换）。
The question would need more details.
Do you want just to look at a file (eg. a log file) or to edit it?
Do you have more memory than the size of the file you want to load or less?
For example, TheGun, a very small text editor written in assembly language, claims to "not have an effective file size limit and the maximum size that can be loaded into it is determined by available memory and loading speed of the file. [...] It has been speed optimised for both file load and save."
To abstract the memory limit, I suppose one can use mapped memory. But then, if you need to edit the file, some clever method should be used, like storing in memory the local changes, and applying them chunk by chunk when saving. Might be ineffective in some cases (big search/replace for example).
我在使用 TextPad 处理 4G 文件时也遇到过问题。 Notepad++ 运行良好。
I have had problems with TextPad on 4G files too. Notepad++ works nicely.
当我面对巨大的日志文件时，我不会尝试查看整个文件，我使用 免费文件分割器
诚然，这是一种解决方法而不是解决方案，有时您需要整个文件。 但通常我只需要查看较大文件中的几行，这似乎也是您的问题。 如果没有，也许其他人会发现该实用程序很有用。
例如，如果您尝试将文本文件加载到 Excel 中以使用自动筛选功能，那么可让您查看大量文本文件的查看器并没有多大帮助。 由于我们都花一天的时间将问题分解为更小的部分以便能够解决它们，因此将相同的原则应用于大文件并没有让我觉得有争议。
When I'm faced with an enormous log file, I don't try to look at the whole thing, I use Free File Splitter
Admittedly this is a workaround rather than a solution, and there are times when you would need the whole file. But often I only need to see a few lines from a larger file and that seems to be your problem too. If not, maybe others would find that utility useful.
A viewer that lets you see enormous text files isn't much help if you are trying to get it loaded into Excel to use the Autofilter, for example. Since we all spend the day breaking down problems into smaller parts to be able to solve them, applying the same principle to a large file didn't strike me as contentious.
Emacs 可以处理 巨大的文件大小，您可以在 Windows 或 *nix 上使用它。
Emacs can handle huge file sizes and you can use it on Windows or *nix.
您使用什么操作系统和CPU？ 如果您使用 32 位操作系统，则系统上的进程在物理上无法寻址超过 4GB 的内存。 由于大多数文本编辑器都会尝试将整个文件加载到内存中，因此我怀疑您是否会找到一个能够满足您需求的编辑器。 它必须是一个非常奇特的文本编辑器，可以进行核外处理，即一次加载文件的一部分。
如果您在具有 64 位 CPU 和 64 位操作系统的计算机上使用 64 位文本编辑器，您也许能够加载如此大的文件。 并且您必须确保交换分区或交换文件中有足够的空间。
What OS and CPU are you using? If you are using a 32-bit OS, then a process on your system physically cannot address more than 4GB of memory. Since most text editors try to load the entire file into memory, I doubt you'll find one that will do what you want. It would have to be a very fancy text editor, that can do out-of-core processing, i. e. load a chunk of the file at a time.
You may be able to load such a huge file with if you use a 64-bit text editor on a computer with a 64-bit CPU and a 64-bit operating system. And you have to make sure that you have enough space in your swap partition or your swap file.
为什么要将 4+ GB 的文件加载到内存中？ 即使您找到可以做到这一点的文本编辑器，您的机器有 4 GB 内存吗？ 除非物理内存超过 4 GB，否则您的机器速度会大幅减慢，并且交换文件会变得疯狂。
那么为什么需要 4 GB 以上的文件呢？ 如果您想转换它，或者进行搜索和替换，您最好编写一个小型快速程序来完成它。
Why do you want to load a 4+ GB file into memory? Even if you find a text editor that can do that, does your machine have 4 GB of memory? And unless it has a lot more than 4 GB in physical memory, your machine will slow down a lot and go swap file crazy.
So why do you want a 4+ GB file? If you want to transform it, or do a search and replace, you may be better off writing a small quick program to do it.
我也喜欢 notepad++。
I also like notepad++.
也可以考虑 glogg，用于不同的用法：
警告（由 Simon Tewsi 在 评论，2013 年 2 月）
glogg could also be considered, for a different usage:
Caveat (reported by Simon Tewsi in the comments, Feb. 2013)
我不得不查看怪物（失控）日志文件（20+ GB）。 我使用了 hexedit 免费版本，它可以处理任何大小的文件。 它也是开源的。 它是一个 Windows 可执行文件。
I've had to look at monster(runaway) log files (20+ GB). I used hexedit FREE version which can work with any size files. It is also open source. It is a Windows executable.
杰夫·阿特伍德（Jeff Atwood）在这里发表了一篇关于此问题的文章：http://www.codinghorror.com/blog/ archives/000229.html
他最终选择了 Edit Pad Pro，因为“根据我之前的使用历史，我觉得 EditPad Pro 是最合适的：它处理大型文本文件的速度相当快，具有同类最佳的优点正则表达式支持，并且它不会假装是一个 IDE。”
Jeff Atwood has a post on this here: http://www.codinghorror.com/blog/archives/000229.html
He eventually went with Edit Pad Pro, because "Based on my prior usage history, I felt that EditPad Pro was the best fit: it's quite fast on large text files, has best-of-breed regex support, and it doesn't pretend to be an IDE."
我没有在编辑器中加载巨大的日志文件，而是使用 Unix 命令行工具（例如
grep、tail、gawk等）来将有趣的部分过滤到一个更小的文件中，然后打开它。在 Windows 上，请尝试 Cygwin。
Instead of loading a gigantic log file in an editor, I'm using Unix command line tools like
grep,tail,gawk, etc. to filter the interesting parts into a much smaller file and then, I open that.On Windows, try Cygwin.
您是否尝试过上下文编辑器？ 它体积小，速度快。
Have you tried context editor? It is small and fast.
我多次偶然发现这篇文章，因为我经常需要处理巨大的文件（10 GB+）。
在厌倦了有缺陷和相当有限的免费软件，并且不愿意在试用期结束后向昂贵的编辑人员付费（毕竟不值钱）之后，我只是使用 VIM for Windows 取得了巨大的成功和满意。
它非常适合这种需求，完全可定制，具有处理文本文件时可以想到的所有功能（搜索、替换、阅读等，你能想到的）
我很惊讶没有人回答这个问题（除了以前的一个）答案，但适用于 MacOS）...
根据记录，我在 这篇博文，明智地提出了建议。
I Stumbled on this post many times, as I often need to handle huge files (10 Gigas+).
After being tired of buggy and pretty limited freeware, and not willing to pay fo costly editors after trial expired (not worth the money after all), I just used VIM for Windows with great success and satisfaction.
It is simply PERFECT for this need, fully customizable, with ALL feature one can think of when dealing with text files (searching, replacing, reading, etc. you name it)
I am very surprised nobody answered that (Except a previous answer but for MacOS)...
For the record I stumbled on it on this blog post, which wisely adviced it.
处理4G的文件确实很困难。 我曾经处理较大的文本文件，但我从未将它们加载到我的编辑器中。 我在以前的公司主要使用 UltraEdit，现在我使用 Notepad++，但我只会得到我需要编辑的那些部分。 （大多数情况下，文件不需要编辑）。
为什么要将这么大的文件加载到编辑器中？ 当我处理这些大小的文件时，我使用了 GNU Core Utils。 我对这些文件执行的最常见的操作是 head（获取前 250k 行等）、tail、split、sort、shuf、uniq 等。它非常强大。
使用 GNU Core Utils 可以做很多事情。 我肯定会推荐这些，而不是新的编辑器。
It's really tough to handle a 4G file as such. I used to handle larger text files, but I never used to load them in to my editor. I mostly used UltraEdit in my previous company, now I use Notepad++, but I would get just those parts which i needed to edit. (Most of the cases, the files never needed an edit).
Why do u want to load such a big file in to an editor? When I handled files of these size, I used GNU Core Utils. The most common operations i performed on those files were head ( to get the top 250k lines etc ), tail, split, sort, shuf, uniq etc. It's really powerful.
There's a lot of things you can do with GNU Core Utils. I would definitely recommend those, instead of a new editor.
很抱歉在这么旧的帖子上发帖，但我在这里尝试了一些技巧，但没有一个对我有用。
它与文本编辑器略有不同，但我发现 Beyond Compare 可以在我的 Vista 32 位机器上处理非常大（3.6 Gig）的文件。
这个文件让 Emacs、大文本文件查看器、HexEdit 和 Notepad++ 都卡住了。
-埃里克
Sorry to post on such an old thread, but I tried several of the tips here, and none of them worked for me.
It's slightly different than a text editor, but I found that Beyond Compare could handle an extremely large (3.6 Gig) file on my Vista 32-bit machine.
This is a file that that Emacs, Large Text File Viewer, HexEdit, and Notepad++ all choked on.
-Eric
在尝试了几次读取 6GB mysqldump 文件后，我最喜欢的是：
PilotEdit Lite http://www.pilotedit.com/。 Pilotedit.com/
因为：
我尝试过的其他...
EmEditor Pro 试用非常令人印象深刻，文件几乎立即打开，但不幸的是对于我的要求来说太贵了。
EditPad Pro 将整个 6GB 文件加载到内存中，并且速度减慢。
My favourite after trying a few to read a 6GB mysqldump file:
PilotEdit Lite http://www.pilotedit.com/
Because:
Others I tried...
EmEditor Pro trial was very impressive, the file opened almost instantly, but unfortunately too expensive for my requirements.
EditPad Pro loaded the whole 6GB file into memory and slowed everything to a crawl.
适用于 Windows、Unix 还是 Mac？ 在 Mac 或 *nix 上，您可以使用命令行或 GUI 版本的 emacs 或 vim。
对于 Mac：TextWrangler 可以很好地处理大文件。 我对 Windows 环境不够熟悉，无法提供帮助。
For windows, unix, or Mac? On the Mac or *nix you can use command line or GUI versions of emacs or vim.
For the Mac: TextWrangler to handle big files well. I'm not versed enough on the Windows landscape to help out there.