82

4 GB 以上のファイルを読み込めるテキスト エディタを探しています。テキストパッドが機能しません。私はそれのコピーを所有しており、そのサポート サイトにアクセスしましたが、それができません。新しいハードウェアが必要かもしれませんが、それは別の問題です。エディターは無料である必要があります。または、費用がかかる場合は 30 ドル以下である必要があります。Windows 用。

4

24 に答える 24

54

glogg も別の用途で考えられます:

グロッグのスクリーンショット

警告 ( 2013 年 2 月のコメントでSimon Tewsiによって報告されました)

1 つの注意点 -Main SearchQuick Find.
私が想定している下のものはQuick Find、速い上のものよりも少なくとも1桁遅いです。

于 2008-10-02T18:49:10.263 に答える
28

モンスター(暴走)ログファイル(20GB以上)を見なければなりませんでした。どんなサイズのファイルでも動作するhexeditFREEバージョンを使用しました。オープンソースでもあります。これはWindowsの実行可能ファイルです。

于 2008-09-19T15:59:52.083 に答える
13

Jeff Atwood がこれについて投稿しています: http://www.codinghorror.com/blog/archives/000229.html

彼は最終的に Edit Pad Pro を使用しました。「これまでの使用履歴に基づいて、EditPad Pro が最適であると感じたからです。大きなテキスト ファイルでも非常に高速で、最適な正規表現をサポートしており、ふりをしないからです。 IDEになること。」

于 2008-09-19T15:30:16.567 に答える
11

grep巨大なログ ファイルをエディタにロードする代わりに、tail、 、 などの Unix コマンド ライン ツールを使用してgawk、興味深い部分をより小さなファイルにフィルタリングしてから、それを開きます。

Windows では、Cygwinを試してください。

于 2009-05-13T13:59:32.100 に答える
5

コンテキストエディターを試しましたか? 小さくて速いです。

于 2011-01-30T12:11:54.477 に答える
4

巨大なファイル(10 Gigas +)を処理する必要があることが多いため、この投稿に何度も遭遇しました。

バグが多く、かなり限られたフリーウェアにうんざりしていて、試用期間が終了した後、高価な編集者にお金を払う気がなかった後(結局のところお金の価値はありません)、私はVIMforWindowsを大成功と満足で使用しました。

これは、このニーズにぴったりで、完全にカスタマイズ可能で、テキストファイルを処理するときに考えられるすべての機能(名前を付けた検索、置換、読み取りなど)を備えています。

私は誰もそれに答えなかったことに非常に驚いています(前の答えを除いて、MacOSの場合)...

記録のために、私はこのブログ投稿でそれを見つけました。それは賢明にそれをアドバイスしました。

于 2013-01-15T00:49:30.123 に答える
3

このような古いスレッドに投稿して申し訳ありませんが、ここでいくつかのヒントを試しましたが、どれもうまくいきませんでした.

テキスト エディタとは少し異なりますが、Beyond Compare は、Vista 32 ビット マシンで非常に大きな (3.6 ギガ) ファイルを処理できることがわかりました。

これは、Emacs、Large Text File Viewer、HexEdit、および Notepad++ がすべて窒息させたファイルです。

-エリック

于 2011-05-20T17:41:47.000 に答える
3

4Gファイルをそのまま扱うのは本当に大変です。以前はより大きなテキスト ファイルを処理していましたが、エディターに読み込むことはありませんでした。以前の会社では主に UltraEdit を使用していましたが、現在は Notepad++ を使用していますが、編集が必要な部分だけを取得していました。(ほとんどの場合、ファイルを編集する必要はありません)。

なぜそんなに大きなファイルをエディタにロードしたいのですか? これらのサイズのファイルを処理するときは、GNU Core Utils を使用しました。私がこれらのファイルに対して実行した最も一般的な操作は、head (上位 250k 行を取得するなど)、tail、split、sort、shuf、uniq などでした。これは非常に強力です。

GNU Core Utils でできることはたくさんあります。新しいエディターではなく、それらをお勧めします。

于 2008-09-19T15:32:49.557 に答える
3

6GBのmysqldumpファイルを読むためにいくつか試した後の私のお気に入り:

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

なぜなら:

  • メモリ使用量が (どういうわけか?!) 25MB を超えたことがないため、システムの残りの部分には基本的に影響はありませんが、開くのに数分かかりました。
  • その間、正確なプログレスバーがあったので、それがどのように進んでいるかを知っていました.
  • ファイルを開くと、簡単な検索と参照がすべて機能し、小さなメモ帳ファイルも機能しました。
  • それは無料です。

他に試した...

EmEditor Proの試用版は非常に印象的で、ファイルはほぼ瞬時に開きましたが、残念ながら私の要件には高すぎました。

EditPad Proは 6GB のファイル全体をメモリにロードし、すべてをクロールに遅らせました。

于 2015-07-21T10:43:30.943 に答える
1

Tweakは、挿入や削除など、非常に大きなファイルの編集を処理できる16進エディターです。

于 2013-01-07T09:56:13.293 に答える
1

大きなファイルを編集するのではなく表示するだけの場合は、ファイル全体をメモリにロードするのではなく、ファイルを一度にチャンクずつ読み取るフリーウェア プログラムがいくつかあります。大きな (> 5 GB) ファイルを読み取る必要がある場合は、これらを使用します。

swiftgear による大きなテキスト ファイル ビューアhttp://www.swiftgear.com/ltfviewer/features.html

