고정 폭 파일 형식이 아직 사용중인 이유는 무엇입니까?

Question

고정 폭 파일 형식에 XML과 같은 장점이 있습니까? 필자는 XML이 동일한 양의 데이터를 저장하기 위해 더 많은 디스크 공간을 차지할 것으로 생각하지만 파일을 압축 할 수도 있습니다. 이론적으로 파일에있는 데이터의 특정 부분을 읽을 수도 있습니다 (그 바이트 만 가져 오기만하면됩니다). 하지만 그 외에는 또 뭐야?

Answer 1

XML을 처리하는 것 (메모리 구조를 읽고로드하는 것뿐만 아니라 XML 파일에서 정규식 검색 또는 단순한 고정 너비 또는 구분 된 파일을 생각하는 것, 또는 수동으로 빠른 수정을 나쁜 것으로 만드는 것 등) 데이터)은 고정 너비 파일보다 복잡합니다. 물론 지금 할 수있는 라이브러리가 많이 있지만 작업중인 플랫폼이 없으면 XML 파서 또는 실제로 읽는 프로그램을 작성 하시겠습니까? n 바이트 위치 x?

Answer 2

아마도 XML을위한 파서, JSON (기타)이 모든 플랫폼에 존재하기 때문에 대부분 레거시 이유로 인해 발생했을 것입니다.

이론적으로 고정 너비 형식은 공간 효율성이 좋습니다. 그리고 조금 더 읽기. 그러나 이것들은 상당한 이점처럼 보이지 않습니다.

CSV와 같은 표 형식 (고정 너비는 아니지만)의 포맷은 조금 더 압축 된 표현과 더 나은 가독성을 결합하여 용도가 있습니다. CSV는지도/축소 스타일 작업에 아주 잘 작동합니다.

Answer 3

XML이 복잡합니다. 특히 스키마에 따라 유효성 검사를 수행하는 경우에 특히 그렇습니다. 다른 사람이 이미 XML 파서를 사용할 수 있기 때문에 이것은 중요 해 보이지 않을 수도 있습니다. 그러나 이것은 상당히 많은 프로세싱을 추가하는데, 이는 더 오래 걸린다는 것을 의미합니다. 이것은 많은 경우에 문제가되지 않을 수도 있지만 때로는 발생할 수 있습니다.

하나의 정수를 사용자 정의 파일 형식으로 저장하려는 경우 단 4 바이트 만 필요하며로드하려는 경우이 4 바이트를 메모리에 복사하면됩니다 (파일 형식과 플랫폼이 동일한 엔디안). 그러나 XML에서는 10-30 바이트 정도 걸릴 수 있습니다. 그리고 그것을로드하는 것은 문자열을 비교하고 정수 및 아마도 더 많은 십진수 표현을 파싱하는 것을 의미합니다.

이러한 성능과 저장소 크기 차이는 고려하기에는 너무 미흡 할 수 있습니다. (사용자 지정 형식을 고안하는 데 필요한 작업이 중요하지는 않지만) 많은 경우에 이러한 차이는 입니다. do 문제를 해결하십시오.

예를 들어, 일부 데이터 전송에 SMS 메시지를 사용하는 시스템이 있습니다. 이는 메시지 당 140 바이트 (!)라는 의미입니다. 그리고 그 메시지를 보내고받는 장치에는 GB의 메모리와 GHz의 CPU가 없습니다. 이 경우 모든 비트가이며 XML을 사용하지 않는 것이 좋습니다.

Answer 4

데이터가 크면 (기가/테라 바이트) 고정 폭 형식의 파일은 MUCH 일 수 있습니다.

각 레코드 및 필드의 크기가 고정되어 있으므로 백만 번째 행 (예 :)을 찾고 거기에서 몇 개의 레코드를 읽을 수 있습니다. 전체 파일을 메모리 맵핑하여 메모리에 맵핑하고 모든 것에 대한 효율적이고 쉬운 무작위 액세스를 얻을 수도 있습니다.

