2009-07-17 6 views
11

좋아요, XML에 관한 몇 권의 책을 읽었으며 침을 뱉어내는 프로그램을 썼습니다. 그러나 여기에 질문이 있습니다. 쉼표로 분리 된 파일과 XML 파일 모두 "사람이 읽을 수있는"파일입니다. 하지만 일반적으로 쉼표로 구분 된 파일은 XML 파일보다 눈에 더 쉽습니다. 태그는 일반적으로 데이터보다 많은 공간을 차지합니다. 이것은 내가 읽고있는 것을 모호하게 만드는 것처럼 보입니다. 형식은 쉼표로 구분 된 파일로 한 줄의 텍스트에 포함 할 수있는 동일한 정보를 포함하는 페이지를 취할 수 있습니다. 쉼표로 구분 된 파일은 분석하기가 훨씬 덜 복잡합니다. 그래서 진짜 질문은 왜 XML입니까? 모든 멋진 애들이하고 있기 때문에?XML과 쉼표로 구분 된 텍스트 파일

+0

사용할 수있는 도구가 있다는 개념은 처음부터 널리 채택되었다는 아이디어를 기반으로합니다. 그러나 구문 관점에서, 왜? 동일한 정보가 훨씬 더 간결한 형식으로 표현 될 수 있습니다. 3 페이지의 정보를 얻기 위해 보일러 플레이트 10 페이지를 읽는 것과 같습니다. 그것은 내가 처음에 사용 된 이유에 대한 좋은 이유를주지 않는다. – NoMoreZealots

답변

11

이들은 두 가지 옵션이 아니며 xml보다 훨씬 가벼운 JSON 또는 YAML을 사용할 수도 있습니다.

일반적으로 많은 특수 문자가있는 단순한 표 형식의 데이터가있는 경우 CSV는 나쁜 선택이 아닙니다. 구조화 된 데이터의 경우 다른 3 개 중 하나를 사용하는 것이 좋습니다.

+0

+1 : 많은 사람들은 거의 똑같은 일을하는 XML 외에 형식이 있다는 것을 잊어 버립니다. 나는 YAML로 일한 적이 없지만 JSON은 XML에 대한 훌륭한 "가벼운"대안입니다 (대부분의 프로그래밍 언어에서 구문 분석하기는 더 쉽습니다). –

+0

오, 이런, 멋지다. 나는 YAML과 JSON을 찾아 보았다. 그리고 그것은 정말로 나에게 나의 대답을 준다. XML보다 비 특종 형식이 훨씬 낫습니다. – NoMoreZealots

+0

많은 경우 JSON이 XML보다 확실히 작업하는 편이 낫습니다. 여기서 XML의 장점은 표준화 된 스키마로 작업 할 때와 스키마를 함께 통합 할 때입니다 (네임 스페이스는 훌륭한 아이디어입니다!). 그 중 어떤 것도 필요로하지 않는 경우, 특히 자신이 필요로하는 임시 형식을 만드는 경우 JSON 또는 YAML로 이동하십시오. – jcdyer

4

모두해야 할 일에 달려 있습니다. 간단한 "평면"행 구조보다 데이터 구조에 더 복잡한 것이 필요한 경우. 예를 들어 계층 적 데이터의 경우 XML은 훌륭한 선택입니다.

6

XML은 복잡하고 구조적이며 계층적인 표현을 지원합니다. CSV가 쉽게 저장할 수있는 것과는 거리가 멀다.

객체 지향 환경에서 복잡한 객체 그래프를 생각해보십시오. 그것은 XML 문서로 꽤 쉽게 직렬화 될 수 있지만 CSV는 그런 것을 처리 할 수 ​​없습니다.

+0

좋아, 나는 상반 대 CSV를 줄 것이다. 그러나 복잡한 객체 지향 환경에 대해 생각해 보면 데이터 표현을위한 C++ 또는 Java 구문이 훨씬 가벼워졌습니다. 문법이 훨씬 더 깔끔하기 때문에 실제로 "C-Structure"스타일 데이터 파서를 작성하려고했습니다. – NoMoreZealots

2

CSV는 절대로 표준이 아니 었습니다. 단지 똑같은 빠르고 더러운 방법으로 많은 사람들이 독립적으로 생각해 냈습니다. 물론이 사람들 중 일부는 다른 사람들보다 더 똑똑했고 캐릭터를 탈출해야한다는 것을 깨달았지만 다른 사람들은 그렇지 않았다. MSSQL조차도 CSV를 부적절하게 수출합니다. 문서화 된 올바른 방법으로 XML을 수행 할 수 있습니다. 그렇다면 올바른 일이나 다른 사람의 응용 프로그램을 사용하는 경우 또는 그것을 수락하지 않는 경우 "내 잘못이 아닙니다."라고 말할 때 어떤 영향력을 행사할 수 있습니다.

