在 Mac OS X 上编辑大文件 [关闭]答案

【问题标题】：Editing large files on Mac OS X [closed]在 Mac OS X 上编辑大文件 [关闭]
【发布时间】：2010-10-31 11:22:06
【问题描述】：

有没有人推荐可以在 Mac OS X 上处理大文件的程序员编辑器？大我的意思是数百兆字节。 TextMate 没有删减它。

【问题讨论】：

您需要交互式编辑吗？既然这么大的文件会超出一个人的大脑可以处理的范围，也许你可以从中提取一些块并处理它们？或者使用 sed/perl/python/whatever 对流应用适当的更改，然后将文件输入？
这是一个很好的观点。它实际上是一个 XML 文件，我只是想了解它的结构。
Vim 也支持多种语言的折叠，但不确定它是否支持 XML。需要研究的东西:-)
>16GB Haswell Core i7 iMac 和运行 Mavericks 的 SSD 上的 5gb 日志文件：TextMate: 打开一个具有正确名称的空的单行文件，然后坐下什么都不做。我等了将近一个小时才放弃它。 TextWrangler & BBEdit: 立即出错。 Sublime Text 2： 进度条 9 分钟，然后再旋转 2 分钟，然后完美 Console： 一次只有 16MB 块。无法一次查看、滚动或搜索整个文件。
Crisp: 让我在下载试用版之前注册。嘘。没有评价。 XCode: 转轮五分钟；滚动很好，但编辑和搜索很糟糕。 MacVim： 打开一个空白的白色窗口。没有纺车。 30 秒后，文件打开。搜索、编辑和滚动都非常出色。 结论：根据您的优先级，我将胜利交给 Sublime Text 2 或 MacVim。

标签： macos editor

【解决方案1】：

你试过Vim吗？这是我唯一使用的编辑器:-)

编辑：这似乎取决于几个因素。我将 Vim 与大型 CSV（即基于文本的）文件一起使用，效果很好。 YMMV :-)

【讨论】：

如果 Vim 能够真正处理数百兆字节大小的文件，我向它致敬。我知道 emacs 会在非常大的文件上窒息。
我经常在非常大的日志文件上使用它。它只加载它需要的东西。现在，对每一行进行一些有趣的数据操作可能需要一段时间 ;-)
Vim 对我来说就像一个魅力，所以感谢你的建议。 BBEdit 被一个 78 MB 的文件卡住了，VIM 在几秒钟内就打开了它:)
FWIW 我刚刚在我的 MacBook Pro 上的 vim 中打开了一个 4GB 的 SQL 转储文件。打开需要一分钟，但它可以工作......
只是一个评论 - 巨大的 VIM 粉丝，但尝试在我的 Mac (MacVim) 和使用标准 VIM 的 ubuntu 上打开一个 3 GB 的文件，这需要很长时间！

【解决方案2】：

如果如您所说，只需要了解结构，请尝试在控制台中打开文档。信不信由你，我可以查看最大 15GB 的文件 (MAC OSX 10.7.2)

【讨论】：

刚刚试用过，它非常适合在 Mac 上查看大文件。它看起来像是为查看日志而设计的，因此必须学习如何使用它，但它在查看大文件时非常有效。谢谢！
我用这个在大约 10 秒内打开了一个 2.4GB 的文本文件。完美的！！！不能推荐这个。
谢谢！刚刚打开了一个 16.95gb 的 xml doc 文件。
控制台只打开最后 16 MB，这就是为什么它看起来很快！请注意状态栏中的Size: 8,7 GB (Showing last 16,8 MB)。
正确，托马斯。还有你好，小世界。）

【解决方案3】：

HexFiend 旨在读取任何大小的文件，但您需要使用固定列的字符换行并且不检测换行符。

【讨论】：

HexFiend 是我所见最快的读取文件之一（5gb sql 转储文件在 3 秒内打开），但这并不是真正的意思用于编辑。或者，菜单似乎没有暗示它。除非你不知道？
这对我有用 - 即使在 Vim 失败之后。
HexFiend 在 1-2 秒内打开一个 6gb 的 json 文件，毫不费力
无法处理 UTF-8...github.com/ridiculousfish/HexFiend/issues/247

【解决方案4】：

如果您只是想了解结构，那么使用 more 或 less 浏览如何？