이러한 경우 XML 파일이 적합하지 않습니다.

Answer 5

나는 고정 폭의 힘을 깨달을 때까지 동일한 질문을했습니다.JSON이 파일 크기를 15GB와 2 + hrs로 늘리면서 수백만 개의 레코드를 파일로 추출하는 테이블이 있습니다. 고정 된 widht를 사용하는 동안 6.5GB와 15 분으로 내려갔습니다.

고정 너비를 추출하고 쓰는 것이 JSON보다 빠릅니다.

CSV도 시도했는데 여기서도 고정 폭이 더 좋았습니다.

Answer 6

나는 이것이 오래되었음을 알고 있지만, 나는 Fixed Width와 XML을 매일 다룬다. 당신이 할 수있는 거의 합계 그것을 :

XML = 가독성

고정 폭 = 속도와 낮은 자원 소비

XML은 주로 인간에 의해 가독성을위한 것입니다. 나는 구조와 타당성 확인에 대해 누구나 말하는 것을 신경 쓰지 않는다. 실제로 필요하지 않은 시스템을 실행하고 있고 파일을 읽는 사람이 앞뒤로 읽도록해야한다면 파일을 처리하는 데 소요되는 시간과 파일을 처리하는 데 소요되는 시간을 오버 헤드로 추가하는 것입니다. 크기에 영향을 주어 파일 전송에 걸리는 시간과 처리에 또 다른 영향을 미칩니다. 이 모든 것은 XML 파일을 소비하는 시스템의 메모리 사용에도 영향을 미칩니다. 그러나 XML에는 장점이 있습니다. 구조를 좀 더 느슨하게 정의 할 수 있습니다. 때로는 파일과 코드가 모두 255 자 길이의 필드를 필요로하지 않는다면 더 쉽습니다. 코드가 해당 제한 기간을로드한다는 것입니다. 또 다른 장점은 XML 내용의 요구 사항을 정의하는 XML 스키마가 XML에 있어야한다는 점입니다. 이는 하나의 API를 사용하는 여러 시스템을 갖는 데 도움이됩니다. 스키마를 개발자에게 제공 할 수 있다면 형식화되고 구조화 된 XML로 직렬화되는 형식화 된 객체를 매우 신속하게 만들 수 있습니다.

고정 폭은 속도와 최소 자원 소비를위한 것입니다. XML보다 설치하는 것이 지루할 수 있습니다. 모든 시스템이 고정 너비 파일의 "열"의 정확한 위치를 알 수 있도록합니다. 종종 모든 시스템이 동일한 열 또는 모든 열을 사용하는 것은 아니기 때문에 고정 너비의 내용을 완전히 이해하는 단일 시스템으로 끝납니다. 이로 인해 전송 된 파일 내용을 활용하여 API 또는 시스템을 확장하는 것이 어려울 수 있습니다. 그러나 필드 라벨, 태그, 원시 데이터가 없기 때문에 종종 작은 패키지를 전선을 통해 보낼 수 있습니다. 항상 그런 것은 아니지만 경우에 따라 텍스트 필드에 많은 양의 데이터가 저장되어 있지만 단락 길이가 입력 된 경우에는 큰 열 너비를 유지해야하는 텍스트 필드가 많이있을 수 있습니다. 이제 Fixed Width 파일에 여러 개의 공백이 있으며 XML은 실제로 전체 패키지 크기를 줄일 수 있습니다.

일반적으로 말하자면 XML은 가독성을위한 것입니다. 일반적으로 고정 폭 파일 또는 CSV 파일을 가져 와서 데이터가 의미하는 바를 즉시 파악할 수는 없습니다. 레이블이있는 XML 파일이있는 곳에서 할 수 있습니다.

내가 간 적이없는 많은 장점과 단점이 있지만, 여기에는 차이점의 실제 고기와 감자가 표시됩니다.