데이터 및 스프레드시트 · CSV 클리너
스프레드시트 사용자를 위한 문자 인코딩: ASCII, Windows-1252 및 UTF-8
· 배경
CSV 인코딩 데이터 형식
인코딩은 어떤 바이트가 어떤 문자를 의미하는지에 대한 합의이며 CSV 파일은 어떤 문자를 사용하는지 명시하지 않습니다. 이 게시물에서는 ASCII, Windows-1252 및 UTF-8를 일반 용어로 설명하고 UTF-8이 승리한 이유와 이것이 수출에 미치는 영향을 설명합니다.
아무것도 설명하지 않는 설명으로 '인코딩 문제입니다' — 인코딩이 실제로 무엇인지
"인코딩 문제"라고 말하면 경계는 식별되지만 해결 방법은 아닙니다. 파일은 바이트를 저장합니다. 페이지에서 구분 기호와 따옴표를 인식하려면 문자가 필요합니다. 바이트 대 문자 일치가 잘못된 경우 파서는 CSV 상태 머신이 작성된 대로 정확하게 동작하더라도 대체 표시를 받을 수 있습니다.
ToolAcre의 계약은 명시적입니다. 선택한 텍스트는 UTF-8로 읽히고 선행 UTF-8 바이트 순서 표시만 특별 처리됩니다. 이 좁은 계약은 CSV에 인코딩 레이블이 있는 것처럼 가장하는 것보다 더 유용합니다. 수출자와 수령자는 구조적 정리를 신뢰할 수 있으려면 먼저 동의해야 합니다.
ASCII: 공유 코어 — 7비트, 영어 알파벳 및 구두점, 거의 모든 인코딩에 공통되는 이유
ASCII 문자는 대부분의 CSV 구문에서 사용되는 친숙한 영어 문자, 숫자 및 구두점에 대해 UTF-8과 겹칩니다. 이것이 고객 이름이나 기호가 공유 범위를 벗어나는 바이트를 소개할 때까지 파일이 정상적으로 나타날 수 있는 이유입니다. 저장소는 이러한 실용적인 관찰을 지원하지만 ASCII 기록이나 정확한 설계 연대기에 대한 주요 소스는 아닙니다.
따라서 하나의 이름이 이미 손상된 경우에도 쉼표와 따옴표를 사용하여 올바르게 구문 분석할 수 있습니다. 구조적 성공은 성격 충실도가 아닙니다. 전체 영어 샘플은 국제 데이터에 중요한 인코딩 경계를 실행할 수 없기 때문에 내보내기를 테스트할 때 비ASCII 픽스처를 포함합니다.
ASCII 오버랩은 유용한 컨텍스트이지만 비트 수와 기록에는 외부 소스가 필요합니다.
레거시 코드 페이지는 지역 테이블 아래에 바이트 값을 할당하고 잘못된 테이블을 사용하면 문자가 변경됩니다. 통합 문서에서 Windows-1252 세부 정보를 요청했지만 ToolAcre에는 선택 가능한 디코더나 매핑 테이블이 없습니다. 해당 구성에서는 Windows-1252 및 Shift-JIS가 UTF-8로 읽혀지고 대체 문자가 표시된다는 경고를 표시합니다.
생산자 설정 또는 변경되지 않은 바이트에서 작동하는 인코딩 인식 검사기를 통해 레거시 소스를 식별합니다. 이 클리너에게 이름에서 테이블을 추론하도록 요청하지 마십시오. `File.text()`가 손상된 문자열을 반환하면 파서는 디코딩이 삭제한 바이트 구분을 복구할 수 없습니다.
레거시 코드 페이지 세부 정보는 저장소 증거 외부에 있습니다. ToolAcre는 이를 디코딩하지 않습니다.
UTF-8는 일반 구문 문자를 변경하지 않고 그대로 두고 ASCII 오버랩을 벗어난 텍스트를 나타낼 수 있습니다. 브라우저는 작업자가 구문 분석하기 전에 선택한 바이트를 JavaScript 문자열로 변환합니다. 테스트에서 보여주듯이 해당 문자열 내에서 유니코드 이름과 이모티콘은 ToolAcre의 파서 및 직렬 변환기를 통해 왕복됩니다.
이 증거는 모듈을 완전한 유니코드 설명자로 만들지 않습니다. 경로가 유효한 디코딩된 문자열, 인용 필드 및 내보내기 텍스트를 유지한다고 말합니다. 정규화 형식, 문자소 클러스터 또는 모든 유니코드 변환에 대한 질문은 코드 외부에 있으므로 한 번의 성공적인 왕복에서 추론해서는 안 됩니다.
ToolAcre는 완전한 유니코드 인코딩 모델이 아닌 UTF-8 텍스트 처리를 보여줍니다.
프로젝트는 구성된 입력 및 출력 계약이기 때문에 UTF-8을 선택합니다. 리포지토리 파일은 더 넓은 웹이 UTF-8을 채택한 역사적 이유를 설정하지 않으므로 이 문서에서는 요청한 주장을 생략합니다. 제품 진실은 실행 가능하기 위해 보편적인 채택 설명이 필요하지 않습니다.
운영자의 경우 표준화란 로드하기 전에 UTF-8로 내보내거나 변환하고 대표적인 다국어 값을 확인한 다음 검토된 테이블을 직렬화하는 것을 의미합니다. 수신 스크립트도 UTF-8을 예상하고 BOM을 수락할지 여부를 결정해야 합니다. 양측의 합의는 불이행에 대한 일반적인 진술보다 더 중요합니다.
저장소는 UTF-8을 이 도구의 계약으로 설정하지만 더 넓은 웹이 이를 선택한 이유는 아닙니다.
구분 기호 감지 전에 선행 U+FEFF가 제거되고 결과는 인터페이스에서 보고할 수 있도록 `hadBom`을 기록합니다. 내보내기는 방문자가 옵션을 선택할 때 동일한 표시를 앞에 붙일 수 있습니다. 해당 선택이 없으면 출력은 첫 번째 헤더 문자로 직접 시작됩니다.
이 표시는 일부 스프레드시트 워크플로에서 UTF-8을(를) 인식하는 데 도움이 될 수 있지만 구성에서는 엄격한 스크립트 또는 데이터베이스 가져오기로 인해 첫 번째 헤더에 표시가 첨부될 수 있음을 경고합니다. 보편적인 청결이 아닌 알려진 소비자를 위한 옵션을 사용하십시오. BOM 정책은 인터페이스 계약의 일부입니다.
여기에 포함되지 않는 내용 — UTF-16 내보내기, 동아시아 인코딩 및 구성된 문자의 정규화
UTF-16, 동아시아 레거시 인코딩 및 유니코드 정규화는 여기서 구현되지 않습니다. 바이트 순서 감지나 대체 문자 복구도 마찬가지입니다. 이러한 누락의 이름을 지정하면 사용자가 성공적인 다운로드를 모든 원본 캐릭터가 살아 남았다는 증거로 취급할 수 없습니다.
지원되지 않는 바이트가 포함된 경우 원본을 보존하고 해당 소스용으로 설계된 디코더를 사용하십시오. 검증된 UTF-8로 변환한 후 ToolAcre는 문서화된 CSV 구조를 처리할 수 있습니다. 행 구문 분석에서 문자 디코딩을 분리하면 오류를 더 쉽게 진단하고 파괴적인 추측을 피할 수 있습니다.
모든 내보내기를 UTF-8하고 그렇게 말합니다. ToolAcre CSV Cleaner의 인코딩 복구가 브라우저에서 레거시 내보내기를 UTF-8로 변환하는 방법
UTF-8을 명시적인 교환 요구 사항으로 만들고 데이터세트에서 사용하는 실제 문자 클래스로 테스트합니다. ToolAcre는 선행 UTF-8 BOM을 제거하거나 추가하고 유효한 유니코드 셀 문자열을 유지하며 CSV 인용을 정규화할 수 있습니다. 원래 개요에서 약속한 레거시 변환을 수행할 수 없습니다.
대체 문자가 나타나면 정리하거나 다시 저장하기 전에 중지하세요. 원본 바이트에서 복구하고 이름을 확인한 다음 반환합니다. 해당 순서는 정보를 보호합니다. 구분 기호, 중복 및 공백 작업을 통해 신뢰할 수 있는 출력을 생성하려면 인코딩이 정확해야 합니다.