4GB 이상의 파일을로드 할 수있는 텍스트 편집기를 찾고 있습니다. Textpad가 작동하지 않습니다. 나는 그것의 사본을 소유하고 그것의 지원 사이트에 갔지만, 그것을하지 않습니다. 새 하드웨어가 필요할 수도 있지만 그것은 다른 질문입니다. 편집자는 무료이거나 비용이들 경우 $ 30를 넘지 않아야합니다. Windows의 경우.
4GB 이상의 파일을로드 할 수있는 텍스트 편집기를 찾고 있습니다. Textpad가 작동하지 않습니다. 나는 그것의 사본을 소유하고 그것의 지원 사이트에 갔지만, 그것을하지 않습니다. 새 하드웨어가 필요할 수도 있지만 그것은 다른 질문입니다. 편집자는 무료이거나 비용이들 경우 $ 30를 넘지 않아야합니다. Windows의 경우.
답변:
괴물 (런 어웨이) 로그 파일 (20GB 이상)을 확인해야했습니다. 모든 크기의 파일과 함께 작동 할 수있는 hexedit FREE 버전 을 사용했습니다 . 또한 오픈 소스입니다. Windows 실행 파일입니다.
Jeff Atwood는 http://www.codinghorror.com/blog/archives/000229.html 에 이에 대한 게시물을 가지고 있습니다.
그는 결국 Edit Pad Pro를 사용했습니다. IDE가되는 것입니다. "
나는 종종 대용량 파일 (10 Gigas +)을 처리해야하기 때문에이 게시물을 여러 번 우연히 발견했습니다.
버그가 많고 제한적인 프리웨어에 지 쳤고 평가판이 만료 된 후 값 비싼 편집자에게 비용을 지불 할 의사가 없었던 (결국 그럴 가치가 없음) VIM for Windows 를 큰 성공과 만족으로 사용했습니다.
텍스트 파일을 다룰 때 생각할 수있는 모든 기능 (검색, 바꾸기, 읽기 등)을 통해 완전히 사용자 정의 할 수있는이 요구에 완벽합니다.
나는 아무도 대답하지 않았다는 것에 매우 놀랐습니다 (이전 답변을 제외하고 MacOS의 경우) ...
기록을 위해 나는 현명하게 조언 한이 블로그 게시물 에서 우연히 발견 했습니다.
4G 파일을 처리하는 것은 정말 어렵습니다. 나는 더 큰 텍스트 파일을 처리하곤했지만 그것을 내 편집기로 불러 온 적이 없었다. 이전 회사에서 주로 UltraEdit를 사용했지만 지금은 Notepad ++를 사용하지만 편집해야하는 부분 만 얻을 수 있습니다. (대부분의 경우 파일을 편집 할 필요가 없습니다).
왜 그렇게 큰 파일을 편집기에로드하고 싶습니까? 이 크기의 파일을 처리 할 때 GNU Core Utils를 사용했습니다. 내가 그 파일에 대해 수행 한 가장 일반적인 작업은 head (상위 250k 라인 등을 얻기 위해), tail, split, sort, shuf, uniq 등이었습니다. 정말 강력합니다.
GNU Core Utils로 할 수있는 일이 많이 있습니다. 나는 새로운 편집자 대신 그것들을 확실히 추천 할 것입니다.
6GB mysqldump 파일을 읽으려고 시도한 후 가장 좋아하는 :
PilotEdit Lite http://www.pilotedit.com/
때문에:
내가 시도한 기타 ...
EmEditor Pro 평가판은 매우 인상적이었고 파일은 거의 즉시 열렸지만 불행히도 내 요구 사항에 비해 너무 비쌌습니다.
EditPad Pro 는 전체 6GB 파일을 메모리에로드하고 모든 것을 크롤링하는 속도를 늦췄습니다.
Windows, Unix 또는 Mac의 경우? Mac 또는 * nix에서는 emacs 또는 vim의 명령 줄 또는 GUI 버전을 사용할 수 있습니다.
Mac의 경우 : TextWrangler는 대용량 파일을 잘 처리합니다. 나는 Windows 환경에 대해 충분히 이해하지 못하여 도움을 줄 수 있습니다.
큰 파일을 편집하기보다보기 만하면 전체 파일을 메모리에로드하지 않고 한 번에 한 덩어리 씩 파일을 읽는 프리웨어 프로그램이 몇 개 있습니다. 대용량 (> 5GB) 파일을 읽어야 할 때 사용합니다.
swiftgear의 대형 텍스트 파일 뷰어 http://www.swiftgear.com/ltfviewer/features.html
Team Walrus의 Big File Viewer.
마지막 링크에 대한 링크를 직접 찾아야합니다. 왜냐하면 나는 초보자 인 하이퍼 링크를 최대 하나만 게시 할 수 있기 때문입니다.
방대한 로그 파일에 직면했을 때 전체를 보지 않고 Free File Splitter를 사용합니다.
분명히 이것은 해결책이 아닌 해결 방법이며 전체 파일이 필요한 경우가 있습니다. 그러나 종종 나는 더 큰 파일에서 몇 줄만 볼 필요가 있으며 그것은 당신의 문제인 것 같습니다. 그렇지 않다면 다른 사람들이 그 유틸리티를 유용하다고 생각할 것입니다.
예를 들어 자동 필터를 사용하기 위해 Excel에로드하려는 경우 방대한 텍스트 파일을 볼 수있는 뷰어는별로 도움이되지 않습니다. 우리 모두는 문제를 해결하기 위해 문제를 작은 부분으로 나누는 데 하루를 보내기 때문에 큰 파일에 동일한 원칙을 적용한다고해서 논쟁의 여지가 없었습니다.
Textpad는 해당 크기의 파일을 열 때도 잘 작동합니다. 3-5GB 범위의 매우 큰 로그 파일을 처리해야 할 때 여러 번 수행했습니다. 또한 grep을 사용하여 가치있는 줄을 뽑은 다음 그 작업을 훌륭하게 살펴보십시오.
질문에 더 자세한 정보가 필요합니다.
파일 (예 : 로그 파일)을 보거나 편집 하시겠습니까?
로드하려는 파일 크기보다 메모리가 많거나 적습니까?
예를 들어 어셈블리 언어로 작성된 매우 작은 텍스트 편집기 인 TheGun 은 " 유효한 파일 크기 제한이 없으며 여기에로드 할 수있는 최대 크기는 사용 가능한 메모리와 파일로드 속도에 따라 결정됩니다. [.. .] 파일 불러 오기와 저장 모두에 최적화 된 속도입니다. "
메모리 제한을 추상화하기 위해 매핑 된 메모리를 사용할 수 있다고 가정합니다. 그러나 파일을 편집해야하는 경우 메모리에 로컬 변경 사항을 저장하고 저장할 때 청크 단위로 적용하는 것과 같은 영리한 방법을 사용해야합니다. 경우에 따라 효과가 없을 수 있습니다 (예 : 대규모 검색 / 교체).
4G 파일에서도 TextPad에 문제가 있습니다. Notepad ++는 잘 작동합니다.
Emacs 는 방대한 파일 크기를 처리 할 수 있으며 Windows 또는 * nix에서 사용할 수 있습니다.
어떤 OS와 CPU를 사용하고 있습니까? 32 비트 OS를 사용하는 경우 시스템의 프로세스는 물리적으로 4GB 이상의 메모리를 처리 할 수 없습니다. 대부분의 텍스트 편집기는 전체 파일을 메모리에로드하려고하기 때문에 원하는 작업을 수행 할 수있는 파일을 찾을 수 없을 것입니다. 아웃 오브 코어 처리를 수행 할 수있는 매우 멋진 텍스트 편집기 여야합니다. 즉, 한 번에 파일 청크를로드 할 수 있습니다.
64 비트 CPU 및 64 비트 운영 체제가 설치된 컴퓨터에서 64 비트 텍스트 편집기를 사용하면 이러한 대용량 파일을로드 할 수 있습니다. 그리고 스왑 파티션이나 스왑 파일에 충분한 공간이 있는지 확인해야합니다.
4GB 이상의 파일을 메모리에로드하려는 이유는 무엇입니까? 그렇게 할 수있는 텍스트 편집기를 찾았더라도 컴퓨터에 4GB의 메모리가 있습니까? 그리고 실제 메모리가 4GB를 초과하지 않는 한 컴퓨터 속도가 많이 느려지고 파일 스왑이 미치게됩니다.
그렇다면 왜 4GB 이상의 파일을 원하십니까? 변환하거나 검색 및 바꾸기를 원할 경우 작은 빠른 프로그램을 작성하는 것이 좋습니다.
나는 또한 notepad ++를 좋아 합니다.