orange @[email protected]

でももし実際に数字用と汎用で符号位置わけたとして、例えば地名のn丁目は、「一丁目」という地名であり 数字+「丁目」ではない問題があるので、どっちで書けばいいのか難しくなって、「なんでhoge丁目はソート失敗するの！？」って混乱が起きたり、「『八丁堀四丁目』ってどれが数字！？」みたいな大混乱が・・・＞＜；

たぶん、漢字使わない文化圏の人から漢数字を見たら「ローマ数字のIと普通のIは別の符号位置なんだから、数字の一とそうじゃない一も別の符号位置にしやがれデース」って思ってるかもしれない＞＜(思ってないかもしれない)

そもそも、漢数字以外の数字の体系で、数字としての用途に限らず数字を使う(例えば単語中の文字として使う)文化圏な単独の文字コードが割り当てられた「数字 かつ 文字」って、漢数字以外にもあるんだろうか・・・？＞＜

数字 - タイ文字 - Wikipedia https://ja.m.wikipedia.org/wiki/%E3%82%BF%E3%82%A4%E6%96%87%E5%AD%97#%E6%95%B0%E5%AD%97

x音声データやの
o音声データの
(画像のってつけようとしたけど、画像では通常の手段より圧縮出来ない気がしてきてカットしたら「や」が残ってた＞＜；)

実用上は意味無さそうだけど、音声データやの非リアルタイムな受信であれば、相互にいい感じのアルゴリズムで予想して、クライアント側では予想するデータを多数投げて(上り大容量)、サーバー側では一番近いものがどれであったか応答する(下り小容量)方式で絞りこんでく方式でもそこそこ圧縮できそうな気がする＞＜

逆で、超巨大辞書をクライアント側に持たせてサーバーに応答してもらう事で仮想的に『大容量アップロード』を『大容量ダウンロード』かのように使うみたいな意味だと、圧縮の実用上たぶん無理があるし、実用化されてる方式で言うとVQ圧縮に近いものになる？＞＜；

ということはオレンジが書いてる時分割カタログ方式も一応(実用性は謎だけど)、「1バイトのリクエストで巨大なカタログから巨大なひとつのデータを選び送ってもらう」って出来るので、一応クリアしてるっぽい？＞＜；

おささんが想定してるのって「ウェブサーバーとクライアント的なやつの、クライアントからウェブサーバーへのリクエストのデータ量を最小にする」みたいな意味とオレンジは理解したけど、違うのかも？＞＜；

オレンジ方式、たぶんシーズンIDを1bitにしたら失敗するので、1バイトの応答でやるならば1シーズン辺り6bitが限界かも＞＜

例えば1分で変更x4シーズン(？)で、2bitでシーズン、残りの6bitで64のIDのカタログを提示って形にすれば、1分辺り64個提示で受け付け時間(寿命)が3分強のカタログが1バイトの応答で出来るかも＞＜

意味がよくわからないけど、ごく小容量の通信と制限なしの通信で非対称の通信で、小容量側がリクエストで大容量側が実データだとしたら、巨大なカタログを投げつけて、そのカタログにあるIDをある程度時分割で投げ返せばいいんでは感＞＜(説明難しい＞＜；)

4Kで車載実況配信とかも出来るかも？＞＜

オレンジもそう思った＞＜；