文本编辑器打开大(巨型,巨大,大)文本文件


1023

我的意思是100+ MB大;这样的文本文件可以推挤编辑器的范围。

我需要浏览一个大的XML文件,但是如果编辑器有错误,则无法浏览。

有什么建议么?


166
实际上,100+ MB甚至1+ GB的文本文件并没有您想像的那么罕见(即,来自繁忙服务器的日志文件)。
安德斯·桑德维格

15
鬼:不是完全是文字。我认为读取文本文件和读取二进制文件的要求有所不同。您可以通过base64或uuencode传递它。
乔伊(Joey)

2
这应该是至少一个类似的问题或有人问18个月之前......即使挂stackoverflow.com/questions/102829/...
ONDEV

1
我也在寻找这个确切问题的答案,以便阅读我生成的一些巨大的日志文件!
HorseloverFat 2012年

1
@BlairHippo我有同样的感觉,问一个问题时我几乎紧张,因为很有可能有人会说“关闭它,应该改用WhateverExchange”
Rodolfo 2013年

Answers:


1385

免费的只读查看器:

  • 大文本文件查看器(Windows)–完全可自定义的主题(颜色,字体,自动换行,标签大小)。支持水平和垂直拆分视图。还支持文件跟踪和正则表达式搜索。非常快速,简单,并且可执行文件很小。
  • klogg(Windows,macOS,Linux)– glogg的维护分支,其主要功能是正则表达式搜索。它还可以监视文件,允许用户标记行,并且内置了认真的优化功能。但是从UI的角度来看,它很丑陋而且笨拙。
  • LogExpert(Windows)–“的GUI替代”tail。它实际上是一个日志文件分析器,而不是大文件查看器,在一次测试中,加载250 MB文件需要10秒和700 MB RAM。但是它的杀手级功能是专栏工具(解析CSV,JSONL等格式的日志,并以电子表格格式显示)和荧光笔(以特定颜色显示带有某些单词的行)。还支持文件跟随,标签,多文件,书签,搜索,插件和外部工具。
  • Lister(Windows)–非常小巧。它是一个可执行文件,只有500 KB,但仍支持搜索(使用正则表达式),打印,十六进制编辑器模式和设置。
  • loxx(Windows)–支持文件跟随,突出显示,行号,大文件,正则表达式,多个文件和视图等。免费版本不能:处理正则表达式,过滤文件,同步时间戳和保存更改的文件。

免费编辑:

  • 您的常规编辑器或IDE。现代编辑器可以处理惊人的大文件。特别是Vim(Windows,macOS,Linux),Emacs(Windows,macOS,Linux),Notepad ++(Windows),Sublime Text(Windows,macOS,Linux)和VS Code(Windows,macOS,Linux)支持大(〜 4 GB)文件(假设您具有RAM)。
  • 大型文件编辑器(Windows)–打开和编辑TB +文件,支持Unicode,使用很少的内存,具有XML特定的功能,并包括二进制模式。
  • GigaEdit(Windows)–支持搜索,字符统计和字体自定义。但这是有问题的–对于大文件,它仅允许覆盖字符,而不能插入字符;它不将LF视为行终止符,而仅将CRLF视为行终止符。而且很慢

内置程序(无需安装):

  • less(macOS,Linux)–传统的Unix命令行传呼工具。使您可以查看几乎任何大小的文本文件。也可以安装在Windows上。
  • 记事本(Windows)–较大的文件比较合适,尤其是在自动换行功能关闭的情况下。
  • 更多(Windows)–这是指WindowsMORE,而不是Unixmore。一个控制台程序,使您可以一次查看一个屏幕的文件。

网络浏览器:

付费编辑:

  • 010编辑器(Windows,macOS,Linux)–打开巨型文件(最大50 GB)。
  • SlickEdit(Windows,macOS,Linux)–打开大文件。
  • UltraEdit(Windows,macOS,Linux)–打开大于6 GB的文件,但必须对其进行更改才能使其实用:菜单»高级»配置»文件处理»临时文件»打开不带临时文件的文件...
  • EmEditor(Windows)–很好地处理非常大的文本文件(官方最多可处理248 GB,但根据一份报告则可处理多达900 GB)。

