JSON과 YAML은 마크업 언어로 간주되나요? [폐쇄]

Question

두 기술에 대해 알아보려면 해당 사양을 읽어보는 것이 좋습니다.

YAML 사람들이 말하는 것은 일반적으로 정확합니다.표시언어 등상징물건 같은 것들의 경우. JSON의 정의가 문제를 가장 잘 설명한다고 생각합니다.

JSON(JavaScript Object Notation)은 경량 데이터 교환 형식입니다.

ㅏ표시언어표시텍스트 등.

마크업 언어가 전체 개체 구조(예: HTML 또는 XML)를 정의하는 데 자주 사용된다는 사실로 인해 둘 사이의 구분이 모호해집니다. 그러나 YAML 및 JSON과 같은 언어는 완전한 구조만 정의합니다(대형 개체 구조의 하위 부분이더라도). 컬렉션 등), 마크업이 문서에 전혀 없을 수 있습니다. HTML과 같은 경우 빈 문서에는 여전히 일부 구조가 포함되어 있습니다(예: 나중에 추가된 제약 조건으로 인해) <html> <head> ... </head> <body> ... </body> </html>. 기술적으로 말하면 태그가 전혀 없는 일반 텍스트 문서도 유효한 HTML입니다.

또 다른 흥미로운 접근 방식은가격 인하, 이는 분명히 마크업 언어이며 정보 교환을 위해 객체와 같은 구조를 정의하는 데 거의 사용되지 않습니다. 반면에 당신은TOML("Tom's Own Markup Language") 스스로를 마크업 언어라고 부르지만 분명히 그렇지 않습니다.

JSON이 마크업 언어로 사용되는 것을 본 적이 없으며 TOML도 마찬가지입니다. 기술적으로 YAML은 마크업 언어로 사용될 수 있지만 더 나은 솔루션이 있으므로 반드시 필요한 것은 아닙니다. 여러 마크업 언어는 어느 정도 좋은 개체 정의 언어(예: XML)를 만들어 주지만 데이터 정의 언어를 사용한 마크업은 일반적으로 나쁜 경험입니다. 그러나 어떤 경우에는 구별이 일반적으로 매우 모호합니다.표시두 가지를 모두 수행하는 언어(예: HTML) 어느 정도는 사용 사례에 따라 다릅니다. 렌더링, 네트워크 통신 등 주석에 주로 사용되는 언어이지만 여기서 주요 초점은 주석이 없는 콘텐츠이므로 마크업 언어입니다.

대신, 실제 콘텐츠가 "문서"가 아닌 단지 데이터로 간주된다면 이는 데이터 정의 언어 등입니다. 문서에서 태그가 누락된 경우 문서가 손상되지 않고 콘텐츠가 그대로 유지되며 정리, 읽기 또는 구문 분석이 덜 어려울 수 있습니다.

JSON과 같은 데이터 정의 언어에서 JSON과 같은 구조가 누락되고 콘텐츠(예: 일반 텍스트)만 남으면 데이터 세트는 실제로 존재하지 않으며 더 이상 JSON이 아닙니다.

내 생각에는 가장 큰 잘못된 명칭은 XML이다. 이름에서 알 수 있듯이 마크업 언어이지만 실제로는 거의 사용되지 않으며 대신 데이터 직렬화에만 거의 독점적으로 사용됩니다. 그래서 이름에 '마크업 언어'라는 용어가 잘못 사용되는 경우가 많은 것 같아요. 그 이유는 아마도 (아마도 확실하지는 않지만) 원래 의도일 것입니다. XML은 원래고의로"확장 가능한 마크업 언어"로서 이는 궁극적으로 데이터 직렬화 및 객체 표현과 같은 용도로만 사용됩니다. 또 다른 이유는 마케팅 등일 수 있습니다.

마지막으로 이 초록을 인용하고 싶습니다.YAML 사양 (내가 강조한 일부 단어):

1.3. JSON과의 관계

