개발자 도구 · Base64 인코더 및 디코더
붙여넣은 Base64가 디코딩에 실패하는 이유: 줄 바꿈, 줄 바꿈 및 스마트 따옴표
· 그것이 중요한 이유
베이스64 인코딩
Base64는 전송 중에 거의 중단되지 않습니다. 클립보드에서는 깨집니다. 이 게시물에는 잘못된 문자 및 길이 오류를 생성하는 복사-붙여넣기 오류와 각 오류를 빠르게 발견하는 방법이 나와 있습니다.
터미널에서는 작동했지만 브라우저에서는 실패한 키 — 보이지 않는 문자 하나와 2시간 검색
엔지니어가 터미널에서 API 키를 복사하여 스크립트에서 테스트했습니다. 키가 터미널에서는 제대로 작동했지만 브라우저 도구에 붙여넣을 때 잘못된 문자로 인해 실패했습니다. 2시간 후 코드, 구성 및 문서를 검색한 후 보이지 않는 문자 하나를 발견했습니다. 에코에 의해 추가되거나 터미널 프롬프트 줄에서 복사된 키 끝에 있는 개행 문자는 Base64 디코더를 손상시키는 추가 문자가 되었습니다. 열쇠는 정확했습니다. 클립보드는 그렇지 않았습니다. Base64 데이터는 전자적으로 전송되고 체크섬 처리되고 검증될 때 신뢰할 수 있습니다. 수동 복사 및 붙여넣기 중에 거의 독점적으로 중단됩니다.
터미널의 줄 바꿈, 명령 출력의 후행 개행, 서식 있는 텍스트 편집기의 스마트 따옴표 대체 및 여러 응용 프로그램 간의 복사-붙여넣기에서 숨겨진 유니코드 문자는 모두 실제 문제가 복사된 방식에 있을 때 Base64가 손상된 것처럼 보이는 오류를 발생시킵니다. 이 게시물은 가장 일반적인 결함을 분류하고 각 결함을 신속하게 찾아 수정하는 방법을 보여줍니다. Base64 알파벳은 대문자와 소문자, 숫자, 더하기 기호, 슬래시 및 패딩 문자(등호)로 구성됩니다. RFC 4648은 구체적입니다. 표준 Base64 문자열에는 줄 바꿈된 경우 해당 문자와 선택적 공백만 포함됩니다.
터미널, 이메일 클라이언트 및 PEM 형식의 줄 바꿈 — 76 열 구분이 일부 디코더에는 적합하고 다른 디코더에는 치명적인 이유
많은 도구는 편차를 허용합니다. 더하기와 슬래시 대신 대시와 밑줄을 사용하는 URL 안전 변형을 허용하거나 줄 바꿈을 무시합니다. RFC를 따르는 엄격한 디코더는 예상 문자 집합을 벗어나는 모든 항목을 거부하고 잘못된 문자 오류로 인해 실패합니다. 오류 메시지에는 일반적으로 문제가 있는 문자의 이름이 지정되거나 문자열을 전혀 디코딩할 수 없다는 내용이 표시됩니다. 이메일, 터미널, 채팅 기록 또는 서식이 지정된 문서에서 Base64를 붙여넣을 때 보이지 않는 문자나 대체 문자가 삽입되어 디코딩이 실패하는 경우가 많습니다. 데이터 자체는 괜찮습니다. 클립보드 전송으로 인해 손상되었습니다.
줄 바꿈은 붙여넣기 Base64 오류의 가장 일반적인 원인이자 가장 쉽게 해결되는 원인이기도 합니다. 터미널 도구는 줄당 76 문자 또는 경우에 따라 80 문자로 출력을 래핑하여 줄 바꿈을 삽입하고 다음 줄에서 계속합니다. 일부 Base64 인코딩 라이브러리를 포함한 많은 인코더는 MIME 이메일과의 호환성을 위해 동일한 76 문자 경계에서 출력을 래핑합니다. 터미널에서 래핑된 Base64 문자열을 복사하면 개행 문자가 함께 표시됩니다.
에코 및 클립보드 도구의 후행 개행 — 추가 문자가 되는 추가 바이트
일부 디코더는 개행 문자를 자동으로 허용하고 무시합니다. 다른 사람들은 이를 유효하지 않은 문자로 거부합니다. 해결 방법은 모든 줄바꿈과 공백을 제거하는 것입니다. Base64 문자열이 터미널의 여러 줄에 걸쳐 래핑된 경우 모든 줄을 선택하고 편집기에 복사한 다음 모든 줄 바꿈을 삭제하세요.
결과 단일 행 문자열을 복사하여 디코더에 붙여넣습니다. 붙여넣기에 실패했을 때 가장 먼저 시도하는 방법입니다. 에코 및 클립보드 유틸리티의 후행 줄 바꿈은 또 다른 일반적인 원인입니다. echo $API_KEY 명령은 명령 표준 동작인 개행 문자가 뒤에 오는 키를 인쇄합니다. 해당 출력을 직접 복사하면 복사본에 개행 문자가 포함됩니다. 일부 터미널은 복사할 때 추가 줄바꿈을 추가하고 일부 클립보드 관리자는 줄바꿈을 유지하거나 복제합니다. 증상은 줄 바꿈과 동일합니다. 즉, Base64에 속하지 않는 문자열 끝에 추가 문자가 있는 것입니다.
둥근 따옴표, 줄바꿈하지 않는 공백 및 너비가 0인 문자 — 서식 있는 텍스트 편집기가 일반 텍스트를 다시 작성하는 방법
수정 방법도 마찬가지로 간단합니다. 디코딩을 시도하기 전에 편집기에서 붙여넣은 문자열의 끝 부분을 다듬습니다. 선행 및 후행 공백과 개행처럼 보이는 모든 문자를 제거합니다. 문자열이 충분히 짧으면 수동으로 다시 입력할 수 있지만 키가 긴 경우 주의 깊게 수동으로 다듬는 것이 더 빠릅니다. 둥근 따옴표, 줄 바꿈하지 않는 공백 및 기타 유니코드 대체는 미묘한 함정입니다. Word와 같은 서식 있는 텍스트 편집기는 자동으로 곧은 따옴표를 둥근 따옴표로 변환하고, 세 개의 하이픈을 em 대시로 변환하고, 특정 공백 시퀀스를 줄바꿈 없는 공백으로 변환합니다. 누군가 Base64 문자열을 문서에 붙여넣은 다음 서식이 지정된 문서에서 도구로 복사하면 해당 대체 항목이 나타납니다.
곧은 큰따옴표(")는 둥근 왼쪽 및 오른쪽 쌍이 되며 둘 다 유효한 Base64가 아닙니다. 줄바꿈 없는 공백(U+00A0)은 일반 공백과 동일해 보이지만 문자 코드가 다르며 모든 파서에서 공백으로 인식되지 않습니다. 해결 방법은 먼저 일반 텍스트 편집기에 붙여넣는 것입니다. 이렇게 하면 모든 서식이 삭제됩니다. Word 문서나 서식이 지정된 채팅에서 붙여넣는 경우 먼저 일반 텍스트 편집기나 HTML 텍스트 영역에 붙여넣고 이상한 문자가 있는지 확인한 다음 일반 텍스트 버전에서 복사하여 도구에 사용하세요.
잘림 및 패딩 손실 — 문자가 누락되었음을 알려주는 길이 모듈로 4 검사
복사 또는 붙여넣기 중에 문자열이 잘리면 잘림이 발생합니다. 매우 긴 Base64 문자열은 일부 시스템에서 클립보드 제한을 초과하거나 애플리케이션 버그로 인해 복사에 실패할 수 있습니다. 결과는 불완전한 더 짧은 문자열입니다. Base64 문자열의 길이는 패딩이 적용된 후 4의 배수가 되어야 합니다. 길이가 4의 배수가 아니면 잘리거나 손상됩니다. 오류 메시지는 일반적으로 문자열 길이가 잘못되었거나 문자가 누락되었음을 나타냅니다. 수정하려면 원래 복사된 내용을 알아야 합니다.
출처를 다시 확인 가능하시면 꼼꼼히 다시 복사해주세요. 그렇지 않으면 잘림을 복구할 수 없습니다. 패딩 손실은 관련된 문제입니다. 등호가 있는 Base64 패딩은 때때로 몇 바이트를 절약하기 위해 제거됩니다. 일부 응용 프로그램에서는 패딩을 생략하고 일부 응용 프로그램에서는 패딩을 요구합니다. 문자열이 원래 채워졌는데 패딩이 손실된 경우 다시 추가하세요. Base64 문자열에는 총 길이가 4의 배수가 되도록 0, 1 또는 2 후행 등호가 있어야 합니다. 아무것도 없고 길이가 4의 배수가 아닌 경우 패딩이 손실되었을 수 있습니다.
작업된 예: 래핑되고 잘린 문자열 복구 — 디코딩될 때까지 단계별로 정리
작업된 예는 이러한 수리를 단계별로 보여줍니다. 복사된 API 키가 편집기에 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg==로 표시된다고 가정해 보겠습니다. 문제를 식별하는 것부터 시작하세요. 후행 Cg==는 홀수입니다. Cg는 개행 문자(16진수 0A)에 대한 base64이며 추가 ==는 무언가가 추가되었음을 나타냅니다. 후행 Cg==를 제거하고 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0만 사용해 보세요. 그것은 여전히 옳지 않습니다. 길이는 4의 배수가 아닌 37자입니다. 다시 다듬기: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0(35자, 여전히 잘못됨). 원본 소스를 확인해보세요. 올바른 문자열은 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0(32자)이며 적절한 패딩은 VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0입니다. 추가: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0=.
디코더에서 테스트합니다. 이것은 실제로 비밀이 아닙니다. 각 단계에서 Base64 인코더 및 디코더를 사용하여 현재 문자열을 테스트하고 식별된 문제를 수정한 후 디코딩될 때까지 다시 테스트합니다. Base64 바이트 자체 내부의 손상은 디코더로 해결할 수 없습니다. 전송, 전송 또는 저장 중에 바이트가 실제로 손상된 경우 Base64 자체는 이를 감지할 수 없습니다. RFC는 유효한 문자를 지정합니다. 해당 세트 외부의 모든 문자는 포착할 디코더 작업입니다. Base64 문자 중간에 0이 1이 되는 것과 같은 바이트 손상은 완전히 다른 문자 코드를 생성하며 Base64만으로는 감지할 수 없습니다.
여기서 다루지 않는 내용 — Base64 자체에서 감지할 수 없는 인코딩된 바이트 내부 손상
체크섬 또는 디지털 서명은 이러한 종류의 손상을 감지하는 데 사용되며 Base64 인코딩 전에 원본 바이너리 데이터에서 계산되어야 합니다. Base64 문자열을 디코딩했는데 결과가 가비지이거나 예상한 것과 다른 경우 복사-붙여넣기 단계가 아닌 인코딩 전이나 전송 중에 손상이 발생한 것입니다. 이는 실제로는 드뭅니다. 대부분의 실패는 위와 같은 복사-붙여넣기 문제입니다. Base64 복사-붙여넣기 실패를 디버깅하는 체계적인 접근 방식은 각 잠재적인 문제를 순서대로 테스트하는 것입니다. 먼저 모든 공백과 줄 바꿈을 제거하십시오. 그런 다음 선행 및 후행 공백과 길 잃은 문자를 잘라냅니다.
그런 다음 모듈로 4의 길이를 확인하고 필요한 경우 패딩을 추가합니다. 각 버전을 Base64 인코더 및 디코더에 붙여넣고 디코딩되는지 확인하세요. 길이 확인에 실패하면 문자열이 잘렸는지 물어보고 원래 소스에서 검색하세요. 알파벳 검사에 실패하고 이상한 문자가 나타나면 둥근 따옴표나 유니코드 대체 문자를 찾아 이를 동등한 ASCII 문자로 바꾸십시오. 잘못된 문자를 이름별로 표시하는 온라인 도구를 사용하여 해당 문자를 식별하고 제거할 수 있습니다. Base64 인코더 및 디코더는 모든 유효하지 않은 문자에 대해 이 작업을 수행하여 알파벳에 없는 문자를 정확하게 나타냅니다.
요점: 데이터를 비난하기 전에 길이와 알파벳을 확인하십시오. Base64 인코더 및 디코더가 각 수리를 테스트할 수 있는 빠른 로컬 장소를 제공하는 방법
해당 피드백을 사용하여 각 문자를 수정하고 문자열이 디코딩될 때까지 계속합니다. 디버깅보다 예방이 더 쉽습니다. Base64 문자열이 다시 필요하다는 것을 알게 되면 서식을 유지하는 방식으로 복사하세요. 서식 있는 텍스트 문서에 붙여넣지 마세요. 일반 텍스트 파일이나 대체할 수 없는 지정된 텍스트 영역에 저장합니다. 누군가가 형식화된 메시지로 Base64 문자열을 보내는 경우 코드 형식이나 일반 텍스트로 다시 보내달라고 요청하세요. 형식이 지정된 소스에서 복사해야 하는 경우 먼저 일반 텍스트 편집기에 붙여넣고 사용하기 전에 문자열을 확인하세요.
사용하기 전에 Base64 인코더 및 디코더에서 문자열을 받자마자 테스트하세요. 실패하면 소스에 계속 액세스할 수 있는 동안 새 복사본을 요청할 수 있습니다. 문자열이 오래되거나 소스가 사라질 때까지 기다리면 잘림이나 손상을 수정하는 것이 불가능해집니다. Base64 인코더 및 디코더는 문자열을 사용하기 전에 테스트할 수 있는 빠른 로컬 장소를 제공합니다. 일찍 테스트하고 자주 테스트하여 복사-붙여넣기 오류가 즉시 발견되도록 하세요.