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で車載実況配信とかも出来るかも？＞＜