非常に長い行と固定長のレコードを処理できるLinuxテキストエディタ
ここにはかなり単純な問題があります。1つの巨大な大きな行（約150,000文字）であるテキストがあります。改行はなく、固定長のフラットファイル（つまり、COBOLプログラムによって生成されたもの）であるため、改行を導入するのは厄介なだけでなく、変更を加えようとしている場合は積極的に役に立ちません。ファイル。
ほとんどのテキストエディタは、1行の大きさに苦労しています（lessは気に入らない、Geditは気に入らない、nanoは気に入らない、私はvimが気に入らないなど）と聞きましたが、機能します。
私が扱っているデータにより適したエディターについて誰か提案がありますか？たった1行ですが、通常の長さの行を持つ1GiB +テキストファイルよりも多くの問題が発生します...
Nullバイトに遭遇したときにbarfではなくEBCDICで動作するか、書き戻すときにそれらをマングルすると、さらに良いでしょう（一部のフィールドはバイナリエンコードされた10進数です）。
これは、生のサイズが大きいファイル（ファイルには1行しか含まれていない）ではなく、ほとんどのエディターが非常に長い行に対応するように最適化されていないという事実に注意してください。
あなたが説明しているようなファイルは、実用的な目的では、バイナリファイルのように機能するので、そのように扱う必要があると思います。
16進エディターで攻撃することもできますが、EBCIDCの部分では役に立ちません。
このファイルで多くの編集を行う必要があり、その固定長のレコード形式に精通している場合は、Perlまたは別の言語で何かを作成する価値があるかもしれません（Perlは古く、このファイルの特定の形式で動作するUTF-8などをEBCIDCに変換するモジュールがあります。
私は実際に試したばかりです 150000文字の1行のファイルでvimを実行すると、シルクのようにスムーズに実行されました。
だから、もしあなたがyou heard vim doesn't like such kind of files。
これが私のファイルを取得した方法です：
seq 150000 | while read num; do echo -n "b" ; done > megaline.txt
EmacsをインストールしてDakatineと同じ方法を試しましたが、うまくいきました。ハングアップも、何もありません。プレーンテキストを編集している場合（つまり、プログラミング言語のモードで必要な種類の分析を行っていない場合は、text-mode）、emacsをロックするのは本当に本当に難しいでしょう。 Eclipseで見られる動作は、おそらくEclipseがテキストをレンダリングするときにテキストに対して何らかの分析を行おうとしているという事実を反映しています。Geditの場合も同様です。また、lessで問題を再現することもできません。問題はありません。
試してみてください： JEdit-プログラマーエディター
いくつかの高度なバッファリング機能と高度に最適化されたI/Oがありますが、起動に時間がかかります（JVMのため）。私はこれを使って1GiBファイルを問題なく表示および編集してきました-少なくともDebianでは。私はそれがウィンドウズで同じように動作することを保証することはできません... :)