개발자 도구 · 구문 변환기
TOML이 존재하는 이유: Cargo.toml 및 pyproject.toml의 설계 목표
· 배경
toml 데이터 형식 개발자 워크플로
TOML는 JSON의 엄격함과 YAML의 모호함에 대한 대응으로 2013에서 만들어졌습니다. 이 게시물에서는 명시된 디자인 목표, 그들이 만든 선택, 그리고 Rust와 Python이 프로젝트 구성을 위해 이를 표준화한 이유를 설명합니다.
하나의 저장소에 세 가지 구성 형식 — 편집기의 경우 JSON, CI의 경우 YAML, 빌드의 경우 TOML 및 세 번째가 존재하는 이유에 대한 질문
저장소는 다양한 구성 화면에 JSON, YAML 및 TOML를 사용할 수 있습니다. ToolAcre는 모든 프로젝트의 선택을 설명할 수 없지만 변환을 통해 구조적 차이가 구체적으로 만들어집니다. TOML은 루트 테이블로 시작하고 중첩을 위해 헤더와 점선 경로를 사용하며 JSON에서 사용할 수 없는 임시 값을 전달합니다.
겉모습으로 논쟁하기보다는 예제를 로드하세요. 중첩된 테이블은 객체가 되고, 이중 괄호 테이블은 배열이 되며, 값이 JSON을 입력하면 주석이 사라집니다. 이렇게 관찰된 경계는 하나의 구문이 본질적으로 더 낫다는 일반적인 주장보다 더 실행 가능합니다.
디자인 목표 — 최소, 명확한 의미, 읽기 쉽고 해시 테이블에 명확하게 매핑되는 형식
제공된 파서는 명확한 테이블 의미 체계를 노출합니다. 헤더는 경로이고 할당은 활성 테이블에 속하며 스칼라 토큰은 TOML 유형을 정의했습니다. 문자열은 단순히 내용이 날짜처럼 보인다는 이유로 입력되지 않습니다. 실제 시간 구문은 ToolAcre가 의도적으로 정규화하는 날짜 개체를 생성합니다.
저장소는 해당 형식의 작성자, 날짜 또는 명시된 철학을 출처로 삼지 않으므로 이 기사에서는 기억된 역사를 사실로 제시하지 않습니다. smol-toml 및 변환기의 자체 정규화 계층에서 테스트된 동작을 보고합니다.
출처가 없는 출처 주장 없이 배송된 파서에서 관찰 가능한 디자인 속성
TOML에는 null이 없으며 해당 문서 루트는 배열이나 스칼라일 수 없습니다. 이 매핑에서는 YAML 스타일 앵커나 별칭을 제공하지 않습니다. 주석은 작성된 TOML에 있지만 값 파서에 의해 유지되지 않으므로 JSON 또는 YAML를 통한 변환이 유지될 수 없습니다.
인용되지 않은 기본 값은 YAML의 스키마 선택이 아닌 TOML 문법을 따릅니다. 파서는 입력된 값을 받아들이거나 위치 정보와 함께 잘못된 TOML를 보고합니다. ToolAcre는 잘못된 할당에 대해 암시적 문자열 모드를 추가하지 않습니다.
지원되는 가치 모델이 제외하거나 다르게 처리하는 것
모델에는 문자열, 부호 있는 정수, 부동 소수점, 부울, 네 가지 임시 종류, 배열 및 테이블이 포함됩니다. 테이블 배열은 반복되는 개체 레코드를 표현합니다. 2^53 이상의 큰 부호 있는 정수는 변환 시 십진수 문자열이 되므로 JavaScript는 이를 자동으로 반올림하지 않습니다.
시간 값은 오프셋 날짜-시간, 현지 날짜-시간, 현지 날짜 또는 현지 시간에 대한 소스 지향 텍스트가 됩니다. 경고는 산문의 종류를 유지하지만 JSON은 문자열만 받습니다. 따라서 다시 변환하면 이를 인용하고 기본 TOML 유형이 손실됩니다.
채택 — Rust 초기의 화물, PEP 518 pyproject.toml 선택 및 2021의 1.0.0 사양
Cargo 및 pyproject 채택은 변환기 저장소에 소스가 없어야 하는 역사적 및 생태계 주장입니다. 여기서는 의도적으로 생략했습니다. 경로나 파일 이름은 연대순, 사양 릴리스 또는 표준 결정에 대한 증거가 아닙니다.
운영상의 질문은 대상 도구가 TOML을 읽는지 여부와 어떤 테이블을 예상하는지입니다. 해당 도구의 현재 문서를 확인하세요. 구문 변환기는 패키지 관리자 구성 계약이 아니라 구문과 값 매핑을 알고 있습니다.
저장소 소스가 없으면 생태계 채택 내역이 생략됩니다.
테이블 컨텍스트가 여러 줄에 걸쳐 지속되는 반면, 대규모 테이블 배열은 반복되는 헤더에 하나의 논리적 목록을 분산시키기 때문에 깊은 중첩은 검색하기가 더 어려울 수 있습니다. JSON은 전체 계층 구조를 명시적으로 만들지만 중괄호와 따옴표를 추가합니다. 두 표현 모두 기본 구성의 복잡성을 제거하지 않습니다.
파서의 중첩은 100로 제한되고 소스 길이는 2백만 자로 제한됩니다. 이는 이상적인 구성 크기나 보편적인 TOML 제한에 대한 설명이 아니라 거부 경계입니다.
여기서 다루지 않는 내용 — TOML 각 언어의 파서 선택 및 일부 표준 라이브러리 구현의 읽기 전용 특성
각 언어의 파서 선택은 표준 라이브러리 쓰기 기능과 마찬가지로 범위를 벗어납니다. ToolAcre는 smol-toml을 동적으로 사용하고 오류를 래핑합니다. 또 다른 구현에서는 유효한 출력의 형식을 다르게 지정하거나 동일한 데이터를 표시하면서 다른 API를 노출할 수 있습니다.
상호 운용성이 중요한 경우 임시 값, 큰 정수, 배열 및 점으로 구분된 키에 대해 교차 도구 고정 장치를 사용하십시오. 여기에서 승인된 파일은 모든 TOML 소비자가 자동으로 승인하지 않습니다.
요점: TOML은 구성 형식에 대해 독단적이며 구문 변환기 패널을 통해 해당 형태의 JSON 또는 YAML 파일을 볼 수 있는 방법에 대해 주장합니다.
TOML은(는) 테이블 루트, 명시적 유형 값, 기본 임시 종류 및 null 없음 등 관찰 가능한 방식으로 독선적입니다. 변환은 기원 신화 없이도 이러한 선택과 JSON 모양의 대상과의 비호환성을 드러냅니다.
패널을 사용하여 나무를 검사하고 경고를 식별합니다. 그런 다음 대상의 스키마로 돌아가서 사람이 유지할 테이블 레이아웃을 작성합니다. 변환기는 형식 선호도에 대한 결정이 아니라 값에 대한 증거를 제공합니다.
TOML이 중간 뷰인 경우에도 동일한 원칙이 적용됩니다. 가독성을 판단하기 전에 소스를 보존하고, 정규화된 값을 비교하고, 모든 시간적 또는 광역 정수 변환을 기록해 두세요. 간결한 테이블 레이아웃은 변경된 유형을 숨길 수 있는 반면 테이블의 장황한 배열은 의미상 정확할 수 있습니다. 형식 선택은 생성된 하나의 샘플의 시각적 깔끔함이 아닌 구성 계약 및 유지 관리 워크플로를 따라야 합니다.