개발자 도구 · Base64 인코더 및 디코더
atob과 btoa가 무엇을 의미하며 라틴어만 이해하는 이유-1
· 배경
베이스64 자바스크립트 유니코드
atob 및 btoa는 Netscape의 날짜이며 이름은 'ASCII에서 바이너리로' 및 '바이너리에서 ASCII로'를 의미합니다. 이 게시물에서는 이들이 어디서 왔는지, WHATWG 표준이 이를 정의하는 방법, 유니코드를 배우지 못한 이유를 다룹니다.
오타처럼 읽는 함수 이름 — 이름으로 인해 발생하는 혼란과 한 줄 답변
atob 및 btoa는 1990년대 Netscape에 도입된 JavaScript 내장 함수입니다. 이름은 약어입니다. btoa는 이진수를 ASCII로, atob은 ASCII를 이진수로 나타냅니다. 이름은 연령과 디자인을 반영합니다. 바이너리가 최신 Uint8Array 또는 Buffer가 아닌 바이트 값 문자열(0-255)을 의미할 때 만들어졌습니다. 이름에 대해 종종 제공되는 니모닉은 관찰 가능한 계약보다 덜 중요합니다. 한 함수는 이진 문자열을 Base64에 매핑하고 다른 함수는 이를 반대로 매핑합니다. 이 저장소는 원래 명명 결정을 문서화하지 않으므로 기사에서는 민속을 소스 브라우저 기록으로 제시하지 않습니다.
함수에는 이진 문자열이 필요합니다. 각 문자의 코드 단위는 1바이트를 나타내는 0-255 범위에 있어야 합니다. 255 이상의 코드 단위가 있는 문자(예: 이모티콘 또는 라틴어 1 외부의 악센트 문자)를 전달하면 함수에서 InvalidCharacterError가 발생하거나 자동으로 잘못된 출력이 생성됩니다. btoa(이진에서 ASCII로)는 이진 문자열을 base64로 인코딩합니다.
이름이 암시하는 것과 바이트 문자열 계약이 실제로 증명하는 것
입력은 각 문자가 바이트인 문자열이어야 합니다(코드 단위 0-255). btoa(hello)는 ASCII 바이트를 base64로 인코딩하고 aGVsbG8=을 반환합니다. 문자 e-acute가 있는 btoa는 사전 구성된 라틴어-1 문자 e-acute(U+00E9)에 0-255 내에 있는 233의 코드 단위가 있기 때문에 작동하는 것으로 보입니다. 그러나 btoa는 e-acute가 생성해야 하는 UTF-8 바이트 0xC3 0xA9가 아닌 단일 바이트 0xE9로 인코딩합니다. 형식화된 배열이 일반 바이트 컨테이너가 되기 전에 JavaScript API는 코드 단위가 바이트를 나타내는 문자열을 사용했습니다. btoa는 255 이상의 코드 단위를 거부하기 때문에 해당 모델은 계속 표시됩니다. 정확한 제품 연대기는 이 파일에 의해 확립되지 않습니다. 실패 경계는 실행 가능한 테스트에 의해 설정됩니다.
이 조용한 손상은 오류보다 더 위험합니다. 결과는 괜찮아 보이지만 잘못되었습니다. atob(ASCII에서 바이너리로)은 base64를 다시 바이너리 문자열로 디코딩합니다. atob(aGVsbG8=)은 hello를 반환합니다. 출력은 각 문자의 코드 단위가 1바이트를 나타내는 0-255인 이진 문자열입니다. 이를 적절한 유니코드 텍스트로 변환하려면 바이트를 UTF-8로 해석하고 TextDecoder로 디코딩해야 합니다.
레거시 바이너리 문자열 모델 — 확인되지 않은 브라우저 기록 주장 없이 관찰 가능한 동작
ASCII의 경우 이 추가 단계는 필요하지 않지만(ASCII는 UTF-8의 하위 집합임) ASCII가 아닌 바이트의 경우 필수적입니다. atob은 그런 해석을 하지 않습니다. 원시 바이트를 이진 문자열로 반환합니다.
WHATWG 표준(웹 API의 생활 표준)은 HTML 사양에서 atob 및 btoa를 정의합니다. 정의에는 atob에 대한 관용적인 base64 디코드 알고리즘이 포함되어 있습니다. 공백을 건너뛰고 누락된 패딩을 허용하여 실제 base64(줄 바꿈이 있는 MIME 래핑된 base64 포함)를 디코딩 가능하게 만듭니다. ToolAcre는 브라우저 디코더를 호출하기 전에 공백, URL 안전 구두점 및 누락된 패딩을 정규화합니다. 그런 다음 반환된 코드 단위를 Uint8Array에 복사하고 치명적인 UTF-8 디코더를 적용합니다. 이 조합은 관용적인 Base64 구문과 엄격한 텍스트 해석을 분리합니다.
이 구현의 현재 동작 — 알파벳 정규화 및 엄격한 UTF-8 텍스트 디코딩을 허용합니다.
함수 서명은 변경되지 않았지만 표준 정의는 함수가 수행하는 작업에 대한 권한입니다. atob과 btoa는 왜 라틴어-1만 허용합니까? 왜냐하면 1990년대에 JavaScript가 설계되었을 때 JavaScript에는 바이트를 직접 표현할 수 있는 방법이 없었기 때문입니다(Uint8Array 또는 ArrayBuffer 없음). 함수에 바이트를 전달하는 유일한 방법은 각 문자가 1바이트를 나타내는 문자열을 사용하는 것이었습니다.
이는 이진 문자열이라고 하며 현대 표준에서는 혼란스럽습니다. JavaScript 문자열은 바이트 시퀀스가 아닌 유니코드 텍스트입니다. 디자인은 두 가지를 결합했습니다. 각 코드 단위가 0-255인 문자열은 이진 문자열입니다. 이름 지정은 시대를 반영합니다. btoa의 ASCII는 문자 그대로 ASCII 텍스트의 7비트를 의미하지만 구현에서는 모든 바이트(0-255)를 허용합니다. 유니코드 모드를 btoa에 직접 추가하면 오랜 바이트 문자열 계약과 위험 호환성이 변경됩니다. 검토된 소스는 대신 인코딩 전에 TextEncoder를 구성합니다. 이 기사에서는 그 구성을 확인할 수 있습니다. 이는 저장소에 기록되지 않은 표준 위원회 동기에 대한 주장을 생략합니다.
작업된 예: 공백과 누락된 패딩이 있는 문자열에서 forgiving-base64 추적 — 엄격한 디코더가 거부하는 atob이 허용하는 것
최신 대안은 이진 문자열 모델을 피합니다. Encoding API는 텍스트를 UTF-8 바이트로 변환하는 TextEncoder와 UTF-8 바이트를 다시 텍스트로 변환하는 TextDecoder를 제공합니다.
Base64 인코딩 및 디코딩은 이제 문자열(atob 및 btoa)과 형식화된 배열 모두에 대해 HTML 사양에 지정됩니다. Base64 인코더 및 디코더 도구는 atob 및 btoa 주변에 TextEncoder 및 TextDecoder를 사용하므로 라틴어 1 제한 없이 유니코드 텍스트를 안전하게 인코딩하고 디코딩할 수 있습니다. 공백이 있거나 채워지지 않은 값은 정규화가 공백을 제거하고 필요한 블록 길이를 복원하므로 성공합니다. 정리된 길이가 나머지 1을 남기는 값은 atob 전에 거부됩니다. 이러한 구별은 여기서 "용서"가 무엇을 의미하는지 보여줍니다. 즉, 복구 가능한 형식은 허용되지만 구조적으로 불가능한 입력은 허용되지 않습니다.
새로운 표준은 Typed Array에 대해 Base64에서 작동합니다. 현재 브라우저 지원을 확인하기 위한 메모와 함께 질적으로 설명되어 있습니다.
btoa로 유니코드를 처리하려면 먼저 텍스트를 UTF-8바이트로 인코딩해야 합니다. 이전 해결 방법은 btoa(unescape(encodeURIComponent(text)))였으며 혼란스럽기는 하지만 작동합니다. encodeURIComponent는 UTF-8 바이트를 백분율로 인코딩하고, unescape는 세 쌍을 다시 문자로 변환하고, btoa는 결과 바이너리 문자열을 인코딩합니다. 이는 작동하지만 더 이상 사용되지 않는 기능에 의존하므로 읽기가 어렵습니다. 최신 코드는 TextEncoder(text).map(byte => String.fromCharCode(byte)) 다음에 btoa를 사용해야 합니다. 또는 더 나은 방식으로 Uint8Array로 직접 변환하고 Encoding API를 사용해야 합니다.
Atob은 자동으로 텍스트를 제공하지 않습니다. 그것은 당신에게 바이너리를 제공합니다. atob(Y2Fmw6kg8J+YgA==)는 caf-accent 및 emoji가 포함된 UTF-8로 인코딩된 텍스트의 바이트를 포함하는 이진 문자열을 반환합니다. 텍스트를 복구하려면 이진 문자열을 Uint8Array로 변환하고 이를 TextDecoder(utf-8)에 전달합니다. Base64 인코더 및 디코더 도구는 이 작업을 자동으로 수행합니다. 텍스트를 붙여 넣으면 이를 UTF-8바이트로 인코딩한 다음 base64로 인코딩합니다. 형식화된 배열 Base64 API는 브라우저 전반에 걸쳐 발전하고 있지만 이 소스에서는 이를 사용하지 않습니다. 이에 따라 현재 호환성 확인 및 대체 계획이 필요합니다. ToolAcre의 명시적인 바이트 배열 변환은 검사 가능하며 현재 테스트 제품군에서 다룹니다.
유형 배열 대안이 진화하고 있습니다. 이에 의존하기 전에 현재 브라우저 지원을 확인하세요.
base64를 붙여넣으면 UTF-8바이트로 디코딩된 다음 텍스트로 디코딩됩니다. 중간 이진 문자열 단계는 1990년대 API의 구현 세부 사항이므로 숨겨져 있습니다. atob 및 btoa를 이해하면 레거시 코드를 디버깅하거나 바이너리 문자열을 전달하는 기존 API로 작업하는 데 유용합니다. 대부분의 새로운 코드는 이진 문자열 모델을 완전히 피해야 합니다.
base64를 인코딩하거나 디코딩해야 하는 경우 Base64 인코더 및 디코더 도구가 유니코드를 올바르게 처리합니다. API를 구축하는 경우 Uint8Array 또는 형식화된 배열 보기를 허용하거나 base64가 UTF-8 또는 Latin-1인지 명확하게 문서화하세요. TextEncoder 없이 ASCII가 아닌 텍스트와 함께 btoa를 사용하는 코드를 검토할 때 이는 버그입니다. 출력이 잘못된 바이트를 인코딩합니다. 노드 버퍼 및 비브라우저 런타임은 서로 다른 API 및 허용 규칙을 정의합니다. 의도적으로 제외되었습니다. 이 문서의 주장은 모든 환경에서 atob 또는 btoa라는 이름의 모든 함수가 아닌 apps/dev,에 구현된 브라우저 기본 요소 및 래퍼에 관한 것입니다.
요약: 바이트 문자열 계약이 있는 2개의 1990년대 함수 — Base64 인코더 및 디코더가 UTF-8를 우회하여 악센트, CJK 및 이모티콘 왕복을 수행하는 방법
atob 및 btoa라는 이름은 1990년대 컴퓨팅의 독특한 인공물입니다. 현대적인 이름은 base64Encode 및 base64Decode이며 API는 Uint8Array 또는 명시적인 인코딩 선언이 있는 문자열을 허용합니다. 그러나 atob과 btoa는 이전 버전과의 호환성을 위해 브라우저에서 유지됩니다. 그것이 의미하는 것과 할 수 없는 것을 이해하면 유니코드 텍스트를 인코딩할 때 자동 손상을 방지하는 데 도움이 됩니다.
Base64 인코더 및 디코더 도구는 격차를 해소합니다. 이 도구는 최신 코드에 필요한 UTF-8 및 base64 언어를 사용합니다. 강력한 패턴은 구성적입니다. 텍스트를 UTF-8 바이트로 인코딩하고 바이트를 이진 문자열 계약으로 변환한 다음 btoa를 호출합니다. atob 주위에서 해당 단계를 되돌립니다. 악센트, CJK 문자 및 이모티콘을 시도한 다음 모든 원본 코드 포인트와 일치하도록 디코딩된 텍스트를 요구합니다.