59
VIM或Emacs ...选择您的毒药,两者都会处理您向他们扔的任何文件。我个人更喜欢Emacs,但是两者都可以打败记事本,而不会打h。
迈克·斯通

25
Emacs具有最大的缓冲区大小,具体取决于基础架构(32或64位)。我认为在32位系统上,大于128 MB的文件会出现“超出最大缓冲区大小”错误。
2009年

82
我刚用561MB的日志文件尝试过Notepad ++,但说文件太大
barfoon

9
@Rafal有趣!看起来在64位上约为1024 PB。原因与emacs必须跟踪缓冲区位置(例如点)有关
baudtack

79
但是要小心,只有在有问题的文件具有足够的换行符时,vim才起作用。我曾经不得不编辑一个ca。150 MB的文件,没有任何换行符,并且不得不诉诸gedit,因为vim无法处理它。
Benno 2010年

192

技巧和窍门

为什么要使用编辑器查看(大)文件?

在* nix或Cygwin下,只需较少使用即可。(有句名言“少即是多,或多或少”,因为“少”代替了以前的Unix命令“更多”,另外还可以向上滚动。)在“少”下搜索和导航类似于Vim,但是没有交换文件和很少的RAM。

GNU的Win32端口更少。请参阅上面答案的“较少”部分。

佩尔

Perl适用于快速脚本,它的..(范围触发器)运算符提供了一种很好的选择机制,可以限制您必须经历的工作。

例如:

$ perl -n -e 'print if ( 1000000 .. 2000000)' humongo.txt | less

这将提取从1百万行到2百万行的所有内容,并允许您以更少的成本手动筛选输出。

另一个例子:

$ perl -n -e 'print if ( /regex one/ .. /regex two/)' humongo.txt | less

当“正则表达式一”找到某些内容时,此操作开始打印,而当“正则表达式二”找到有趣的块的末尾时,此操作停止。它可能会找到多个块。筛选输出...

日志解析器

这是您可以使用的另一个有用的工具。引用维基百科的文章

logparser是一种灵活的命令行实用程序,最初由Microsoft员工Gabriele Giuseppini编写,用于自动化IIS日志记录的测试。它旨在用于Windows操作系统,并且包含在IIS 6.0资源工具包工具中。logparser的默认行为类似于“数据处理管道”,方法是在命令行上获取SQL表达式,然后输出包含与该SQL表达式匹配的行。

Microsoft将Logparser描述为功能强大的多功能工具,它提供对基于文本的数据(例如日志文件,XML文件和CSV文件)以及Windows操作系统上的关键数据源(例如事件日志,注册表,文件系统和Active Directory。输入查询的结果可以在基于文本的输出中自定义格式,或者可以持久保存到SQL,SYSLOG或图表等更特殊的目标。

用法示例:

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%'"

尺寸的相对性

100 MB不太大。3 GB越来越大。我曾经在打印和邮件设施工作,该设施创造了美国一流邮件的2%。我担任技术负责人的系统之一占邮件总数的15%以上。我们到处都有一些大文件要调试。

和更多...

请随时在此处添加更多工具和信息。这个答案是社区Wiki的一个原因!我们都需要更多有关处理大量数据的建议...


8
+1,最近我需要查看一些非常大的xml文件(+1 GB)。我在Windows上,vim,emacs,notepad ++和其他几个编辑器都完全阻塞了文件,以至于试图打开文件时,我的系统几乎变得无法使用。一段时间后,我意识到当我只需要查看它时,实际上没有必要尝试在-editor-中打开文件。使用cygwin(和一些聪明的grep / less / sed-magic),我很容易找到了我感兴趣的部分,并且可以轻松阅读。
wasatz

8
您不需要cygwin,也可以在Windows
ChristophK,

2
这里的XML编辑器还有一个大文件查看器组件,并且确实为大文件提供了语法着色。文件没有完全加载到内存中,因此多GB文档应该不是问题。另外,该工具还可以验证那些大型XML文档。我认为,处理大型XML数据的最佳方法之一。
lichtfusion

9
好,所以我只解决了自己的问题。less用自动换行很慢。less -S没有自动换行功能,即使在较大的行数上,闪电般快速。我又开心了!
安迪·布朗

6
好答案。我想指出的是,如果您已经安装了Windows版Git,则可能还包括Git bash,其中包括less
transistor1
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.