JSON과 YAML 모두 사람이 읽을 수 있는 데이터를 목표로 합니다.교환 형식. 그러나 JSON과 YAML은 우선순위가 다릅니다. JSON의 가장 중요한 디자인 목표는 단순성과 일반성입니다. 따라서 JSON은 생성 및 구문 분석이 간단하지만 사람의 가독성이 떨어지는 단점이 있습니다. 또한 최소 공통 분모 정보 모델을 사용하여 모든 최신 프로그래밍 환경에서 모든 JSON 데이터를 쉽게 처리할 수 있도록 보장합니다.

대조적으로, YAML의 가장 중요한 디자인 목표는 사람의 가독성과임의의 기본 데이터 구조 직렬화 지원. 따라서 YAML을 사용하면 읽기 쉬운 파일을 생성할 수 있지만 생성 및 구문 분석이 더 복잡합니다. 또한 YAML은 최소 공통 분모 데이터 유형을 초월하므로 서로 다른 프로그래밍 환경을 교차할 때 더 복잡한 처리가 필요합니다.

따라서 YAML은 향상된 인간 가독성과 보다 완전한 정보 모델을 제공하는 JSON의 자연스러운 상위 집합으로 간주될 수 있습니다. 이는 실제로도 마찬가지입니다. 모든 JSON 파일은 유효한 YAML 파일이기도 합니다. 이를 통해 추가 기능이 필요한 경우 JSON에서 YAML로 쉽게 마이그레이션할 수 있습니다.

[…]

YAML과 JSON 사이의 중간 형식을 정의하는 것이 유용할 수 있습니다. 이 형식은 JSON과 같이 구문 분석하기 간단하지만 사람이 읽기에는 어렵습니다. 동시에 YAML과 같은 임의의 기본 데이터 구조를 직렬화할 수 있습니다. 이 형식은 YAML의 "정규 형식"으로도 사용할 수 있습니다. 이러한 "YSON" 형식(YSON은 직렬화된 개체 표기법)을 정의하려면 JSON 사양을 강화하거나 YAML 사양을 제한하면 됩니다. 그러한 정의는 이 사양의 범위를 벗어납니다.

이 단락에는 "마크업 언어"라는 용어가 없습니다. 대신, 이것이 어떻게 교환 형식이고 데이터 직렬화를 위해 설계되었는지 언급합니다. 마지막 섹션에서는 지정된 요구 사항에 더 적합할 수 있는 중간 형식을 만드는 방법에 대해 설명합니다. 이는 "마크업 언어"와 "마크업 언어" 사이의 경계가 명확하지 않으며 일종의 정의 "회색 영역"이 있다는 추가 증거입니다.

전반적으로 저는 단순히 "구글 검색"을 하는 것이 아니라 해당 기술의 정의를 찾고 해당 기술 개발자의 정의를 읽어 보시기 바랍니다. 이제 Google 검색 단계가 완료되었습니다. 다음에는 해당 문서 등을 읽어보세요.

귀하의 책이 개발자가 자신의 기술이나 제품에 대해 말하는 것과 모순되는 경우 교과서가 잘못되었을 수 있으며 개발자나 저자가 정의한 모든 것이 의미가 없을 수 있으므로 둘 중 하나를 복음으로 받아들이지 마십시오. 의심스러우면 두 기술을 모두 살펴보고 기술 자체에 대한 설명이나 교과서에 설명된 내용과 얼마나 일치하는지 확인하세요. 일부 교과서 저자들은 단순히 개발자의 정의 등을 채택하기도 합니다.

일반적으로 약간 더 넓은 정의를 사용하여 언제든지 참조할 수 있습니다. XML과 JSON은 의심할 여지 없이 객체 표현이며 정의 언어로 사용될 수 있습니다. 그림OGDL단순히 "순서 그래프 정의 언어"라고 부르는 것은 XML이나 JSON을 포함하여 트리 구조를 사용하는 거의 모든 언어에 대한 유효한 설명입니다.

Answer 1