私はパフォーマンスエンジニアをひるませる告白を持っています.WP Adminify用のWordPressダッシュボードの初期バージョンでは、私はスプライトシートの管理にうんざりしていたので、すべてのアイコンをbase64 でエンコードし、CSSにまっすぐにインライン化しました。アイコンは即座に表示され、余分な要求はなく、画像が欠落していることもありませんでした。その後、スタイルシートがメガバイトを超えて膨らみ、ページが2 回目の読み込みで遅く感じられました。なぜなら、それらのインライン化された画像はどれも自分でキャッシュできなかったからです。そのプロジェクトで、" image to base64" は、使いすぎやすい真に便利なテクニックであることを学びました。
このガイドでは、そのレッスンの両方の半分をカバーしています。 で画像を base64 に変換する方法を紹介します 画像からBase64コンバータへ Toolz.dev では、base64 をデコードして画像に戻す方法、データ URI の実際、正直なトレードオフを考慮して、恩恵を受ける資産をインライン化し、恩恵を受けない資産を残します。
tl;dr: 画像をbase64 に変換すると、そのバイナリの内容がテキスト文字列に変わり、通常は のようなデータURIでラップされます
data:image/png;base64,iVBORw0KG...。 that string embeds directly in HTML, CSS, SVG, or JSON with no separate file request. Toolz.dev converter encodes and decodes in both directions, runs entirely in your browser so no image is ever uploaded, and gives you the raw base64, a ready data URI, an<img>タグ、およびCSSスニペット。 base64 はサイズを約3 分の1 に膨らませるので、大きな写真ではなく、アイコンのような小さなアセットをインライン化します。
正確には、base64 画像とは何ですか?
Base64 はエンコーディングスキームであり、圧縮でも暗号化でもありません。 scheme は、によって定義されます RFC 4648、そして data: で包むURI RFC 2397。 A から Z までの文字と a から z までの文字、0 から 9 までの数字、および 64 個の印刷可能な ASCII 文字を使用して、任意のバイナリ データを表します + あんど /、 と = パディングに使用されます。このスキームは、電子メールの添付ファイルと JSON ペイロードに表示される base64 を管理する同じ標準である RFC 4648 で定義されています。
存在する理由は internet' s の配管の多くは、生のバイトではなくテキスト用に構築されたからです。 binary データには、テキスト指向のチャネルが混乱するバイト値を含めることができます。 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 の an <img> それか、 url() CSS で background-image. no network round trip happens, because there is nothing to fetch.画像は既にそこにあり、マークアップに綴られている。
それが1 つの文で全体の魔法と全体の費用です 画像はすでにそこにあるため、即座にレンダリングされ、リンクされたファイルのように個別にキャッシュしたり、ページ間で共有したりできない理由でもあります。
Toolz.devで画像をbase64 に変換するにはどうすればよいですか?
ザ・ 画像からBase64コンバータへ は2 方向で、エンコーディングがデフォルトです。
" Image to Base64" の方向を選択し、画像をアップロードまたはドロップします。ツールはブラウザー File API を使用してファイルをローカルに読み取ります。また、その読み取りはブラウザーで発生するため、画像はサーバーに移動することはありません。ロードされると、プレビューと 4 つの出力が取得され、それぞれに独自のコピー ボタンが付きます。
生のbase64 は裸の文字列で、既に自分のラッパーを持っている時に便利です。 data URI は full です data:... 文字列を貼り付ける準備ができています src や url()。 HTML <img> タグ はテンプレートにドロップできる完全な要素です。 CSS background-image 宣言はスタイルシートの準備ができています.あなたがデコードされたバイトサイズとbase64 文字数を見るものと一緒に, だからあなたはコミットする前に重みを判断することができます.数に警戒に見える場合, それはその仕事をしているツールです: あなたのHTMLで200 KBの写真が270 KBの文字列になることはまさに再検討する瞬間です。
base64 をデコードしてイメージに戻すにはどうすればよいですか?
" Base64 to Image" に切り替えて、生の base64 文字列または完全なデータ URI のいずれかを方向付けて貼り付けます。コンバータは入力に対して許容範囲です。空白を剥がし、完全に貼り付ける場合は、空白を剥がします data:image/png;base64,... 文字列 それはプレフィックスからまっすぐにMIMEタイプを読み取ります。 bare base64 をプレフィックスのない状態で貼り付けると、PNGを前提としています。これは、ほとんどのスクリーンショットとエクスポートされたアセットの安全なデフォルトです。
最初に文字列を検証します 貼り付けたものがもっともらしいものでない場合 base64、つまりRFC 4648 アルファベットの外側の文字が含まれている場合、ツールは壊れた画像を表示するのではなく、入力がチェックアウトすると、ライブプレビューと、元のバイナリファイルを再構築して適切な拡張子で保存するダウンロードボタンを取得します この方向は、スタイルシートやAPIレスポンスに埋め込まれたデータURIを見つけて、それが実際に何であるかを確認したり、実際のファイルに抽出したりするときに本当に便利です。
ここにあるものはすべてクライアント側であり、これはテキスト指向からツールボックスの残りの部分を通るのと同じ約束です Base64 コンバーター に the URLエンコーダ。この種の作業をブラウザで保持する背後にあるより広範な理由が必要な場合は、 base64 エンコーディングガイド エンコーディング自体をさらに詳しく説明します。
画像を base64 としてインライン化する必要があるのはいつですか、また、インライン化しないのはいつですか?
これはツールが通知するために存在する決定であるため、実際に使用する表を次に示します。
| 状況 | ベース64 としてインライン? | なんでや |
|---|---|---|
| サイト全体で使用される小さなアイコンまたはロゴ | よくある | リクエストを削除すると、即座に表示され、オーバーヘッドは小さくなります |
| ちっちゃなSVGまたは1pxの背景 | はいって | 33 パーセントのオーバーヘッドは、数百バイトでは無視できます |
| 単一ファイルの HTML エクスポートまたは電子メール | はいって | ファイルは自己完結型である必要があり、外部アセットは許可されません |
| 大型ヒーローの写真またはバナー | いやー | オーバーヘッドが大きく、画像を個別にキャッシュすることはできません |
| 画像は多くのページで再利用されます | いやー | リンクされたファイルは一度キャッシュされ、共有されます; インライン化すると、どこにでも重複します |
| 頻繁に変化するコンテンツイメージ | いやー | 編集者は、base64 のブロブをファイルほど簡単に交換することはできません |
テーブルの後ろのパターンは簡単です インライン化すると、ドキュメント内のバイトのネットワークリクエストを取引します その取引は、資産が小さく、保存されたリクエストが重要である場合に勝ちます これは、折り目の上のアイコンの古典的なケースです 資産が大きいまたは共有されているときに負けます 33 パーセントの税金を支払うため、独立したキャッシュを失い、ブラウザが何かをペイントする前に解析する必要があるファイルそのものを肥大化します。
"no" 行の場合、通常、ファイルを最適化し、正常に提供することがより良い動きです。そこにツールがあります 画像圧縮 それか、 フォーマット変換 その維持を獲得, 資産を縮小するので、リンクされたバージョンはできるだけ軽いです。 でそのワークフロー全体について詳しく書きました Web 開発者ツールキット ガイド.
base64 は私のイメージを非公開にしますか?
はい、いいえ、そして区別は重要です。 Base64 はエンコーディングであるため、文字列を持っている人は誰でも、それをデコードして正確な元の画像に戻すことができます。秘密性はゼロです。 "Base64 から Image" であるため、データ URI を隠す方法として扱わないでください。まさにこのツールの方向は、それを 1 つのペーストに反転させます。
プライベートとは変換そのもの。 Toolz.devでは画像はファイルAPIでブラウザーで完全に読み取られエンコードされ、何もアップロードされないので、エンコードしているアートワーク、スクリーンショット、クライアントロゴはプロセス中にマシンから離れることはありませんそれはコンテンツを隠すエンコードとは異なる保証であり、私はそれについて正確にしようと努めていますなぜなら "private" は緩く投げ回されるからですプライバシーはローカル処理にあり、より広くカバーされています データプライバシー ガイド, スキームとしてbase64 ではありません.
これを出荷するからのいくつかの実用的なヒント
できるときはアイコンに SVG を優先し、SVG マークアップを base64 でエンコードするのではなく直接インライン化します。 SVG はすでにテキストであるため、base64 でラップすると、33 パーセントの税金が無料で追加されるだけです。 Base64 は、PNG や JPEG などの真にバイナリであるラスター形式に最適です。
単一の画像だけでなく、ドキュメントの合計サイズを見てください。 1 つのインライン付きアイコンは目に見えません。そのうちの 40 個、WordPress ダッシュボードで犯した間違いですが、無駄のないスタイルシートをモンスターに変えます。一握り以上のインラインを入れる場合、それは一歩下がって、代わりにリンクされたスプライトまたはアイコン フォントを検討するためのシグナルです。
MIME タイプは正直なままにしてください。 JPEG をエクスポートするが、そのデータ URI にラベルを付ける場合 image/png、いくつかのブラウザは対処し、いくつかは対処しない。 converterはファイルから実数型を検出するので出力は正しいが、他の場所でデータuriを手作業で組み立てる場合は、メディア型を実際のバイトに一致させる。
そして、謎のデータURIでいっぱいのコードベースを継承するときは、デコードの方向を覚えておいてください。 " Base64 to Image" sideに1つ貼り付けてダウンロードをヒットすることは、スタイルシートが実際に何を出荷しているかを確認する最速の方法です。
実際にどのようにbase64 エンコーディングが機能するのか、ステップバイステップで?
33 パーセントのオーバーヘッドストーリー全体が自然に抜け落ちるので、メカニクスを一度見るのに役立ちます。 Base64 は一度に3 バイトのグループで動作します。 3 バイトは24 ビットです。エンコーダは、それらの24 ビットをそれぞれ6 ビットの4 つのチャンクにスライスします。 6 ビットは、0 から63 までの64 の値を表すことができ、それらの値のそれぞれは、base64 アルファベットの1 文字にマッピングされます:0 から25 のAからZ、26 から51 のAからZ、52 から61 の0 から9 の数字、その後 + 62 と / 63 の場合.
したがって、3 つの入力バイトは常に 4 つの出力文字になります。それがサイズ増加の源です。4 つの文字は 3 バイトの情報、つまり 4 対 3 の比率を運びます。これは、出力が入力より 3 分の 1 大きいと言っているのと同じです。スキームの仕組みに組み込まれているため、回避する方法はありません。
パディングは残り物を処理します。データが 3 バイトのクリーン倍数でない場合、エンコーダは最後のグループにパッドを入れるため、それでも整数の文字が生成され、1 つまたは 2 つ追加されます = どれだけのpaddingを追加したかを記録するサイン。 base64 文字列がしばしばで終わるのはそのためです = や ==。 単一の末尾 = は、最後のグループが2 バイト; a doubleを保持していたことを意味する == 1 つを保持したことを意味します。 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 to Image 方向に切り替えて、生の Base64 文字列または完全なデータ URI を貼り付けます。ツールはそれをデコードし、プレビューを表示し、再構成された画像ファイルをダウンロードできます。
どの画像形式がサポートされていますか?
PNG、JPG/JPEG、GIF、WebP、SVG、BMP、ICO、AVIF はすべてサポートされています。ファイルから正しい MIME タイプが検出されるため、結果のデータ URI が正しくレンダリングされます。
Base64 文字列が画像より大きいのはなぜですか?
Base64 は 4 文字のテキスト文字で 3 バイトのバイナリ データを表すため、エンコードされた出力はソースよりも約 33 パーセント大きくなります。そのオーバーヘッドが、Base64 が大きな写真よりも小さなアイコンやロゴに適している理由です。
ここで画像を変換しても安全ですか?
はい。すべての画像は、ファイル API を使用してブラウザーで完全に読み取られ、エンコードされます。サーバーにファイル、文字列、または結果がアップロードされないため、プライベート画像はデバイス上に残ります。
本番環境では画像を Base64 としてインライン化する必要がありますか?
インラインは、HTTP リクエストを削除し、欠落した画像のフラッシュを回避するため、アイコンなどの小さくて頻繁に使用されるアセットに対してうまく機能します。大きな画像の場合は、通常、ブラウザがファイルを独立してキャッシュできるように、別々のファイルを保持する方が良いです。
コンバーターはオフラインでもモバイルでも動作しますか?
はい。すべての処理はクライアント側であるため、接続がなくてもページが読み込まれた後に機能し、インターフェイスは最新のデスクトップ ブラウザとモバイル ブラウザ全体で応答します。
