여기에는 상당히 간단한 문제가 있습니다. 하나의 거대한 큰 줄(~150,000자)로 구성된 텍스트 조각이 있습니다. 줄 바꿈이 없고 고정 길이의 플랫 파일(즉, 프로그램에 의해 생성됨 COBOL)이므로 줄 바꿈을 도입하는 것은 어색할 뿐만 아니라 파일을 변경하려고 할 때 적극적으로 도움이 되지 않습니다.
대부분의 텍스트 편집기는 작동하기는 하지만 그렇게 큰 한 줄( less좋지 않음, Gedit좋지 않음, 좋지 않음, 싫다고 nano들었음 등) 때문에 어려움을 겪습니다.vim
내가 작업 중인 데이터에 더 적합한 편집기에 대한 제안이 있는 사람이 있나요? 단 한 줄이지만 일반 길이의 줄이 포함된 1GiB+ 텍스트 파일보다 더 많은 문제를 야기합니다.
null 바이트가 발견될 때 barf 와 함께 작동 EBCDIC하고 작동하지 않거나 다시 쓸 때 이를 엉망으로 만드는 경우(일부 필드는 이진 인코딩된 십진수임) 더 좋을 것입니다.
이는 원시 크기 측면에서 큰 파일에 관한 것이 아니라(파일에 한 줄만 포함되어 있음) 대부분의 편집기가 매우 긴 줄을 처리하도록 최적화되어 있지 않다는 사실에 관한 것입니다.
답변1
귀하가 설명하는 방식과 같은 파일은 실용적인 목적으로 바이너리 파일처럼 작동하므로 그렇게 취급해야 한다고 생각합니다.
16진수 편집기로 공격할 수 있지만 EBCIDC 부분에는 도움이 되지 않습니다.
이 파일을 많이 편집해야 하고 고정 길이 레코드 형식에 익숙하다면 Perl이나 다른 언어로 뭔가를 만드는 것이 시간을 할애할 가치가 있을 수 있습니다. UTF-8 등을 EBCIDC로 변환하는 모듈이 있으며 이 파일의 특정 형식에서 작동합니다.
답변2
나는 실제로방금 시도했습니다vim을 한 줄에 150,000자로 입력했는데 비단처럼 매끄럽게 실행되었습니다.
그래서 나는 당신이 단지 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
시도 해봐:JEdit - 프로그래머 편집자
일부 고급 버퍼링 기능과 고도로 최적화된 I/O를 갖추고 있지만 시작하는 데 시간이 걸립니다(JVM으로 인해). 나는 적어도 Debian에서는 아무런 문제 없이 1GiB 이상의 파일을 보고 편집하는 데 그것을 사용해 왔습니다. 하지만 Windows에서 잘 작동할 것이라고 보장할 수는 없습니다... :)