데이터 및 스프레드시트 · CSV 클리너
CSV과 JSON 간 변환: 모양, 유형 및 손실되는 항목
· 작동 방식
CSV JSON 데이터 형식
CSV은 일반 텍스트이고 JSON은 중첩된 입력 데이터이므로 둘 사이를 변환하려면 결정이 필요합니다. 이 게시물에서는 표 형식 데이터의 일반적인 JSON 모양, 유형이 추론되는 방식, 왕복에서 살아남을 수 없는 항목에 대해 설명합니다.
API는 JSON을 원하고 내보내기는 CSV이며 모든 숫자는 문자열로 도착합니다. 두 형식이 유형에 대해 동의하지 않는 이유
스프레드시트 내보내기에서는 해당 문자가 개수, 제품 코드 또는 식별자를 의미하는지 여부를 밝히지 않고 42을 표시할 수 있습니다. JSON은 숫자와 문자열을 구별할 수 있지만 CSV 소스는 그러한 구별을 제공할 수 없습니다. 따라서 ToolAcre는 보수적 표현을 선택합니다. 모든 셀은 숫자, 실제처럼 보이는 단어 및 빈 셀을 포함하여 JSON 문자열이 됩니다.
이 결정은 0012과 같은 텍스트를 그대로 유지하고 API 통합에 대한 변환을 예측 가능하게 만듭니다. 이는 또한 다운스트림 코드가 산술을 수행하기 전에 자체 스키마에서 필드를 캐스팅해야 함을 의미합니다. 생성된 파일을 이미 입력된 것으로 처리하면 변환기의 가정이 덜 눈에 띄는 애플리케이션 코드로 이동될 뿐입니다.
일반적인 대상 모양 — 헤더로 키가 지정된 객체 배열 및 헤더가 깔끔하고 고유해야 하는 이유
경로는 각 데이터 행에 대해 하나의 개체가 포함된 최상위 배열을 생성합니다. 헤더 셀은 객체 키가 되고 동일한 열 위치에서 값을 가져옵니다. 비어 있는 세 번째 헤더는 column_3이 되고, id라는 두 번째 헤더는 첫 번째 id 필드를 덮어쓰는 대신 id_2가 됩니다.
깔끔하고 고유한 이름이 유용하지만 변환기는 공백을 소문자로 변환하거나 음역하거나 바꾸지 않습니다. 키를 계산하는 동안에만 헤더를 자르고 필요한 경우 위치 이름이나 숫자 접미사를 만듭니다. API에 고객 이메일이 아닌 customer_email이 필요한 경우 출력 계약을 사용하기 전에 의도적으로 해당 열의 이름을 바꾸십시오.
대체 모양 — 배열 및 열 지향 객체의 배열, 그리고 각각이 더 적합한 경우
선택 가능한 대상으로 제안된 배열 배열 및 열 지향 객체의 개요입니다. 이는 합리적인 데이터 디자인이지만 이 인터페이스는 이를 제공하지 않습니다. 출력은 항상 첫 번째 CSV 행을 기준으로 한 일반 레코드의 JSON 배열이며 읽기 가능한 검사를 위해 두 개의 공백으로 들여쓰기되어 있습니다.
이러한 좁은 선택은 열 이름이 어디에 있는지에 대한 모호성을 제거하고 모든 레코드 모양을 동일하게 유지합니다. 다른 소비자가 배열을 기대하는 경우 해당 소비자의 스키마에 따라 다운로드한 JSON을 변환합니다. ToolAcre가 여러 레이아웃 중에서 선택한다고 주장하는 것은 구성이나 패널 코드에 존재하지 않는 컨트롤과 분기를 설명하는 것입니다.
이 변환기는 하나의 모양, 즉 평면 개체의 최상위 배열을 내보냅니다.
유형 추측이 발생하지 않습니다. CSV 텍스트 42은 "42"가 되고, false는 "false"가 되며, 공백은 null이 아닌 ""가 됩니다. 이는 셀을 문자열 속성에 직접 매핑하는 도구 기록 및 구현에서 명시적으로 나타납니다. 경로는 열을 검사하지 않고 비어 있지 않은 모든 값이 숫자라고 결정합니다.
또한 문자열을 보존하면 선행 0, 날짜 및 긴 식별자를 변경하는 스프레드시트 애플리케이션에 대한 게시된 토론과 이 기사가 구분됩니다. 여기서 요점은 변환기의 실제 계약입니다. 즉, 그러한 종류의 강제를 피합니다. 알려진 수량을 구문 분석하고 식별자를 그대로 유지하는 것은 소비자의 책임입니다.
유형은 텍스트로 유지됩니다. ToolAcre는 추론을 수행하지 않습니다.
반대 방향으로 ToolAcre는 항목이 개체인 최상위 JSON 배열을 허용합니다. 모든 개체의 키 조합에서 처음 표시된 순서대로 열을 작성하므로 이후 레코드에서 도입된 필드가 손실되지 않습니다. 누락, null 및 정의되지 않은 속성은 빈 CSV 셀이 됩니다.
속성 내에 저장된 개체 또는 배열은 해당 셀 내에서 JSON 텍스트로 직렬화됩니다. 이렇게 하면 텍스트 표현이 유지되지만 중첩된 구조가 추가 열이나 행으로 바뀌지는 않습니다. 배열이 아닌 루트와 기본 값을 포함하는 배열은 이 경로가 지원하는 테이블 모델과 일치하지 않기 때문에 거부됩니다.
JSON-to-CSV은 객체 배열을 허용하고 중첩된 값을 JSON 텍스트로 씁니다.
이름, 활성, 개수 다음에 Ada,true,007가 오는 것을 고려하세요. JSON 결과는 이름이 "Ada"이고 활성이 "true"이며 개수가 "007"인 개체를 포함하는 배열입니다. 해당 단순 객체 배열을 다시 변환하면 유형 추론이 0을 제거하거나 부울처럼 보이는 단어를 변환하지 않기 때문에 동일한 3개의 텍스트 셀이 생성됩니다.
이제 다른 값 앞에 빈 헤더를 추가합니다. JSON 키는 column_4가 되므로 소스 이름이 없어도 데이터에 계속 접근할 수 있습니다. 그러나 헤더 너비를 넘어서 추가 셀을 추가하면 로더가 행이 불규칙하다는 경고를 표시합니다. 해당 잉여 셀에는 키가 없으며 JSON에 없습니다.
여기서 다루지 않는 내용 — 깊게 중첩된 JSON, 스키마 유효성 검사 및 매우 큰 JSON 문서 스트리밍
경로가 스키마 유효성 검사기, 재귀 병합기 또는 스트리밍 JSON 프로세서가 아닙니다. 하나의 문서화된 형태를 허용하고 유효하지 않은 JSON 또는 특정 오류와 함께 지원되지 않는 루트를 보고합니다. 깊게 중첩된 레코드에는 키의 구두점이 구조를 생성한다는 자동 약속보다는 해당 도메인을 중심으로 설계된 매핑이 필요합니다.
입력 파일 검사는 구성된 50 MB까지 파일을 허용하며 CSV 구문 분석은 작업자에서 발생합니다. 이러한 사실은 스트리밍을 설정하지 않습니다. 파일 텍스트와 완료된 행은 여전히 변환을 위해 구체화됩니다. 매우 큰 JSON 워크플로의 경우 여기에서 추론하는 대신 증분 구문 분석을 명시적으로 문서화하는 구현을 사용하는 시스템을 사용하세요.
스키마 유효성 검사, 기본 배열 및 비배열 루트가 허용되는 모양을 벗어났습니다.
변환은 눈에 보이는 선택 항목 집합입니다. 첫 번째 행은 키로, 일반 개체는 레코드로, 문자열은 값으로 사용됩니다. ToolAcre는 샘플에서 추측하는 대신 이러한 선택을 안정적으로 만듭니다. 비어 있고 반복되는 헤더는 결정적 키를 받는 반면, 이름 없는 잉여 값이 눈에 띄지 않게 사라지기 전에 불규칙한 입력이 표면화됩니다.
미리보기를 사용하여 구분 기호와 행 모양을 확인하고 경고를 해결한 다음 JSON을(를) 다운로드하거나 복사하세요. 결과 파일은 자체 스키마를 알고 있는 코드에 적합합니다. 이는 의도적으로 해당 스키마를 대체하는 것이 아니며 해당 제한은 형식 변경 중에 텍스트 ID를 보호하는 것입니다.