【讨论】：

非常好的建议：如果你只需要阅读内容，less 比 vi 效率更高。

【解决方案5】：

vim 绝对是答案。查看macvim，mac 版本。

【讨论】：

你能解释一下vim是如何工作的吗？对我来说，它只显示文件的顶部或底部，不响应上下移动箭头，也不响应点击...

【解决方案6】：

BBEdit，那个旧的备用服务器，以沉着地处理非常大的文件而闻名（或者，至少，它回到了 TextMate 之前的时代）。有一个免费版本，TextWranger；我认为它基于相同的核心并且应该仍然可以工作。

【讨论】：

我尝试了 TextWrangler，但不幸的是它卡在了文件上。
最新的 BBEdit 在我的 4GB 文件上崩溃。我通常将它用于百兆文件，但它显然无法处理 GB 大小的文件。
TextWrangler 和 BBEdit 可以编辑最大 384MB 的任何文件。这个限制是因为它们将整个文件存储在 RAM 中，并且它是 unicode 加密的，因此效率不高。我最近在一个巨大的 XML 文件上使用了split -b 300m foo.xml，TextWrangler 花了几秒钟的时间打开它，但随后功能齐全——甚至语法高亮。
@AbhiBeckert 编码，你的意思是编码

【解决方案7】：

我已将 gvim 用于大于 1 GB 的 NASTRAN 输出文件。 gvim 可以很好地处理大文件。事实上，这是我从 Emacs 切换到 vim 的主要原因。

Emacs 是一个很棒的编辑器，但它只能处理 128 MB 的文件，至少是 32 位版本。如果您决定使用 Emacs，我建议将其配置为关闭大文件的语法突出显示。

当时处理大文件的另一种方法是大量使用 head、tail 和 split。

【讨论】：

【解决方案8】：

Vim 已经被推荐了。如果您使用 vim，您可能还想使用 LargeFile 插件（由无与伦比的 Charles “Dr Chip” Campbell 提供），它会自动禁用 vim 的各种功能，以提高文件超过 100Mb 的速度（默认设置)。

【讨论】：

【解决方案9】：

OS X 上的本机 emacs 现在似乎是 64 位版本。它在我的 250MB 文本文件中非常有用。

【讨论】：

【解决方案10】：

emacs，当然，至少是 64 位构建（现在你可以在 OS X 上做到这一点，对吗？）

而且，这些肯定是生成的文件。您真的需要一次与他们互动吗？

【讨论】：

据我所知，Emacs 最多只能处理 128 MB。不确定 64 个版本。
是的，32 的 128mb 限制。我应该仔细检查一下 OS X 上的 64 位构建，因为在某些方面 64 位很有趣

【解决方案11】：

由于您在评论中指出它实际上是一个 XML 文件并且您只是想了解它的结构，您可能需要查看 Oxygen'sLargeFileViewer，这是一个与 Oxygen XML 编辑器捆绑在一起的帮助应用程序。（我不知道它也可能与作者一起提供。）

【讨论】：

【解决方案12】：

Crisp 声称可以编辑“8GB 或更多”的文件，但我没有尝试过。

【讨论】：

【解决方案13】：

编辑：不要使用 Sublime Text 2！虽然它对我有用，但显然对于许多其他用户 Sublime Text 2 无法处理大文本文件。以下是我的原始答案：

Sublime Text 2 for Mac 10.6.8 为我打开了一个 200 MB 的文件，没有任何问题

【讨论】：

刚刚用 180MB 的 SQL 文件试了一下。打开文件几分钟，尝试将整个文件加载到内存中。不好
如果您正在编写 180MB 的 SQL 文件，我认为您可能“做错了”。（哦，这是出口？那我原谅你）
Sublime Text 3 在对大文件进行查找和替换时基本上会挂起。
非常棒的文本编辑器，但不是它的强项。
我不断收到对我的答案的负面反馈，我相信所有反对这个答案的人，我的答案对于他们的用例来说是不正确的。事实上，也许我的回答是正确的唯一用例是我的用例:-)。我在考虑怎么办？我应该删除这个答案并获得一些分数来恢复我的声誉吗？我决定保留这个答案 - 作为对这个问题的未来观众的警告。不要使用 SUBLIME TEXT 2！它似乎对大多数用户不利。