Team Walrus による Big File Viewer。

初心者のハイパーリンクは最大 1 つしか投稿できないため、最後のリンクのリンクは自分で見つける必要があります。

于 2010-07-02T22:41:11.053 に答える
1

EmEditorがこれを処理する必要があります。彼らのサイトが主張するように:

EmEditor は、新しいカスタム バーであるラージ ファイル コントローラーでファイルの一部を開くことにより、 248 GB (または 21 億行)を超えるファイルを開くことができるようになりました。ラージ ファイル コントローラーを使用すると、開くファイルの開始点、終了点、および範囲を指定できます。また、ファイルを開くのを停止し、ファイルの実際のサイズと使用可能な一時ディスクのサイズを監視することもできます。

無料じゃないけど..

于 2013-02-26T15:35:00.550 に答える
1

FAR コマンダーは大きなファイルを開くことができることがわかりました (私は 4.2 GB の xml ファイルを試しました)。ファイル全体をメモリにロードせず、高速に動作します。

于 2015-03-19T13:47:36.043 に答える
1

Windows、Unix、または Mac の場合は? Mac または *nix では、コマンド ラインまたは GUI バージョンの emacs または vim を使用できます。

Mac の場合: 大きなファイルを適切に処理するための TextWrangler。私は、Windows のランドスケープに十分に精通しておらず、そこを支援することができません。

于 2008-09-19T15:28:31.860 に答える
1

膨大なログ ファイルに直面したとき、全体を見ようとせず、Free File Splitterを使用します

確かに、これは解決策ではなく回避策であり、ファイル全体が必要になる場合があります。しかし、多くの場合、大きなファイルから数行しか表示する必要がなく、それも問題のようです。そうでない場合は、他の人がそのユーティリティを便利だと思うかもしれません。

たとえば、膨大なテキスト ファイルを表示できるビューアーは、Excel に読み込んでオートフィルターを使用する場合にはあまり役に立ちません。私たちは皆、問題を解決できるように問題を小さな部分に分解することに 1 日を費やしているため、同じ原則を大きなファイルに適用することは、私には論争の的ではありませんでした。

于 2008-09-19T15:43:25.803 に答える
1

次のコマンドで 5 GB のファイルを (すばやく) 開きました。

1) Hex Editor Neo

2) 010 エディター

于 2015-07-15T15:10:25.003 に答える
1

HxD -- これは hexeditor ですが、その場での編集が可能で、大きなファイルをバーフしません。

于 2011-10-05T16:41:05.983 に答える
0

質問にはさらに詳細が必要です。
ファイル(ログファイルなど)を確認するだけですか、それとも編集しますか?
ロードしたいファイルのサイズ以下のメモリがありますか?
たとえば、アセンブリ言語で記述された非常に小さなテキストエディタであるTheGunは、「有効なファイルサイズの制限はなく、ロードできる最大サイズは、使用可能なメモリとファイルのロード速度によって決まります。[.. 。]ファイルの読み込みと保存の両方で速度が最適化されています。

メモリ制限を抽象化するために、マップトメモリを使用できると思います。ただし、ファイルを編集する必要がある場合は、ローカルの変更をメモリに保存し、保存時にチャンクごとに適用するなど、巧妙な方法を使用する必要があります。場合によっては効果がない可能性があります(たとえば、大規模な検索/置換)。

于 2008-09-19T15:48:08.617 に答える
0

4GファイルのTextPadにも問題があります。Notepad++はうまく機能します。

于 2008-10-05T02:55:32.060 に答える
0

テキストパッドは、そのサイズのファイルを開くときにもうまく機能します。3 ~ 5GB の範囲の非常に大きなログ ファイルを処理する必要がある場合、私は何度もこれを行いました。また、grep を使用して価値のある行を引き出してから、それらを確認するとうまくいきます。

于 2008-09-19T15:43:54.057 に答える
-1

使用しているOSとCPUは?32 ビット OS を使用している場合、システム上のプロセスは物理的に 4GB を超えるメモリをアドレス指定できません。ほとんどのテキスト エディタはファイル全体をメモリにロードしようとするため、目的の機能を備えたエディタが見つかるとは思えません。アウトオブコア処理、つまり一度にファイルのチャンクをロードできる、非常に洗練されたテキスト エディタである必要があります。

64 ビットの CPU と 64 ビットのオペレーティング システムを搭載したコンピューターで 64 ビットのテキスト エディターを使用すると、このような巨大なファイルを読み込むことができる場合があります。また、スワップ パーティションまたはスワップ ファイルに十分なスペースがあることを確認する必要があります。

于 2008-09-19T15:32:54.160 に答える
-1

なぜ 4 GB 以上のファイルをメモリにロードする必要があるのですか? それができるテキスト エディタを見つけたとしても、あなたのマシンには 4 GB のメモリがありますか? また、物理メモリが 4 GB をはるかに超えていない限り、マシンの速度が大幅に低下し、スワップ ファイルが狂ってしまいます。

では、なぜ 4 GB 以上のファイルが必要なのでしょうか? それを変換したい場合、または検索と置換を行いたい場合は、それを実行するための小さな簡単なプログラムを作成する方がよい場合があります。

于 2008-09-19T15:33:50.413 に答える
-1

Emacsは巨大なファイル サイズを処理でき、Windows または *nix で使用できます。

于 2008-09-19T15:29:11.610 に答える
-2

notepad++も好きです。

于 2008-09-19T15:33:09.480 に答える