我的意思是100+MB大；这样的文本文件可以推动编辑器的信封。
我需要查看一个大的XML文件，但是如果编辑器有问题，就不能查看。
有什么建议吗？
- 实际上，100+MB甚至1+GB的文本文件并不像您想象的那样罕见(即，来自繁忙服务器的日志文件)。
- 鬼鬼祟祟：不完全是文字。我认为阅读文本文件和阅读二进制文件的要求有所不同。不过，您可以通过base64或uuencode传递它。
- 早在1995年，我就用Winword在16MB的机器上打开64MB的文件。我相信15年后也会有同样的效果。
- 要生成随机文本文件而不是二进制文件，请使用以下命令：cat /dev/urandom | tr -dc 'A-z' | head -c 1000000，其中-c之后的最后一个数字是文件中的字节数。
- 实际上，Microsoft Office Access可以读取和分析非常大的XML文件，但只有当XML格式与可以转换为表的内容相匹配时，它才有意义。
- 如果使用vim:set binary superuser.com/questions/364012/&hellip；
- 这至少应该是一个类似的问题，甚至与18个月前的问题联系在一起…stackoverflow.com/questions/102829/&hellip；
- 我也在寻找这个确切问题的答案，以便阅读我生成的大量日志文件！
- 这是我的回退：gigaedit(heliwave.com/gigaedit.html)。没有什么新奇的，但小，便携式，免费和打开大量文件在一瞬间。
- @我也有同样的感觉，当我问一个问题的时候，我几乎紧张，因为有人会说"关闭这个，它应该去什么交换代替"
- @偷偷摸摸这也可以用来在几秒钟内生成大文件。grep -r"someText" . > bigfile假设目录中有一些文件包含符合搜索条件的匹配行。当然，您需要强制停止grep，因为这将使grep进入一个无止境的循环：)
- amolnpujari.wordpress.com/2012/03/31/reading_巨无霸xml-rb它在Ruby中处理大型xml非常简单
- 要查看文件，我建议使用这个在线查看器-readfileonline.com-您不必安装任何编程接口，它可以在每个设备和操作系统中工作。
- 在具有PowerShell>获取内容C:scripts est.txt的Windows计算机上-totalCount 3
- winasm.net/free-small-fast-text-editor.html免费且非常快速
- 你可以在jenson.in/demos/open ou biant ou files ou in ou browser.php上尝试这个方法。
- 首先问问你自己：你真的想编辑一个大于1GB的文件，还是想快速查看它，并能编辑其他"普通"文件？在后一种情况下，您可以更好地选择日志查看器和文本编辑器。
VS代码(Windows、MacOS、Linux)-免费开放源代码，带有一个漂亮的GUI。编辑了一个3.6 GB的JSON文件，一分钟后加载。您必须有足够的RAM来加载文件。
免费只读查看器：
- GLOG(Windows、MacOS、Linux)–已确认处理多GB文件。其主要特点是正则表达式搜索。具有选项卡，直接从磁盘读取文件，可以监视/跟踪文件，并允许用户标记行。
- logexpert(windows)–"tail的图形用户界面替代品"。支持文件跟踪、搜索、过滤、可配置的突出显示、插件和外部工具。
- 大文本文件查看器(Windows)–最小，可执行大小非常小。支持拆分视图、文本主题自定义、regex搜索和文件跟踪。
- Lister(Windows)–更小巧、更简约。它是一个可执行文件，只有500kb，但它仍然支持搜索(使用regex)、打印、十六进制编辑器模式和设置。
自由编辑：
- Vim和Emacs(Windows、MacOS、Linux)–经典的Unix编辑器。学习曲线陡峭，但效率极高。它们的设置可以进行调整以使其更快。
- 大文件编辑器(Windows)–打开和编辑TB+文件，支持Unicode，使用很少的内存，具有特定于XML的功能，并包括二进制模式。
- hxd(windows)–一个十六进制的编辑器，而不是文本编辑器；但是它的速度和实用性令人惊讶。
- GigaEdit(Windows)–支持搜索、字符统计和字体自定义。但是它有问题——对于大文件，它只允许重写字符，而不允许插入字符；它不把lf看作行终止符，只允许crlf；而且速度很慢。
内置程序(不需要安装)：
- LESS(MacOS、Linux)–传统的Unix命令行寻呼机工具。允许您查看几乎任何大小的文本文件。也可以安装在Windows上。
- 记事本(Windows)–适合大文件，尤其是关闭自动换行。
- 更多(windows)–这是指windows MORE，而不是unix MORE。一种控制台程序，允许您一次查看一个文件。
网络观众：
- htmlpen.com–可以打开并语法突出显示tb+文件。允许编辑，非常大的文件除外。支持搜索、正则表达式和导出。
- readfileonline.com–另一个HTML5大型文件查看器。支持搜索。
付费编辑：
- 010编辑器(Windows、MacOS、Linux)–打开巨大的(高达50 GB)文件。
- slickedit(windows、macos、linux)–打开大文件。
- Ultraedit(Windows、MacOS、Linux)–打开超过6 GB的文件，但必须更改配置才能使其实用：菜单？先进的？配置？文件处理？临时文件？打开没有临时文件的文件…
- eMeditor(Windows)–可以很好地处理非常大的文本文件(官方最高为248 GB，但根据一份报告，高达900 GB)。
最后，您试过用常规编辑器打开大文件吗？有些编辑器实际上可以处理相当大的文件。特别是，记事本+和高级文本(Windows、MacOS、Linux)支持2 GB范围内的文件。
- Vim或Emacs…挑选你的毒液，他们都会处理你向他们扔的任何文件。我个人更喜欢Emacs，但两者都能在不打嗝的情况下击败记事本。
- Emacs具有最大的缓冲区大小，这取决于底层体系结构(32或64位)。我认为在32位系统上，大于128MB的文件会出现"超过最大缓冲区大小"错误。
- 我刚用一个561MB的日志文件尝试了notepad++，它说它太大了
- 我经常用gvim打开~600MB的文件…
- 我过去曾被要求编辑多GB范围内的几个纯文本文件，我们的用户试图用MS Word编辑这些文件…好吧，你们大多数人都会知道发生了什么。刚刚在vim中打开它，搜索并替换为坐在我旁边的用户(当然，在最终读取了那个巨大的文件之后)。
- @拉法很有趣！在64位上看起来是~1024千兆字节。原因与Emacs必须跟踪缓冲区位置(如点)有关。
- 我会用第二个gvim获取大量文件。我刚编辑了一个950MB的文本文件，没有任何问题(但打开和保存需要一段时间)。当我在notepad2中尝试相同的文件时，Windows开始关注我的页面文件的大小，并开始调整它的大小。
- 但是要小心，只要有问题的文件有足够的换行符，VIM就只能工作。我曾经不得不编辑一个大约150MB的文件，没有任何行中断，并且不得不求助于gedit，因为vim无法处理它。
- 如果您打算使用(g)vim来提高性能，那么您可能需要关闭一些功能，例如语法高亮显示、swapfile和undo。参见vim.wikia.com/wiki/faster_loading_of_large_files，vim.wikia.com/wiki/vimtip611 and vim.org/scripts/script.php？Script PtId＝1506。
- 我想知道5GB文本文件是否存在。-哦…如果你不介意的话，我可以知道……(在现实世界中)我们被迫使用/编辑这些庞大的文本文件。(另一种方法是打破文件并制作一些文件..通常任何文件类型的较大文件都会使系统哭泣以提供性能)
- @Rafal:Emacs23可以增加Emacs23的缓冲区大小。我现在不记得怎么做了。
- 我尝试了所有的方法，gvim吸进了一个信息，它甚至没有告诉你它正在加载一个文件——永远都需要加载这个文件(只有20万行，500万行)。Slickedit在大约3秒钟内打开了整个文件。拿到试用许可证是件好事。感谢您列出这些。
- Emacs在32位上肯定存在缓冲区大小问题。
- 我想要一个mmap()文件的编辑器，它只读取我正在查看的部分…即使是gvim似乎也会先将整个内容加载到内存中，甚至调整窗口的大小也会在它认为…
- 我遇到了一个由6MB代码编码的单个字符的问题。记事本+和NetBeans无法处理它，但010编辑器很容易做到！D
- gvim需要永远加载一个2GB文件，然后在其中查找也非常缓慢。它似乎将整个文件加载到RAM中。也许大型文件插件会有帮助，但默认的似乎不是最佳的。
- 无法在1.6GB文件上使用这些文件，尤其是gvim或我可以找到的任何其他vim for windows。必须使用filesplitter将其拆分为100MB块，然后我使用editplus查看它们。旧的edit.com(dos)可以处理大文件(几百MB)，但在64位窗口中不可用。
- 010editor成功打开了我的3.3GB MySQL数据库转储。
- 010编辑器是否有XML格式选项？
- 如果交换处于打开状态，32位版本的VIM 7.3将以大约2g的速度崩溃，如果交换处于关闭状态，只会给出错误的行数。但是64位版本工作正常；我当前正在"浏览"一个7.5g文件，我无法用鼠标调整窗口大小，查找速度有点慢，但它工作正常。(81m行，应用程序中所有内存分配的日志。)
- @医生啊，废话。我的1025petabyte文件呢？呃。我猜Emacs是如此的固守在过去以至于它不能编辑它。它认为日期是1997年？
- 使用了大文本查看器和hxd的组合。LTV用于漂亮的文本视图和行搜索，HXD用于实际编辑+搜索和替换。
- 我有一个2+千兆字节的SQL脚本，我试图用gvim打开它。它折起来像一对2，然后坐下来哭了。然后我试了一下010editor，它像冠军一样闪耀。报废GVIM，使用010。
- 我用hxd打开大文件。它对我来说非常有用，还有很多其他的特性。我可以在不到一秒钟的时间内用它(约200 GB)打开并查看整个硬盘。滚动浏览文件并对其进行编辑也非常顺利。
- "但是要小心，Vim只能在有问题的文件有足够的换行符的情况下工作。"@benno，这是Vim中的配置设置，而不是限制。你可以这样改变：:set display+=lastline。但是，不把它作为默认值有点奇怪。
- 如果您一直在使用largetextfileviewer，请切换到glogg！LTF较小，但Glogg似乎工作得更好。
- 如果您只想查看文件内容，那么我建议您使用一个非常好的在线工具：readfileonline.com，它适用于所有现代浏览器。
- 大文本文件查看器能够打开一个22GB的文件而不会出现任何问题。
- 有没有办法在hxd中看到具有正确换行符的文件？？我觉得奇怪的"…"是分隔符，甚至连行尾都没有。
- 使用大文本文件查看器，我刚刚打开了一个30GB的文件，没有问题。不过，找到一个特定的关键字大约需要5分钟。
- gvim会打开我的1.6GB文件，但我不能真正用它做太多…我知道这是一项艰巨的任务，但我需要找到并替换大约1.5亿个实例。GVIM只能做到一半。
- emeditor将快速打开"高达248 GB的限制(或21亿行)"emeditor.com/text editor的功能/large file support/&hellip；对于csv文件也有分隔符("open data files up to 20 billion rows and 200 million columns large！")DelimtWist.com
- 使用gvim时，使用此插件自动禁用大型文件上的慢速功能：github.com/vim-scripts/largefile
- gvim被8GB文件阻塞并"停止工作"。
- 我找不到010编辑器来搜索一个20克的大文本文件…在我杀死它之前，它只是窒息和冻结
- 请参见vim的largefile插件。
- 您可以使用XML验证器或buddy浏览、编辑和搜索/替换几乎任何大小的文本文件。此外，您还可以获得XML文档的语法着色。编辑器也允许您选择编码。
- logexpert在长线上失败。如果一条线是~8000个字符，它将被切断，并且下一条线也将被切断，要短得多。HXD工作得很好。
- 我用010编辑器打开了一个42.7GB的文件(是的，维基百科XML文件27)。它起作用了(文件有634957038行)！我在一台笔记本电脑上使用的是Windows10 64位，内存为16GB，编辑器为010的V6.0.3。我还可以搜索文件末尾的字符串(尽管010花了将近10分钟完成搜索)。
- 正如@user2070775所建议的，readfileonline.com非常适合快速查看。
- 此处仍存在大型文本视图查看器。
- 我自己使用editpad-lite(非商业用途免费)，它可以编辑大于4 GB的文件，即使您的电脑只有几GB的RAM。此外，单行的最大长度不受限制，这是许多编辑器声称支持"无限"文件大小的问题。
- windows命令more是查找和确认文件结构的理想工具。
- Sublime Text 3适用于大型文件；我没有代表将其作为答案添加，但只是用1.6g日志文件进行了测试。它甚至在读取文件时显示了一个加载条，与这里提到的其他程序不同，使用起来感觉很流畅。它是免费的，而且还有一个便携版本！
- 我不知道为什么我不能回复操作。在Windows中最好的选择是：eMeditor、Delimit、EditPad Pro和Texpad，所有的商业和所有的都可以读写和做许多比内存大得多的文件。emeditor和delimit提供了将csv文件作为电子表格查看的选项。我遇到了emeditor的问题，它每隔几秒钟就重新加载一次文件，使您无法工作。您还可以尝试slickeditor和hippoedit。
- 010编辑器非常适合我的情况，我必须编辑一个8GB的MySQL转储，但失败了，我必须恢复，我还从日志表中删除了一些GBS，这节省了我很多时间！
- 另外，总司令的"查看文件"菜单选项(F3)也非常擅长这一点。我认为，它所做的是虚拟滚动，而不是加载所有内容。
- largetextfileviewer为我工作，提供2 GB的文本。Emurasoft的eMeditor声称，如果其他解决方案对您不起作用，那么它的开放空间可达248GB，可能值得一看。
- Liquidsoft有一个可怕的安装程序，它给我留下了一个无法关闭的对话框。
- 010编辑工作很有魅力：D
- 我尝试过logexpert，并为1GB文本文件工作得很好。其他人不是自由的，也不是为我工作的
- Liquid Large File Editor做得很好，而且是免费的(社区版)：liquid-technologies.com/large-file-editor
- 我试过logexpert 1.5.5493。它总是在打开一个大的txt文件不到2分钟后崩溃。TXT文件大约2.5g。
- 在19gbjson跟踪文件上使用010editor的混合包体验。在显示文件之前，需要几秒钟"扫描换行符"。执行搜索时崩溃，似乎在移动到第一个"最近"匹配项之前查找所有匹配项(因为显示匹配项花费了一段时间，当时有完整的匹配项列表)。否则还允许我检查我的超大文件，所以不是完全浪费。FWW。
- 请注意，LiquidStudio甚至要求您注册"免费"社区版(电子邮件、姓名等)，这有点不可靠。logexpert试图将整个文件加载到内存中，因此使用一个30 GB的文件和12 GB的RAM，它对我来说不起作用。
- 在我的电脑上，Liquid Studio文本搜索速度仅为23 MB/s！荒谬的相比之下，eMeditor速度为312 MB/s，并受CPU速度限制。我有SSD。基准日期：2018年6月19日。
- 更新：glogg在Liquid Studio和EmEditor之间有搜索性能。EmEditor仍然是最快的。
- 你能用logexpert编辑文件吗？
- 在64位的Windows中，标准记事本.exe完美地处理了450 MB的csv文件中的打开和搜索，而崇高的文本3则永远挂起，而vs代码则表示它太大了。
- 格洛格真是太棒了。我可以很容易地发现趋势并过滤到一个日志标记。谢谢你的推荐。
- 我认为VS代码是一个很好的选择。免费和开源。刚刚添加到列表中。
提示和技巧较少的
为什么使用编辑器只查看(大)文件？
在*nix或cygwin下，使用更少。(有句名言——"少即多，多即少"——因为"少"取代了早期的unix命令"多"，添加了一个可以向上滚动的命令。)在"少"下搜索和导航与vim非常相似，但没有交换文件和使用的RAM。
有一个不含GNU的win32端口。请参阅上面答案的"更少"部分。
珀尔
Perl非常适合快速脚本，它的..操作符(range flip-flop)提供了一种很好的选择机制，可以限制必须处理的crud。
例如：
1
| $ perl -n -e 'print if ( 1000000 .. 2000000)' humongo.txt | less |
这将提取从第100万行到第200万行的所有内容，并允许您手动筛选更少的输出。
另一个例子：
1
| $ perl -n -e 'print if ( /regex one/ .. /regex two/)' humongo.txt | less |
当"正则表达式1"找到某个内容时开始打印，当"正则表达式2"找到感兴趣的块的结尾时停止打印。它可能会找到多个块。筛选输出…
统计程序
这是您可以使用的另一个有用的工具。引用维基百科的文章：
logparser is a flexible command line utility that was initially written by Gabriele Giuseppini, a Microsoft employee, to automate tests for IIS logging. It was intended for use with the Windows operating system, and was included with the IIS 6.0 Resource Kit Tools. The default behavior of logparser works like a"data processing pipeline", by taking an SQL expression on the command line, and outputting the lines containing matches for the SQL expression.
Microsoft describes Logparser as a powerful, versatile tool that provides universal query access to text-based data such as log files, XML files and CSV files, as well as key data sources on the Windows operating system such as the Event Log, the Registry, the file system, and Active Directory. The results of the input query can be custom-formatted in text based output, or they can be persisted to more specialty targets like SQL, SYSLOG, or a chart.
示例用法：
1
2
| C:\>logparser.exe -i:textline -o:tsv"select Index, Text from 'c:\path\to\file.log' where line > 1000 and line < 2000"
C:\>logparser.exe -i:textline -o:tsv"select Index, Text from 'c:\path\to\file.log' where line like '%pattern%'" |
尺寸的相对性
100MB不太大。3GB正在变得越来越大。我曾经在一家打印和邮寄公司工作，这家公司创造了美国大约2%的一等邮件。其中一个我是技术负责人的系统占邮件总数的15%以上。我们有一些大文件要调试。
还有更多…
请随意在此处添加更多工具和信息。这个答案是有原因的社区维基！我们都需要更多关于处理大量数据的建议…
- +1，我最近有一些非常大的XML文件(+1千兆字节)，我需要查看这些文件。我在Windows上，Vim、Emacs、Notepad++和其他几个编辑器都完全阻塞了文件，以至于我的系统在试图打开文件时几乎无法使用。过了一会儿，我意识到在一个编辑器中打开这个文件是多么的不必要——而我只是需要——查看——它。使用cygwin(和一些聪明的grep/less/sed魔法)，我很容易找到我感兴趣的部分，可以轻松地阅读它。
- Cygwin在查看一个大于2GB的文件方面做得比较少
- 您不需要Cygwin，也可以在windows下使用它：gnuwin32.sourceforge.net/packages/less.htm
- 我不知道如何用less编辑文件，但在尝到味道后，我用vim编辑了一个庞大的json对象，这使得其他编辑器(括号，textmate<-note，我在os x上运行)都吐了出来。
- 这里的XML编辑器也有一个大型的文件查看器组件，并为大型文件提供语法着色。文件没有完全加载到内存中，因此多GB文档不应该是问题。此外，该工具还可以验证那些大型XML文档…在我看来，使用大型XML数据的最佳方法之一。
- 我将"否认"logparser.exe这一"社区"添加到我的答案中的东西，因为我更喜欢使用POSIX工具，而不是一些仅限Microsoft的东西，显然，与我的其他示例相比，它调用命令行的时间更长。
- 我试过用mingw shell包装的less，它抱怨400MB文件的内存问题。无益。
- 只要线路不太长，less就很好。我在这个线程中是因为更少的(Linux)会严重阻塞包含大型序列化XML的调试日志文件，我需要更快的速度。
- 好吧，所以我只是解决了我自己的问题。带换行符的less速度较慢。没有自动换行的less -S即使在大型线路上也是闪电般的快。我又高兴了！
- 很好的回答。我想指出的是，如果您安装了用于Windows的Git，那么您可能也安装了Git-bash，其中包括less。
- 好吧，这部电影有点像"艾伦·史密斯的作品"。我最初的回答没有提到IISLogParser，因为我尽可能避免使用MS Windows。我想维基是快乐的：-)
- 锁定问题是StackOverflow中最好的问题之一。