我這裡有一個相當簡單的問題：我有一段文本，它是一個巨大的大行（約 150,000 個字元）。沒有換行符，而且它是一個固定長度的平面文件（即它是由程式生成的COBOL），因此引入換行符不僅很尷尬，而且如果我試圖對文件進行更改，它也毫無幫助。
大多數文字編輯器都在處理這麼大的一行（less不喜歡它，Gedit不喜歡它，nano不喜歡它，我聽說vim不喜歡它，等等），儘管它們確實有效。
有人對更適合我正在使用的數據的編輯器有什麼建議嗎？它只是一行，但它仍然比具有正常長度行的 1GiB+ 文字檔案會導致更多問題...
EBCDIC如果它在遇到空位元組時能夠使用而不是 barf，或者在寫回時破壞它們（某些欄位是二進位編碼的十進位），那就更好了。
請注意，這並不是關於原始大小很大的文件 - 該文件僅包含一行 - 而是關於大多數編輯器沒有針對處理很長的行進行優化的事實。
答案1
我認為，出於實際目的，像您描述的那樣的文件就像二進位一樣，您應該這樣對待它。
您可以使用十六進位編輯器來攻擊它，但這對您的 EBCIDC 部分沒有幫助。
如果您必須對此文件進行大量編輯並且非常熟悉其固定長度記錄格式，那麼可能值得您花時間用 Perl 或其他語言編寫一些東西（我建議使用 Perl，因為它很舊並且很可能會有將UTF- 8 等轉換為EBCIDC 的模組），可以使用該檔案的特定格式。
答案2
其實我剛剛嘗試過vim 在一個單行 150000 個字元的檔案上運行，運行流暢。
所以我想你真的應該嘗試一下，如果你不這樣做只是因為you heard vim doesn't like such kind of files。
這是我獲取文件的方式：
seq 150000 | while read num; do echo -n "b" ; done > megaline.txt
答案3
我在 emacs 安裝中嘗試了與 Dakatine 相同的方法，效果很好。沒有掛斷，什麼都沒有。如果您正在編輯純文字（即不進行程式語言模式所需的任何分析，請參見text-mode），那麼鎖定 emacs 將會非常非常困難。您在 Eclipse 中看到的行為可能反映了這樣一個事實：Eclipse 試圖在呈現文字時對文字進行某種分析 — Gedit 也是如此。我也無法重現你的問題less——它對我來說很好。
答案4
它具有一些高級緩衝功能和高度優化的 I/O，但需要一段時間才能啟動（由於 JVM）。我一直在使用它來查看和編輯超過 1GiB 的文件，沒有任何問題 - 至少在 Debian 上是這樣。但我不能保證它在 Windows 上的表現也一樣好......:)