Base64で送るなら Compression Dictionary Transport (Shared Brotli) を使うと効率良さそう。まだAndroidとPCのChromium系限定だけど。
Gzip圧縮後のバイナリデータを受け付けるなら、そもそもBase64エンコードする必要は⋯という気もしなくはない。(事情は分かるが)
「Base64は重い」っていう思考停止な通説に理論で殴りに行くスタイル、嫌いじゃない。結局リソース食うから一長一短だけど、設計の選択肢としてはアリだな
なるなる。こういう記事たすかる
かういふ ChatGPT 文体の記事を見る度に「本当に実験したのか? ハルシネーションぢゃねえの?」と疑ふやうになってしまった
マッチポンプ感…まあJSONに埋め込む便利さはあるんだろうけど…でも巨大JSONにはなっちゃうなあ
テキスト化した物をバイナリ化するんだからそりゃそうだよね
受け取った側のgunzip後のJSONパースがでっかいJSONノードのパースでメモリ効率が悪いというのが通信のことよりもずっと問題視してた。
Base64は64種類の文字しか出現しないから圧縮できる、なんてほぼ自明で、説明の流れで言ってるとは言え「謎」扱いはモヤモヤする。
何でこんな「どんな形の折紙でも広げれば1枚なのです、折るのは大変だけど」みたい話がブクマされてるの？もしかしてLLMの回答を記事としてキャッシュすればAIの電力消費を削減できるっていう実験？それって検索と何…
本当だわ。やってみたら確かに、10MBのjpeg画像ファイル→(base64エンコード)→13MBのテキストファイル→(zip圧縮)→11MBのzipファイル……となった。
当たり前すぎ。しかも記事の至るところでおかしな記述（"ランダムな英数字"、"実質的な情報量 = bit"、"出現率 100%"など)が見られる。著者がそもそも基本を全く理解しておらず、ところどころAIに書かせたっぽい記事。
当たり前なのでは。
Webのフロントエンドとかやってるやつは、結局、見よう見まねでキーボードをランダムにたたいてるだけではないかという疑いを抱かせる観測事例。
この記事もエントロピーが低いから圧縮して三行にしよう。
ISHだとサイズ増えるけどMNPクラス5で圧縮できる話 歴史は繰り返す
お、おう…
塵も積もれば。無駄な計算資源は使わないに越したことはない。
Base64エンコードしたら効率下がるだろうとは思ってたけど、3割増えるのは知らなかった
氷を溶かすと水になるが、もう一度冷やすと氷に戻るみたいな・・・
普通のサーバフレームワークならmultipart/form-dataもオブジェクトとして扱えるからbase64で送るメリットはほとんど無い。multipart/form-dataが前提でストリームにするか非ストリームにするかの選択かと。
AIっぽさが消えてない
テキストデータとして処理したいから冗長化してまでエンコードしているはずなのにバイナリのまま送るのと比較するのはナンセンス。あとmultipart/form-dataはバイナリじゃないだろ
BASE64が情報密度を下げるけど、圧縮すれば元の情報密度に戻る
当たり前というか、バイナリで送れるならそもそも Base64 でテキスト化する意味はないだろ…
Base64がランダムだと思ってる人、いないとは思うが、いたら暗号化と混同してると思う
面白いよね
当たり前や、んでgzipを送るときはbase64化されるんだから33%増加するだろ 馬鹿なのかな?
圧縮したやつをbase64にして、それを再び圧縮するという設計に、ウッとなる、そういう感覚を大切にしていきたいね
“この特性を理解してアーキテクチャを選定”することがあるのかは気になる
圧縮率の話は別に問題ないと思うけど、multipart/form-dataはクライアントからの送信なのに、gzip圧縮を有効にすればという書き方はサーバーから送信する話に見えるのでそのあたりの理解がチグハグしてそう
ここでいう圧縮て要はWebサーバーとクライアントが自動でやってくれるオプションだから、それに乗せるリクエスト/レスポンスにBase64化したバイナリつけたい場合がないとはいえないとは
圧縮できるのは自明だけど、同じ情報量まで圧縮できるかは分からんでしょ。まぁそりゃなるんだけどさ、バカにしてるやつほどプログラマーとしてはヤバいと思うけど。
ブコメの方が勉強になるのでこういうアホ記事も歓迎です とりあえずZOZO大丈夫か？こんなレベルのエンジニアに記事書かせて
バイナリOKならjpegのままでええやん。パスワードかかるけど
『Base64はデータ量が増える』で思考停止してる人は見かけるので、『gzipでトントン』という発信はそこまで無意味でもないと思うな。(細部はともかく)決定的な誤りがあるわけでもない記事に対して反応が辛辣すぎる。
本文には「HTTP圧縮(Gzip/Brotli)を有効にしていれば」と書いてあるが、タイトルだけだとどのレイヤーでgzipされるか明白でなく誤解している人がいる。本文を読まないのが悪いのだが、こういう不親切なタイトルは嫌い
webのapiサーバが転送目的で画像データを送出する際、バイナリか、base64後のjson等をhttpdのgzipで送るか、どっちでも容量的には変わらんという話ならわからない話でもないだろう。
いやbase64せずにバイナリで送れや。そしてわざわざ記事にせんでもわかる内容じゃろ
理想的なサンプルによるBASE64＋gzipの最適(化)値が元の(ハフマン)圧縮画像のデータより小さくならない証明ができた時点で「やるだけ無駄」の証明になるんじゃないのかな
Gzip圧縮ってWebサーバとかがやるやつ(Content-Encoding)のことで、プログラム側では意識しないところの話でしょ？理解してない上位コメントが多くない？
みんな言ってるけど、Base64がなぜ圧縮できるか以前に、なぜBase64で送る必要があるのか？がよく分からん
Base64はテキストデータで送る必要がある視点しか無かったので変換のところの理解がうまく出来なかった… 精進します。ありがとうございます
「(圧縮)画像を送るのにBase64使ってもHTTP圧縮で結局通信容量は殆ど変わらない」だけなら、まあそうですね、で終わってる話なのかな。解説部分にツッコミが集まってしまった感。
そもそもBase64を使うときはHTMLとか他のテキストフォーマット内に埋め込んで通信の行き来を軽減するとかだろうし、バイナリそのまま送りゃいいというのも違うのでは
え、良い記事じゃん。
シャノン限界の話かな？可逆圧縮の理論限界に近づくのは至って理屈通りではあるな
gzipがbase64の復号に対応してる可能性すらある
“Web APIでJPG画像を送信する際、「バイナリ（multipart/form-data）で送るか」「Base64エンコードしてJSONに埋め込むか」で迷うことがあります。” と冒頭に書いてあるのが読めないブクマカが多くてびっくりする。
ただわかりやすく解説してるだけやのに「あたりまえやろ」って叩かれまくっててかわいそう。
タイトル見て意味なくない？と思ったけど、アプリケーションレイヤーではテキストベースのBase64を使うのが妥当で、HTTPのレイヤーでgzip圧縮でサイズを減らせばテキスト化のデメリットを取り戻せるという話。
いつものQiita民クォリティー。
AIに対して失礼なコメントが散見される
「ハフマン符号は、Base64化によって人工的に引き伸ばされた「8bit表現」を、本来の「6bit表現」に再圧縮して詰め直します。」は明確に誤りでは
画像をBase64で送るとサイズが33%増えるが、Gzip圧縮すれば「ほぼ元通り」になるという話 - Qiita
Base64で送るなら Compression Dictionary Transport (Shared Brotli) を使うと効率良さそう。まだAndroidとPCのChromium系限定だけど。
Gzip圧縮後のバイナリデータを受け付けるなら、そもそもBase64エンコードする必要は⋯という気もしなくはない。(事情は分かるが)
「Base64は重い」っていう思考停止な通説に理論で殴りに行くスタイル、嫌いじゃない。結局リソース食うから一長一短だけど、設計の選択肢としてはアリだな
なるなる。こういう記事たすかる
かういふ ChatGPT 文体の記事を見る度に「本当に実験したのか? ハルシネーションぢゃねえの?」と疑ふやうになってしまった
マッチポンプ感…まあJSONに埋め込む便利さはあるんだろうけど…でも巨大JSONにはなっちゃうなあ
テキスト化した物をバイナリ化するんだからそりゃそうだよね
受け取った側のgunzip後のJSONパースがでっかいJSONノードのパースでメモリ効率が悪いというのが通信のことよりもずっと問題視してた。
Base64は64種類の文字しか出現しないから圧縮できる、なんてほぼ自明で、説明の流れで言ってるとは言え「謎」扱いはモヤモヤする。
何でこんな「どんな形の折紙でも広げれば1枚なのです、折るのは大変だけど」みたい話がブクマされてるの？もしかしてLLMの回答を記事としてキャッシュすればAIの電力消費を削減できるっていう実験？それって検索と何…
本当だわ。やってみたら確かに、10MBのjpeg画像ファイル→(base64エンコード)→13MBのテキストファイル→(zip圧縮)→11MBのzipファイル……となった。
当たり前すぎ。しかも記事の至るところでおかしな記述（"ランダムな英数字"、"実質的な情報量 = bit"、"出現率 100%"など)が見られる。著者がそもそも基本を全く理解しておらず、ところどころAIに書かせたっぽい記事。
当たり前なのでは。
Webのフロントエンドとかやってるやつは、結局、見よう見まねでキーボードをランダムにたたいてるだけではないかという疑いを抱かせる観測事例。
この記事もエントロピーが低いから圧縮して三行にしよう。
ISHだとサイズ増えるけどMNPクラス5で圧縮できる話 歴史は繰り返す
お、おう…
塵も積もれば。無駄な計算資源は使わないに越したことはない。
Base64エンコードしたら効率下がるだろうとは思ってたけど、3割増えるのは知らなかった
氷を溶かすと水になるが、もう一度冷やすと氷に戻るみたいな・・・
普通のサーバフレームワークならmultipart/form-dataもオブジェクトとして扱えるからbase64で送るメリットはほとんど無い。multipart/form-dataが前提でストリームにするか非ストリームにするかの選択かと。
AIっぽさが消えてない
テキストデータとして処理したいから冗長化してまでエンコードしているはずなのにバイナリのまま送るのと比較するのはナンセンス。あとmultipart/form-dataはバイナリじゃないだろ
BASE64が情報密度を下げるけど、圧縮すれば元の情報密度に戻る
当たり前というか、バイナリで送れるならそもそも Base64 でテキスト化する意味はないだろ…
Base64がランダムだと思ってる人、いないとは思うが、いたら暗号化と混同してると思う
面白いよね
当たり前や、んでgzipを送るときはbase64化されるんだから33%増加するだろ 馬鹿なのかな?
圧縮したやつをbase64にして、それを再び圧縮するという設計に、ウッとなる、そういう感覚を大切にしていきたいね
“この特性を理解してアーキテクチャを選定”することがあるのかは気になる
圧縮率の話は別に問題ないと思うけど、multipart/form-dataはクライアントからの送信なのに、gzip圧縮を有効にすればという書き方はサーバーから送信する話に見えるのでそのあたりの理解がチグハグしてそう
ここでいう圧縮て要はWebサーバーとクライアントが自動でやってくれるオプションだから、それに乗せるリクエスト/レスポンスにBase64化したバイナリつけたい場合がないとはいえないとは
圧縮できるのは自明だけど、同じ情報量まで圧縮できるかは分からんでしょ。まぁそりゃなるんだけどさ、バカにしてるやつほどプログラマーとしてはヤバいと思うけど。
ブコメの方が勉強になるのでこういうアホ記事も歓迎です とりあえずZOZO大丈夫か？こんなレベルのエンジニアに記事書かせて
バイナリOKならjpegのままでええやん。パスワードかかるけど
『Base64はデータ量が増える』で思考停止してる人は見かけるので、『gzipでトントン』という発信はそこまで無意味でもないと思うな。(細部はともかく)決定的な誤りがあるわけでもない記事に対して反応が辛辣すぎる。
本文には「HTTP圧縮(Gzip/Brotli)を有効にしていれば」と書いてあるが、タイトルだけだとどのレイヤーでgzipされるか明白でなく誤解している人がいる。本文を読まないのが悪いのだが、こういう不親切なタイトルは嫌い
webのapiサーバが転送目的で画像データを送出する際、バイナリか、base64後のjson等をhttpdのgzipで送るか、どっちでも容量的には変わらんという話ならわからない話でもないだろう。
いやbase64せずにバイナリで送れや。そしてわざわざ記事にせんでもわかる内容じゃろ
理想的なサンプルによるBASE64＋gzipの最適(化)値が元の(ハフマン)圧縮画像のデータより小さくならない証明ができた時点で「やるだけ無駄」の証明になるんじゃないのかな
Gzip圧縮ってWebサーバとかがやるやつ(Content-Encoding)のことで、プログラム側では意識しないところの話でしょ？理解してない上位コメントが多くない？
みんな言ってるけど、Base64がなぜ圧縮できるか以前に、なぜBase64で送る必要があるのか？がよく分からん
Base64はテキストデータで送る必要がある視点しか無かったので変換のところの理解がうまく出来なかった… 精進します。ありがとうございます
「(圧縮)画像を送るのにBase64使ってもHTTP圧縮で結局通信容量は殆ど変わらない」だけなら、まあそうですね、で終わってる話なのかな。解説部分にツッコミが集まってしまった感。
そもそもBase64を使うときはHTMLとか他のテキストフォーマット内に埋め込んで通信の行き来を軽減するとかだろうし、バイナリそのまま送りゃいいというのも違うのでは
え、良い記事じゃん。
シャノン限界の話かな？可逆圧縮の理論限界に近づくのは至って理屈通りではあるな
gzipがbase64の復号に対応してる可能性すらある
“Web APIでJPG画像を送信する際、「バイナリ（multipart/form-data）で送るか」「Base64エンコードしてJSONに埋め込むか」で迷うことがあります。” と冒頭に書いてあるのが読めないブクマカが多くてびっくりする。
ただわかりやすく解説してるだけやのに「あたりまえやろ」って叩かれまくっててかわいそう。
タイトル見て意味なくない？と思ったけど、アプリケーションレイヤーではテキストベースのBase64を使うのが妥当で、HTTPのレイヤーでgzip圧縮でサイズを減らせばテキスト化のデメリットを取り戻せるという話。
いつものQiita民クォリティー。
AIに対して失礼なコメントが散見される
「ハフマン符号は、Base64化によって人工的に引き伸ばされた「8bit表現」を、本来の「6bit表現」に再圧縮して詰め直します。」は明確に誤りでは