+0

좋은 예 : CSV에 쉼표가 포함 된 데이터는 어떻게 처리합니까? XML은 이런 경우를 다루는 올바른 방법을 문서화했습니다. – russau

+0

CSV는 표준입니다 : http://www.rfc-editor.org/rfc/rfc4180.txt – pmf

+0

그래도 XML을 사용하는 이유는 아닙니다. –

1

Xml은 계약 (스키마 또는 DTD)에 대해 유효성을 검사 할 수 있습니다.

1

XML은 또한 주위의 무료 기술이 있습니다 XMLDOM, XPath에, XSLT, XSD, XML 스키마

16

장점

장점 XML의 수는 CSV 이상이 있습니다

  • 계층 데이터를 조직
  • 자동 데이터 유효성 검사 (XML 스키마 또는 DTD)
  • Eas ILY
  • 은 기업 간 통신을 단순화
  • 쉬운
  • 객체 지속성 (마샬링)에 대한
  • 적합한 XML-RPC와 함께 사용할 수 있습니다
  • 관계 구조를 파악하기 위해 (사용 XSL) 포맷을 변환
  • 유용한 관련 기술 (XPath는, DOM) 최신 웹
  • 추출물이, 변환 브라우저 및로드 (ETL) 툴
  • 긴밀한 통합 뒤로 형식 호환성 (버전 속성)
  • 디지털 서명
  • 그것은 완전히 문제 도메인과 당신이 해결하려고에 따라 달라집니다

파일.

마지막 항목은 웹 페이지를 작성할 때 많은 사람들이 그리워 무언가이다. 대용량 데이터 저장소가있는 상황을 고려해보십시오. 노래에는 아티스트, 앨범, 분당 비트 등이 있습니다. 데이터를 XML로 내보내고 간단한 스타일 시트를 작성하여 XML을 XHTML로 렌더링 한 다음 XML 페이지에서 브라우저를 가리킬 수 있습니다. 브라우저는 XML을 웹 페이지로 렌더링합니다.

CSV로 할 수 없습니다.

단점

Spolsky 조엘은 XML 복잡한 데이터 저장소로 잘못 선택 이유에 a great article있다 :이 느립니다. (단일 CPU 명령으로 이전 레코드 또는 다음 레코드를 검색 할 수있는 데이터베이스와 달리 XML 문서의 레코드를 훨씬 빨리 탐색 할 수 있습니다.) 아마도 이것은 waiting 18 months으로 해결되는 최적화 문제로 간주 될 수 있습니다. 따라서 : 느린

  • 는 가독성을 저하 할 수있는 다른 형식보다
  • 문법적 중복을 구문 분석
  • 스토리지 비용에 영향을 미칠 수
  • 문서 팽창
  • 쉽게
  • 저조한 (비 계층) 데이터 구조를 중복 모델링 할 수 없습니다 설계된 XML 파일 형식은 드문 일이 아닙니다. (필자의 경험에 의하면, 표창장이 필요합니다)

관련 질문

다음을 참조하십시오 : Why Should I Use A Human Readable File Format.

+1

+1 정확하게 XML에 관한 도구 및 사양의 전체 생태계가 있습니다. 또 하나 : XML 디지털 서명은 데이터를 인증하는 표준 방법을 제공합니다. http://www.w3.org/Signature/ –

4

음 XML은 사람이 읽고 사람이 편집 할 수 있습니다. XML 파일을보고 정확히 무엇인지 알 수 있습니다. CSV 파일은 사람이 읽을 수 있지만 각 값이 무엇을 의미하는지 실제로 알지 못합니다.

예를 들어 사용자 계정을 저장하고 있다면 어떤 방법을 사용 하시겠습니까?

<user> 
    <username>ryeguy</username> 
    <password>abc123</password> 
    <regdate>3-4-08</regdate> 
    <email>[email protected]</email> 
</user> 

OR 물론

ryeguy,abc123,3-4-08,[email protected] 

, 이것은 단지 예이지만, 30 개 필드 정도로 상상!

악화되었거나 하위 필드를 만들면 어떻게됩니까?

