나는 성능 엔지니어가 움츠러들게 할 고백을 가지고있다. WP Adminify 용 WordPress 대시 보드의 초기 버전에서 나는 스프라이트 시트 관리에 지쳤 기 때문에 모든 아이콘을 base64 로 인코딩하고 CSS 에 바로 인라인으로 연결했다. 아이콘은 즉시 나타 났으며 추가 요청도없고 누락 된 이미지의 플래시도 없었습니다. 그런 다음 스타일 시트가 메가 바이트를 지나서 풍선처럼 불어 났고 두 번째로드에서 페이지가 느려지는 느낌이 들었습니다. 그 인라인 이미지 중 어느 것도 자체적으로 캐시 할 수 없었기 때문입니다. 그 프로젝트는 & quot;image to base64" 또한 남용하기 쉬운 진정으로 유용한 기술입니다.
이 가이드는 그 수업의 두 반쪽을 모두 다룹니다. 저는 이미지를 base64 로 변환하는 방법을 보여 드리겠습니다 Base64 변환기에 이미지 Toolz.dev에서는 base64를 이미지로 다시 디코딩하는 방법, 데이터 URI가 실제로 무엇인지, 정직한 절충안을 통해 이익을 얻는 자산을 인라인화하고 그렇지 않은 자산을 남겨둡니다.
TL;DR: 이미지를 base64로 변환하면 해당 바이너리 내용이 일반적으로 다음과 같은 데이터 URI로 감싸인 텍스트 문자열로 바뀝니다
data:image/png;base64,iVBORw0KG.... 그 문자열은 별도의 파일 요청 없이 HTML,CSS, SVG,JSON 에 직접 내장됩니다. Toolz.dev 변환기는 양방향으로 인코딩 및 디코딩하고 브라우저에서 완전히 실행되므로 이미지가 업로드되지 않으며 원시 base64,준비된 데이터 URI,an<img>태그, 그리고 CSS 스니펫.Base64 는 약 3 분의 1 의 크기를 부풀려서 큰 사진이 아닌 아이콘과 같은 작은 자산을 인라인으로 만듭니다.
base64 이미지란 정확히 무엇입니까?
Base64 는 압축이 아닌 암호화가 아닌 인코딩 체계입니다. 체계는 다음에 의해 정의됩니다 RFC 4648, 그리고 data: 감싸는 URI RFC 2397. 인쇄 가능한 64 개의 ASCII 문자를 사용하여 임의의 이진 데이터를 나타냅니다: 문자 A 에서 Z 및 a 에서 z,숫자 0 에서 9,더하기 + 그리고 /, 와 함께 = 패딩에 사용됩니다. 구성표는 이메일 첨부 파일 및 JSON 페이로드에서 볼 수있는 base64 를 관리하는 것과 동일한 표준 인 RFC 4648 에 정의되어 있습니다.
존재하는 이유는 internet's 배관이 원시 바이트가 아닌 텍스트를 위해 많이 만들어 졌기 때문입니다. 바이너리 데이터에는 텍스트 지향 채널이 망가 뜨릴 바이트 값이 포함될 수 있습니다. Base64 는 3 바이트의 입력을 받아 그 24 비트를 6 개의 4 개 그룹으로 나누고 각 그룹을 64 문자 중 하나에 매핑하여 그것을 회피합니다. 3 바이트 인,4 문자 아웃. 그 3 대 4 비율은 인코딩 된 출력이 소스보다 대략 33 퍼센트 큰 정확한 이유이며 인라이닝이 좋은 아이디어인지 여부를 결정하기 때문에 기억할만한 숫자입니다.
A "base64 image"는 단순히 해당 인코딩을 통해 실행된 이미지 파일입니다. 문자열 자체는 텍스트일 뿐입니다. 렌더링 가능하게 만드는 것은 데이터 URI 로 래핑하는 것입니다.
데이터 URI 란 무엇이며 브라우저가 이를 렌더링하는 이유는 무엇입니까?
데이터 URI 는 원격 리소스를 가리키는 대신 페이로드를 인라인으로 전달하는 URL 입니다. RFC 2397 에 정의된 모양은 data:[<media-type>][;base64],<data>. 다음과 같은 PNG의 경우 data:image/png;base64,iVBORw0KGgo....
중요한 조각은 미디어 유형,입니다 image/png 그 예제에서. 그것은 브라우저에게 뒤에 오는 바이트를 해석하는 방법을 알려줍니다. 데이터 URI 가 자신의 MIME 유형을 발표하기 때문에 브라우저는 치료할 수 있습니다 data:image/png;base64,... 그림으로 URL을 예상하는 속성을 구문 분석하는 순간입니다 src 의 <img> 또는 the url() CSS 에서 background-image니다. 네트워크 왕복은 일어나지 않습니다. 가져올 것이 없기 때문입니다. 이미지는 이미 거기에 있으며 마크 업에 철자가 있습니다.
그것이 전체 마법이고 전체 비용이 한 문장으로 되어 있습니다. 이미지가 이미 존재하는 이유이며,즉시 렌더링되는 이유이며,또한 연결된 파일이 할 수 있는 방식으로 페이지 간에 별도로 캐시하거나 공유할 수 없는 이유이기도 합니다.
Toolz.dev 에서 이미지를 base64 로 변환하려면 어떻게 해야 하나요?
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 10 Base64 변환기에 이미지 는 두 방향이 있으며, 인코딩은 기본값입니다.
"Base64" 에 이미지; 방향을 선택한 다음 이미지를 업로드하거나 드롭합니다. 도구는 브라우저 파일 API 를 사용하여 로컬로 파일을 읽으며 해당 읽기가 브라우저에서 발생하기 때문에 이미지가 서버로 이동하지 않습니다. 일단 로드되면 미리보기와 4 개의 출력이 제공되며 각각 자체 복사 버튼이 있습니다.
원시 base64 는 베어 문자열로, 이미 자체 래퍼가 있을 때 유용합니다. 데이터 URI가 전체입니다 data:... 에 붙여넣을 준비가 된 문자열입니다 src 또는 url(). HTML <img> 태그는 템플릿에 넣을 수 있는 완전한 요소입니다. CSS background-image 선언은 스타일시트를 위한 준비가 되어 있습니다. 디코딩된 바이트 크기와 base64 문자 수를 볼 수 있는 것과 함께 커밋하기 전에 가중치를 판단할 수 있습니다. 숫자가 놀라워 보인다면, 그것이 그 일을 하는 도구입니다: HTML에서 200KB 사진이 270KB 문자열이 되는 것은 바로 재고해야 할 순간입니다.
base64 를 이미지로 다시 디코딩하려면 어떻게 해야 하나요?
"Base64 를 Image"로 전환하여 원시 base64 문자열 또는 완전한 데이터 URI 중 하나를 방향 및 붙여 넣습니다. 변환기는 입력에 대해 허용 오차입니다: 공백을 제거하고 전체 붙여 넣을 경우 data:image/png;base64,... 문자열 그것은 접두사 밖으로 바로 MIME 유형을 읽습니다. 접두사없이 bare base64 를 붙여 넣으면 대부분의 스크린 샷과 내보낸 자산에 대한 안전한 기본값 인 PNG를 가정합니다.
문자열의 유효성을 먼저 검사합니다. 붙여 넣은 내용이 그럴듯하지 않은 경우 base64, 즉 RFC 4648 알파벳 외부의 문자가 포함되어 있으면 도구는 깨진 이미지를 표시하지 않고 알려줍니다. 입력이 체크 아웃되면 라이브 미리보기와 원본 바이너리 파일을 다시 빌드하고 올바른 확장자로 저장하는 다운로드 버튼을 얻을 수 있습니다. 이 방향은 스타일 시트 또는 API 응답에 묻혀있는 데이터 URI 를 찾아 실제로 무엇인지 확인하거나 실제 파일로 다시 추출 할 때 진정으로 편리합니다.
여기에 있는 모든 것은 클라이언트 측입니다. 이는 텍스트 지향에서 도구 상자의 나머지 부분을 통해 실행되는 것과 동일한 약속입니다 Base64 변환기 에 URL 인코더. 브라우저에서 이러한 종류의 작업을 유지하는 데 대한 더 넓은 추론을 원한다면 base64 인코딩 가이드 인코딩 자체에 대해 더 자세히 설명합니다.
언제 base64 로 이미지를 인라인해야하며, 언제하지 말아야합니까?
이것이 도구가 알려주기 위해 존재하는 결정이므로 실제로 사용하는 표는 다음과 같습니다.
| 상황 | Base64로 인라인으로? | 왜 |
|---|---|---|
| 사이트 전체에서 사용되는 작은 아이콘 또는 로고 | 종종 그렇습니다 | 요청을 제거하고 즉시 나타나며 오버헤드가 작습니다 |
| 작은 SVG 또는 1px 배경 | 예 | 33 퍼센트의 오버헤드는 몇 백 바이트에서 무시할 수 있습니다 |
| 단일 파일 HTML 내보내기 또는 이메일 | 예 | 파일은 외부 자산이 허용되지 않고 독립적이어야 합니다 |
| 대형 영웅 사진 또는 배너 | 아니요 | 오버헤드가 크고 이미지를 별도로 캐시할 수 없습니다 |
| 많은 페이지에서 이미지를 재사용했습니다 | 아니요 | 연결된 파일은 한 번 캐시되어 공유됩니다; 인라인은 모든 곳에서 이를 복제합니다 |
| 자주 바뀌는 콘텐츠 이미지 | 아니요 | 편집자는 파일처럼 쉽게 base64 blob을 교환할 수 없습니다 |
테이블 뒤에 패턴은 간단합니다. 인라이닝은 문서의 바이트에 대한 네트워크 요청을 거래합니다. 자산이 작고 저장된 요청이 중요 할 때 그 거래가 승리하며,이는 접힌 부분 위의 아이콘에 대한 고전적인 경우입니다. 자산이 크거나 공유 될 때 손실됩니다. 33 퍼센트의 세금을 지불하기 때문에 독립적 인 캐싱을 잃고 브라우저가 무엇이든 페인트하기 전에 구문 분석해야하는 바로 그 파일을 부풀립니다.
"no" 행의 경우 일반적으로 파일을 최적화하고 정상적으로 제공하는 것이 더 나은 이동입니다. 즉, 도구가 좋아하는 곳입니다 이미지 압축 또는 the 포맷 변환기 유지 수익을 창출하여 자산을 축소하여 연결된 버전이 최대한 가볍습니다. 나는 전체 워크플로에 대해 더 자세히 썼습니다 웹 개발자 툴킷 가이드.
base64는 내 이미지를 비공개로 유지합니까?
예,아니오, 그리고 구별이 중요합니다. Base64 는 인코딩이므로 문자열을 가진 사람은 누구나 정확한 원본 이미지로 다시 디코딩 할 수 있습니다. 제로 비밀을 제공합니다. 데이터 URI 를 숨기는 방법으로 취급하지 마십시오. 왜냐하면 "Base64 to Image" 바로이 도구의 방향은 하나의 붙여 넣기에서 그것을 반전시킵니다.
비공개란 변환 그 자체입니다. Toolz.dev 에서 이미지는 File API 를 사용하여 브라우저에서 완전히 읽고 인코딩되며 아무 것도 업로드되지 않습니다. 따라서 아트 워크,스크린 샷,인코딩하는 클라이언트 로고는 프로세스 중에 머신을 떠나지 않습니다. 그것은 콘텐츠를 숨기는 인코딩과는 다른 보증이며,나는 & quot;private" 느슨하게 던져지기 때문에 그것에 대해 정확하게하려고 노력합니다. 개인 정보는 로컬 처리에 있으며,더 광범위하게 에서 다룹니다 데이터 개인 정보 보호 base64가 아닌 체계로 안내합니다.
이것을 발송하는 몇 가지 실용적인 팁
가능한 경우 아이콘에 SVG 를 선호하고,SVG 마크업을 base64 로 인코딩하는 것보다 직접 인라인으로 만듭니다. SVG 는 이미 텍스트이므로 base64 로 감싸면 33 퍼센트의 세금만 추가됩니다. Base64 는 진정으로 바이너리 인 PNG 및 JPEG 와 같은 래스터 형식에 대해 빛납니다.
단일 이미지뿐만 아니라 전체 문서 크기를보십시오. 하나의 인라인 아이콘은 보이지 않습니다. 그 중 40 개는 WordPress 대시 보드에서 내가 저지른 실수로 린 스타일 시트를 괴물로 바꿉니다. 한 줌 이상 인라인으로 묶는다면,그것은 뒤로 물러나서 링크 된 스프라이트 또는 아이콘 글꼴을 대신 고려하라는 신호입니다.
MIME 유형을 정직하게 유지하십시오. JPEG 를 내보내지만 데이터 URI 를 로 레이블을 지정하는 경우 image/png는, 몇몇 브라우저는 대처하고 몇몇은 대처하지 않습니다. 변환기는 파일에서 진짜 유형을 검출합니다 그래서 산출은 정확합니다, 그러나 당신이 다른 곳에 자료 URI를 손으로 조립하는 경우에, 매체 유형을 실제적인 바이트에 일치하십시오.
그리고 미스터리 데이터 URI 로 가득 찬 코드베이스를 상속받을 때 디코드 방향을 기억하십시오. "Base64 에 Image"에 하나를 붙여 넣는면과 타격 다운로드는 스타일 시트가 실제로 배송되는 것을 볼 수있는 가장 빠른 방법입니다.
base64 인코딩은 실제로 어떻게 단계별로 작동합니까?
전체 33 퍼센트 오버헤드 스토리가 자연스럽게 빠져나가기 때문에 역학을 한 번 보는 것이 도움이 된다. Base64 는 한 번에 3 바이트씩의 그룹에서 동작한다. 3 바이트는 24 비트이다. 인코더는 그 24 비트를 각각 6 비트의 4 개의 덩어리로 쪼갠다. 6 비트는 0 부터 63 까지의 64 개의 값을 나타낼 수 있고,그 값 각각은 base64 알파벳의 한 문자로 매핑된다: 0 부터 25 까지는 A 부터 Z,26 부터 51 까지는 a 부터 z,52 부터 61 까지는 0 부터 9 의 자리,그러면 + 62 및 / 63을 위해.
그래서 세 입력 바이트는 항상 네 개의 출력 문자가 됩니다. 그것이 크기 증가의 원천입니다. 네 개의 문자는 세 바이트의 정보를 가지고 다니는데,이는 4 대 3 의 비율인데,이는 출력이 입력보다 3 분의 1 이 크다는 것과 같은 방식입니다. 왜냐하면 그것은 구성표가 작동하는 방식에 구워지기 때문입니다.
패딩은 남은 음식을 처리합니다. 데이터가 3바이트의 깨끗한 배수가 아닌 경우 인코더는 최종 그룹을 패딩하여 여전히 정수의 문자를 생성하고 하나 또는 두 개를 추가합니다 = 얼마나 많은 패딩을 추가했는지 기록하는 표지판입니다. 그래서 base64 문자열이 자주 끝납니다 = 또는 ==. 단일 후행 = 2바이트를 보유한 마지막 그룹을 의미합니다; 더블 == 하나를 쥐고 있다는 뜻입니다. Toolz.dev 변환기는 양방향으로 자동으로 패딩을 처리하고,디코딩할 때 후행이 있거나 없는 문자열을 행복하게 받아들입니다 =, 일부 시스템에서는 이를 제거하기 때문입니다.
아주 작은 예제로 이 플레이 아웃을 볼 수 있습니다. 문자 "Man"에 대한 3 개의 ASCII 바이트를 인코딩 문헌에서 바로 나온 유명한 예인 "TWFu" 4 개의 문자로 인코딩합니다. 동일한 3 개의 문자를 텍스트로 데이터 URI 에 놓으면 왕복 여행을 볼 수 있거나 도구를 통해 실제 이미지를 실행하고 출력의 문자 수가 항상 옆에 표시된 바이트 수의 약 3 분의 4 임을 알 수 있습니다.
이것을 이해하면 base64 가 큰 이미지에 적합하지 않고 작은 이미지에 잘 맞는 이유도 설명됩니다. 오버 헤드는 고정 된 비율이므로 300 바이트 아이콘의 경우 100 바이트의 비용이 들지만 아무도 신경 쓰지 않습니다. 2 메가 바이트 사진에서는 문서의 순수 텍스트 부풀림의 3 분의 2 가 필요하며 해당 문서는 페이지가 렌더링되기 전에 다운로드하고 구문 분석해야합니다. 수학은 크기에 따라 변경되지 않지만 결과는 변경됩니다.
자주 묻는 질문
이미지를 Base64로 변환하려면 어떻게 해야 하나요?
Image to Base64 방향을 선택한 다음 이미지를 업로드하거나 드롭합니다. 이 도구는 파일을 로컬로 읽고 인코딩한 다음 원시 Base64 와 함께 바로 사용할 수 있는 데이터 URI, img 태그 및 복사할 수 있는 CSS 스니펫을 반환합니다.
데이터 URI 란 무엇입니까?
데이터 URI 는 파일을 링크하는 대신 data:[mime-type];base64,[data] 형식으로 인라인으로 삽입하는 문자열입니다. PNG 의 경우 data:image/png;base64,iVBORw0KGgo... 브라우저는 URL 이 예상되는 곳마다 이미지로 렌더링하므로 별도의 요청이 필요하지 않습니다.
Base64 를 다시 이미지로 변환할 수 있나요?
예. 이미지 방향으로 Base64 로 전환하고 원시 Base64 문자열 또는 전체 데이터 URI 중 하나를 붙여 넣습니다. 이 도구는 이를 디코딩하고 미리보기를 표시하며 재구성된 이미지 파일을 다운로드할 수 있습니다.
어떤 이미지 형식이 지원됩니까?
PNG,JPG/JPEG,GIF, WebP,SVG, BMP,ICO, AVIF 가 모두 지원됩니다. 파일에서 올바른 MIME 유형이 감지되므로 결과 데이터 URI 가 올바르게 렌더링됩니다.
Base64 문자열이 내 이미지보다 큰 이유는 무엇입니까?
Base64 는 4 개의 텍스트 문자로 구성된 3 바이트의 이진 데이터를 나타내므로 인코딩 된 출력은 소스보다 약 33 퍼센트 큽니다. 그 오버 헤드는 Base64 가 큰 사진보다 작은 아이콘과 로고에 더 적합한 이유입니다.
여기에서 이미지를 변환하는 것이 안전합니까?
예. 모든 이미지는 File API 를 사용하여 브라우저에서 완전히 읽고 인코딩됩니다. 파일,문자열 또는 결과가 서버에 업로드되지 않으므로 개인 이미지가 장치에 유지됩니다.
제작 중에 이미지를 Base64로 인라인해야 합니까?
인라이닝은 HTTP 요청을 제거하고 누락 된 이미지의 플래시를 피하기 때문에 아이콘과 같이 자주 사용되는 작은 자산에 잘 작동합니다. 큰 이미지의 경우 일반적으로 브라우저가 독립적으로 캐시 할 수 있도록 별도의 파일을 유지하는 것이 좋습니다.
변환기는 오프라인 및 모바일에서 작동합니까?
예. 모든 처리가 클라이언트 측이기 때문에 연결 없이도 페이지가 로드된 후에 작동하며 인터페이스는 최신 데스크톱 및 모바일 브라우저에서 반응합니다.