<user> 
    <username>ryeguy</username> 
    <password>abc123</password> 
    <regdate>3-4-08</regdate> 
    <email>[email protected]</email> 
    <posts> 
     <post> 
      <id>34</id> 
      .... 
     </post> 
    </posts> 
</user> 

그건 엉덩이에 CSV를 넣는 것입니다. 곧 당신은 자신의 질의어를 작성하게 될 것입니다.

+0

잘 모르겠습니다. 파일 형식이 실제로 실제 DATA보다 많은 공간을 차지합니다. 데이터 즉, 실제로 알아야 할 것들! 프로그램 대신 손으로 직접 작업하는 경우 " 데이터"는 내 HD를 방해하고 큰 파일의 경우 클럭 사이클을 낭비해야하는 것입니다. 어쨌든 실제로 읽을 수는 없습니다. . – NoMoreZealots

+0

첫 번째 줄에 "username, password, regdate, email"와 같은 머리글 행을 넣고 필드를 실제로 기억하지 못하게 할 수 있습니다. – erjiang

3

XML이 사람이 읽을 수 있다는 사실은 사람이 직접 읽거나 (심지어 편집 한) 아이디어로 만들어진 것을 의미하지 않습니다.

XML에는 여러 가지 경우에 적합한 좋은 속성 집합이 있습니다. 특히 이러한 속성이 필연적으로 가져 오는 추가 부담을 처리 할 인력이있는 경우 : 유효성 검사, 잘 정의 된 표준, 많은 매우 융통성있는 아키텍처이기 때문에 많은 프로그램에서 사용하는 트리 모델과 잘 일치합니다. 인간의 가독성은 디버깅을 단순화하고 (바이너리 파일의 디버깅을 시도 ...), 사소한 경우에 대한 검사와 작은 변경을 추가하는 부가 가치입니다. 반면에

CSV 많은 방언이 존재하지만, 빠르고 쉬운 선형이며, 그것을 잘 분석하는 것은 사소한에서 까지입니다 (그것이 사소한 보이는 것을 및 추가 문제와!). 데이터 테이블과 관련된 대부분의 응용 프로그램의 경우 CSV가 완벽한 선택입니다.

그러나 일반적으로 XML로 해결할 수있는 데이터 표현의 경우가 있지만 CSV (예 : 트리)로는 해결할 수 없습니다. 반면에 CSV로 표현할 수있는 모든 데이터는 XML로 표현 될 수도 있지만 공간, 구문 분석의 용이성 등의면에서 더 효율적이라는 보장은 없습니다. 그것은 당신의 형식에 대한 "자유"의 문제입니다. XML은 자유도가 높습니다. CSV가 낮습니다. XML의 과장은 또한이 사실과 관련이 있습니다.

해머 증후군의 피해자가되지 마십시오. 망치 (XML)가있을 때 모든 것이 손톱처럼 보입니다 (XML로 해결해야하는 것). 현실은 매우 다르고 미묘합니다. XML은 멋지지만 모든 문제에 대한 해답이 아닙니다. 당신이 CSV를 통해 XML을 선호 할 이유 중

+0

나는 망치 덧글을 좋아한다. Bob Fett Bob, Fett, 100에 비해서는 멍청한 것 같습니다. – NoMoreZealots

1

는 (물론 손에 작업에 따라 다름) : * 거의 모든 플랫폼과 언어, 쓰기, 구문 분석 및 XML을 조작, 독서에 대한 기존의 라이브러리를 가지고있다. * XML에는 모든 문자를 인코딩하기위한 잘 정의 된 규칙이 있습니다. CSV는 데이터의 일부인 쉼표를 인코딩하는 방법과 같은 모호성이 있습니다. * XML은 데이터가 표 (행과 열)처럼 보이면 CSV가 가장 유용한 다양한 데이터 모양 (계층 적)을 지원합니다.

2

XML은 콘텐츠를 설명하고 다양한 언어로 지원되는 라이브러리를 보유하고 있지만 비 대한 수 있습니다. csv의 수신 측이 레이아웃을 알고 있고 그것이 표 형식이라면, 나는 그것에 대해 잘못된 것을 보지 못합니다.

1

XML은 TREE 기반이고 CSV는 TABLE 기반이므로이 경우 기본 구분을 생각하고 있습니다.

즉, XML로 복잡한 TREE 구조를 중첩하거나 다시 중첩 및 생략하고 일반적으로 만들 수 있지만 CSV에서는 간단한 2D 테이블 만 만들 수 있습니다.

관련 문제