文字コード総合スレ part13

**デフォルトの名無しさん** · 2020/07/03(金) 20:53:47.08

Windows NTは初代からUnicodeがネイティブの文字コードです。cp932ではありません。
プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
UTF-8、Shift_JIS、JIS、EUC、Unicode、UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。

■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/
　（スレ再利用）UnicodeとUTF-8の違いは？ http://pc12.2ch.net/test/read.cgi/tech/1177930957/
　（隔離スレ）UnicodeとUTF-8の違いは？　その2 http://pc12.2ch.net/test/read.cgi/tech/1274937437/
文字コード総合スレ part5 http://pc12.2ch.net/test/read.cgi/tech/1236529563/
文字コード総合スレ part6 http://hibari.2ch.net/test/read.cgi/tech/1278923059/
文字コード総合スレ part7 http://toro.2ch.net/test/read.cgi/tech/1306595564/
文字コード総合スレ part8 http://peace.2ch.net/test/read.cgi/tech/1354248962/
文字コード総合スレ part9 http://peace.2ch.net/test/read.cgi/tech/1401301779/
文字コード総合スレ Part10 http://mevius.2ch.net/test/read.cgi/tech/1444822140/
文字コード総合スレ Part11 https://mevius.5ch.net/test/read.cgi/tech/1516629503/
文字コード総合スレ Part12 https://mevius.5ch.net/test/read.cgi/tech/1544931495/

**デフォルトの名無しさん** · 2022/08/16(火) 11:08:43.06

地球外の惑星人の言語が見つかりだしたらあっという間に埋まるだろう

**デフォルトの名無しさん** · 2022/08/16(火) 16:32:26.25

>>579
明朝体とゴシック体を丸ごと登録はありえないけど、甲骨文字、金文、篆書あたりの楷書より古い字体は古代文字扱いで丸ごと登録とか、可能性がゼロではないんだよな。
現在の漢字では失われて甲骨・金文にしかない文字とかもあるので。

**デフォルトの名無しさん** · 2022/08/17(水) 01:36:20.68

音が出るコードが U+0007 以外にも沢山作られて・・・

**デフォルトの名無しさん** · 2022/08/17(水) 01:41:52.37

>>582
よし、パパ全ての音階を符号化しちゃうぞ。
といっても半音単位で人間の耳に聞こえる音と楽譜にある長さ全部登録しても余裕そうだが。楽器ごとに別の符号を準備するか？

**デフォルトの名無しさん** · 2022/08/17(水) 01:47:12.74

日本の変体仮名もマイナー過ぎるもの以外はあらかた登録されことを踏まえると、第三漢字面は甲骨文字等で埋まることになりそう（実際に登録された場合、今後数百年で最後の大規模登録になるはず）

**デフォルトの名無しさん** · 2022/08/17(水) 08:36:52.62

どれだけ文字が増えてもASCIIとの互換性は維持しなきゃいけないんだろうなぁ

**デフォルトの名無しさん** · 2022/08/17(水) 09:04:59.81

甲骨文字はまだ研究中できちんと体系化できてなくて、これとあれは同じ文字だと思っていたが実は別の文字だったとか、見た目全然違うけど同じ文字とか、いまだにやってるし、研究者によって意見が違ったりする。
登録するとなるとかなり先になりそう、もしくは見切り発車的に現状の字形の見た目だけで登録するか。

**デフォルトの名無しさん** · 2022/08/17(水) 12:03:40.31

>>577
スマートやね

**デフォルトの名無しさん** · 2022/08/18(木) 20:52:25.67

任意多倍長文字コード…

**デフォルトの名無しさん** · 2022/08/20(土) 02:24:45.92

>>562
文字に関しては、時代が進めば解析できていない古代文字がわかるようになるわけではない。

宇宙人が現れないかぎりは、絵文字が増える程度。

**デフォルトの名無しさん** · 2022/08/20(土) 02:27:00.88

可能性としてはフォントごとに文字が登録されることになると収まらなくなるな。

**デフォルトの名無しさん** · 2022/08/20(土) 12:56:39.98

>>589
いや、古代文字の解析はちょっとづつでも進んでるよ。それで埋まったりしないだろうけど。
あとユニコードには意味不明のまま形だけで登録されている古代文字もあるので、解析されてなくても良いという。

**デフォルトの名無しさん** · 2022/08/20(土) 15:44:41.14

こんなやつか
https://www.tanqfamily.com/post/suuji

**デフォルトの名無しさん** · 2022/08/21(日) 02:25:17.60

>>591
はっきり言ってわからないことはわからない。遠い過去のことを必死に解明しようとなんてしない。

**デフォルトの名無しさん** · 2022/08/21(日) 03:05:58.69

歴史学否定派w

**デフォルトの名無しさん** · 2022/08/21(日) 10:03:23.55

読めねぇ orz
鱼 U+9C7C
鱻 U+9C7B
䲜 U+4C9C
https://kanji.jitenon.jp/cat/bushu11001.html

**デフォルトの名無しさん** · 2022/08/21(日) 21:12:42.94

🐟

**デフォルトの名無しさん** · 2022/08/22(月) 15:43:07.04

>>595
森とか品とかは日常的に使ってるわけですし

**デフォルトの名無しさん** · 2022/08/22(月) 19:06:10.43

鮮は鱻と羴の組み合わさった漢字、という説もあるようですね

**デフォルトの名無しさん** · 2022/08/22(月) 19:13:20.22

巧言令色鮮し仁
こうげんれいしょくすくなしじん
（「論語‐学而」にみえる孔子の説いたことば）
ことば巧みで表情をとりつくろっている人は、かえって仁の心が欠けているものだの意。

**デフォルトの名無しさん** · 2022/08/22(月) 19:20:47.37

鱼は魚の簡体字のようだが、ソース分離のパティーンなのかな

**デフォルトの名無しさん** · 2022/08/22(月) 19:25:14.80

あ簡体字繁体字はそっか

**デフォルトの名無しさん** · 2022/08/23(火) 00:11:38.72

澁→渋みたいに3つ並んでるやつの下2つを＞＜で省略するのって日本ローカル？

**デフォルトの名無しさん** · 2022/08/23(火) 12:27:00.71

......🐟............

䲜䲜䲜䲜䲜䲜䲜䲜
䲜䲜䲜䲜䲜䲜䲜䲜

**デフォルトの名無しさん** · 2022/08/23(火) 12:27:52.24

..凹..凹..凹..凹..

..........凸......

**デフォルトの名無しさん** · 2022/08/23(火) 17:31:29.10

0208で表現可能じゃないかw

**デフォルトの名無しさん** · 2022/08/24(水) 09:32:11.96

murataのCMかよ

**デフォルトの名無しさん** · 2022/08/25(木) 22:40:43.43

だれかマヨビームして

**デフォルトの名無しさん** · 2022/08/26(金) 09:51:20.37

うざったてー

**デフォルトの名無しさん** · 2022/09/14(水) 05:33:42.06

ここ人がいなくなるとばたっといなくなるな

**デフォルトの名無しさん** · 2022/09/16(金) 15:08:56.61

Unicodeバージョン 15.0リリース ―CJKの表意文字など4,489文字が追加
https://gihyo.jp/article/2022/09/unicode15

**デフォルトの名無しさん** · 2022/09/17(土) 05:27:23.56

毎回絵文字で話題を呼ぶ戦略もそろそろネタ切れか

**デフォルトの名無しさん** · 2022/09/17(土) 06:46:26.46

絵文字の文字数はあまり増えてないけど、合成パターンが派手に増えて、面倒過ぎることに。

**デフォルトの名無しさん** · 2022/09/17(土) 12:44:09.49

次は動いたり光ったりする絵文字

**デフォルトの名無しさん** · 2022/09/17(土) 18:58:46.03

それはガラケーが15年ぐらい前に通った道だ

**デフォルトの名無しさん** · 2022/09/17(土) 19:43:06.21

次は飛び出す絵文字とお喋りする絵文字だよ

**デフォルトの名無しさん** · 2022/09/17(土) 22:02:20.28

絵文字はいいから
歩と香杏桂圭銀全金飛龍角馬王玉
の逆さ文字を登録してほしい

**デフォルトの名無しさん** · 2022/09/17(土) 22:19:44.75

とりあえず一個作ったよ
つ王

**デフォルトの名無しさん** · 2022/09/17(土) 22:30:43.46

肌色や性別より反転や回転が欲しい

**デフォルトの名無しさん** · 2022/09/17(土) 22:37:03.11

>>616
つ異字体セレクタ

**デフォルトの名無しさん** · 2022/09/18(日) 00:02:30.98

>>619
環境によって逆向きにされるかもしれないのはだめじゃない？
逆だと意味がひっくり返るんだから

**デフォルトの名無しさん** · 2022/09/18(日) 01:19:36.82

ちゃんと盤面が表示される保証がないといけないですよね

**デフォルトの名無しさん** · 2022/09/18(日) 01:21:24.86

>>617
王は逆向きに配置されることはありえません、無駄な仕事ご苦労なことです

**デフォルトの名無しさん** · 2022/09/18(日) 02:21:35.78

>>620
確かにそうなんだよね。。。ただ、年次のUnicode規格が社会に浸透していく過渡期には常に付きまとう問題であって異字体に限った話ではないように思える
それと同時に、異字体（少なくとも漢字の異字体）に意味の違いを含めてしまう（意味の違いを見出す運用を前提としてしまう）と問題が生じることのわかりやすいモデルケースでもあるとも思った

**デフォルトの名無しさん** · 2022/09/18(日) 02:24:07.74

>>622
古のドラクエで使われた「り」メソッドであって、実は何もしていないという

**デフォルトの名無しさん** · 2022/09/18(日) 02:33:42.02

>>624
んなことわかってんだよ、アホンダラ、死ね

**デフォルトの名無しさん** · 2022/09/18(日) 02:38:02.45

>>623
異議を唱えます
本来漢字に正字と異字という区別はなく、どの漢字も平等であるべきなんですよ
Unicode はすべての字（letter and character) を収録する、という建前である以上、異字体コレクターの存在自体が自己矛盾と考えます
CJK 漢字統合など、ダメリカ様の都合で決まった醜悪な存在、でも、結局 16 ビットに収まらなかったという体たらくになりましたよね…

**デフォルトの名無しさん** · 2022/09/18(日) 03:18:17.32

同じ人相手でレスごとに態度豹変するの笑う

**デフォルトの名無しさん** · 2022/09/18(日) 03:19:36.25

>>623
未対応で何も表示されないだけならいいのよ
未対応で逆のものが表示されるのは困るのよ

**デフォルトの名無しさん** · 2022/09/18(日) 09:50:27.91

異体字セレクターでも新コードポイントでもフォント作ってくれれば問題ないよ。
それより同じ漢字を複数箇所に登録するのをやめてくれ。基本漢字はあれだけ無理矢理ユニファイしたくせに、その後はチェック甘くて完全に同じ字形が新規登録されることがある。

**デフォルトの名無しさん** · 2022/09/18(日) 10:01:21.85

>>629
もし良ければ、近年の具体例を教えて欲しい

**デフォルトの名無しさん** · 2022/09/18(日) 11:28:41.95

閉て
>>630
どれくらい近年を求めてるのかは知らんが
私が気づいたのは U+3588 と U+439B の（老/口）とか。
これどう見ても同じ漢字を口部と老部に二重登録しただけやろ。
U+29FCE と U+29FD7 の（予鳥）の違いとかもわからん。

**デフォルトの名無しさん** · 2022/09/18(日) 13:19:58.23

>>631
20年以上前に追加された文字同士を例にとって「チェックが甘くて...新規登録されることが"ある"」と表現するのはどうかと思うよ（「あった」ならまだしも...）
当時と現在のチェック体制を事実上同一視した上で「やめてくれ」と懇願する姿勢も同様

**デフォルトの名無しさん** · 2022/09/18(日) 13:32:38.16

>>632
基本漢字とその後って言ってるのに、最近って言いかえるお前の定義ってどうなってるの？
問題は問題だろ、それともお前全チェックして、俺がたまたま気づいたこの2つ以外は問題がないと言い切れるの？

**デフォルトの名無しさん** · 2022/10/02(日) 09:38:14.71

Unicode をレンダリングするときは言語情報を渡しましょう
https://blog.8-p.info/ja/2022/09/30/unicode/

**デフォルトの名無しさん** · 2022/10/07(金) 06:10:39.92

>>634
よくある言語の優先順位ってどういうときに役立つのかよく知らなかったりw

例えば 1.英語 2.日本語としていても、英語と日本語が混ざったドキュメントの場合に
日本語部分が中国フォントで処理されたり。この挙動には関係ない設定なのかな?

中国語のフォントもひらがなとか持ってるから、フォントのコードセットだけ見て
その中国語のフォントが日本語もおkとされて使われてたりする?
（たしかfontconfigとかそんな挙動だった記憶が）
日本語と認識してるが中国フォントで表示しているのか日本語と認識してもいないのか

**デフォルトの名無しさん** · 2022/10/07(金) 09:05:35.88

>>635
アプリが対応しているかとか、フォントが対応しているかとか色々ある。
最近のオープンタイプ形式のフォントとかだと同じ文字コードに複数の字形を持っていて、アプリが対応していれば言語設定に従って字体を自動的に切り替えてくれたりする。アプリが対応してなければデフォルトの字形が使われる。

**デフォルトの名無しさん** · 2022/10/08(土) 05:58:47.54

結局>>634に書いてあることのうち、ユーザー側の言語情報というのはあまり重要じゃ
なくてデータ側の言語情報というのがより大事なのかなと

ぶっちゃけコンピュータの利用というのは圧倒的に向こうからやってくるデータの
処理だし。ユーザの言語設定が日本語でも、中国語のテキストが来たらそれは
中国語のフォントで処理してほしい

**デフォルトの名無しさん** · 2022/10/08(土) 06:16:01.16

>>637
データ側に言語情報があったあら、レンダリングやレイアウトにその言語情報を使うのは基本中の基本で、当たり前過ぎて議論の対象にならんのでは。
データに言語情報がない場合にどのようにするかという問題。手抜きアプリだとフォントのデフォルトを使う。そしてフォントのデフォルトが中国字形になってるとか良くある。

**デフォルトの名無しさん** · 2022/10/08(土) 12:17:20.96

>>638
言語情報が付いてなかったら本当は言語推定とかした方がいいと思うけどね
文字コードで言語統合してしまった分、分離のコストを支払う必要があるということ
ユーザーの設定は推定できなかった場合の最後の手段かな
普通は言語推定とかいちいちしないからユーザー設定頼みのみと

**デフォルトの名無しさん** · 2022/10/08(土) 12:24:41.42

>>639
言語タグが英語で文章も英語でその中に漢字で「骨」の一文字だけ含まれてる場合はどの国の字体で表示すベき？
言語推定とか無意味、字体推定とかできれば別だが、そんなの論理的に不可能。

**デフォルトの名無しさん** · 2022/10/10(月) 20:05:36.45

>>635みたいに優先順位の設定がある場合は
一度英語と判定した文書中でも漢字が出てきたらそれに立ち返って参考にすべきかもしれない、
みたいな考え方はあり得るかも。

**デフォルトの名無しさん** · 2022/10/11(火) 07:48:39.31

青空文庫がCP932しばり(Shift_JISではない)なのはなぜなんだぜ？

**デフォルトの名無しさん** · 2022/10/11(火) 08:25:59.56

>>640
もちろん最後の手段に近い話だよ
Unicode自体は、マルチリンガルはあまり考えてないわけでしょ。事実上
一つのコードセットをいろんなモノリンガルで使うのが基本。だからUnicodeだけで
マルチリンガルがいけてなくても当た前
Unicodeの英語の中に一個だけ「骨」とかもうね、責めるならUnicodeの中の人をw
その上で、多少はどうにかするなら、という話

**デフォルトの名無しさん** · 2022/10/11(火) 09:09:02.40

今から unicode を何とかするのなら完全 IVS化かなあ。
IVS の登録を全面拡大して、漢字を書く際には著者が使用した字体のIVSをつける。
IVSのついていない漢字は「著者が字体にこだわりは無く読者の好み字体で表示することを指定した」というルールにする。
字体にこだわるとテキストのサイズが増えるけど今の環境なら特に問題にはならないだろ。

**デフォルトの名無しさん** · 2022/10/11(火) 20:10:00.97

1文字ずつつけるんじゃなくて新たに囲み用の言語指定マーク作ってもいいんでは？
既にLTR/RTL指定とか「ここからここまでルビ」みたいなマークがあるんだから。

どっちの方法でも実効性が現れるかどうかは「メジャーな環境が(入力ユーザーが気にしていなくても)デフォルトで付けるかどうか」次第だけど、
完全IVS化だと漢字圏のテキストがほぼ倍になる、そんなのをデフォルトにする判断を各社が果たしてするんだろうか？

**デフォルトの名無しさん** · 2022/10/11(火) 21:16:13.21

>>645
普通の人は字体にこだわらないから付けないだろうし、字体にこだわる著者はサイズが倍以上になってもつけるだろうし選択権が著者側にあるのが良いと思うんだよな。もはやテキストサイズとか誤差の範囲でけちる理由ないし。
日本語と中国語が混じった国際的な文章を書きたい場合とか、1文字単位で指定できるのが重要というか。

**デフォルトの名無しさん** · 2022/10/11(火) 21:31:15.03

>>644
たしかにそうすればCJK混在のテキストであっても、文字単位でそれぞれ正確に字体を表示できるね

ただし、そのままでは視覚的に「1. 完全IVS化仕様に基づいてIVSで修飾された漢字」と「2. 既存の個別コードポイントの漢字」の区別ができないが故に、テキスト作成時にIMEやエディタ側でその違いを視認できるような仕組みが必要になる気がする
それから、上記1,2双方の漢字を検索等で相互にマッチさせるにはUNICODE正規化仕様に手を入れればよいのだろうか？あまり詳しくないけど、その実現手段がない場合は色々とカオスな状況を招きそう

当たり前だけど、当該仕様を必要とする漢字圏のテキストサイズが倍近くなってしまう点もなかなかにキツい（それでも非漢字圏の言語に対する圧倒的な情報密度は揺るぎないが...）

**デフォルトの名無しさん** · 2022/10/11(火) 23:02:41.36

>>647
検索に関しては今の正規化検索が仕様通り実装されてれば、そのままでいけると思う。

**デフォルトの名無しさん** · 2022/10/11(火) 23:13:45.33

>>64
そのまま、とは?

**デフォルトの名無しさん** · 2022/10/11(火) 23:14:14.94

>>648
安価ミス

そのまま、とは?

**デフォルトの名無しさん** · 2022/10/12(水) 00:57:28.78

>>650
異体字セレクタは正規化の対象外である一方で無視可能な結合クラス0の結合文字なので、表示／検索系での無視する／しない、個別に可視化する／しないのような制御の対象にできる。
規格本体には手を入れなくても、そのままでも大丈夫だろうという意味。もちろんアプリの対応はいるし、IVDの大幅拡張がいるのだけど。

**デフォルトの名無しさん** · 2022/10/12(水) 01:14:40.26

>>646
普通の人がつけなかったら今回の元の話の解決(緩和)にならないと思う。
日本語IMEで入力したらデフォで日本語書体指定になっている、というのが必要かと。

**デフォルトの名無しさん** · 2022/10/12(水) 01:15:05.77

書体よりも字形のほうがいいか

**デフォルトの名無しさん** · 2022/10/12(水) 10:12:03.10

>>652
元の話で言えば、利用者はレンダリングの際に言語情報ではなく、好みの字形情報を渡すようにしようということになるだけだよ。
著者が特定の字形を指定している場合はその字形で表示される。著者が字形を指定しない場合は読者の好みの字形で表示される。
字形情報と言語情報は別ベクトルなので一緒くたに扱うのはやめようとい話。
もしこの方法が普及したら字形にこだわりの強い日本人は、緩やかに差異のある漢字全てにIVSをつけるように移行して行くと思う。（サイズが小さいメリットより字形の指定が出来るメリットが上回ると考える人が多くなりそうという予想）

**デフォルトの名無しさん** · 2022/10/12(水) 13:50:34.84

たどればわかるが元の話は海外産ゲームの日本語とかの話題だよ

**デフォルトの名無しさん** · 2022/10/12(水) 14:15:20.45

>>655
ゲームがユーザ情報の好みの字体を使用するようになれば良いのにねという意味だけど。何か矛盾してる？

**デフォルトの名無しさん** · 2022/10/12(水) 17:59:58.38

>>654>>656
「ユーザ情報」ってのがわからんがその枠組みだとユーザーじゃなくてゲーム製作(日本語版製作)側がIVS付けるかどうかにかかってくるんじゃないの？
で、ユーザーの声を聴いてIVS付けてくれるような体制のとこは現時点でも日本語フォント指定ぐらいできるんでIVSの出る幕はないような。

**デフォルトの名無しさん** · 2022/10/12(水) 18:06:05.49

字形と言語は固定の関係ではない、という思想が根っこにあるのは理解したけど、20世紀後半以降の各国の漢字政策を経て固まった今現在の現実に即した思想かどうかは正直疑問。
増殖してしまった異体字について「本来は同じもの」と言ったところでどうしようもないのと似た理想論な感じがする。

**デフォルトの名無しさん** · 2022/10/12(水) 18:34:29.78

>>658
でもな、日本国内でも古い本や文献を引用したり、人名地名とかだと台湾と同じ字体が出てきたりするんだよ。これに中国繁体字のタグ付けるのは間違ってると思わないか？

**デフォルトの名無しさん** · 2022/10/12(水) 18:53:53.43

そういうのはIVSつければいいんじゃね？

**デフォルトの名無しさん** · 2022/10/13(木) 00:52:39.79

>>660
だから、そういう話だよ。いまのところ IVD が不十分なので役に立たないけど。

**デフォルトの名無しさん** · 2022/10/13(木) 18:18:17.03

どの方式にしろ、この問題の解消のためには入力環境側がデフォルトで字形情報を埋め込まないとだめなのよ。
受け手になる現代の日本語話者にとって許容範囲外の字形に化ける可能性があるのに入力者にはそれが見通せないんだから。

**デフォルトの名無しさん** · 2022/12/01(木) 05:16:11.16

今どきのEメールのエンコーディングって何が標準ですか?
gmailで試したら、MIMEでUTF-8 + Base64になりましたけど（かつテキストの属性の有無で
htmlかplainのマルチパートになる）、これって「標準」?
ISO-2022-JPとかあまり使わない感じ?

**デフォルトの名無しさん** · 2022/12/01(木) 08:59:44.12

GmailもThunderbirdもUTF-8だけになってしまいましたね。デファクトスタンダードなのかな?

**デフォルトの名無しさん** · 2022/12/01(木) 18:25:26.50

まあ、絵文字使いたいよね

**デフォルトの名無しさん** · 2022/12/02(金) 08:15:06.11

孫は歴史的偉人

**デフォルトの名無しさん** · 2022/12/02(金) 09:35:18.27

今でも7ビットの制約とかあるんだっけ
いずれにせよMIMEのエンコードをするから別にISO-2022-JPじゃなくてもいいと

**デフォルトの名無しさん** · 2022/12/02(金) 11:55:24.27

実は7bit制約もインターネットの場合は存在しない。
昔ながらの個別メール網とメール交換する際の互換性のために7bitが必要だっただけだが、そういうのは滅びたかゲートウェイで7－8変換するようになったので。
そういう意味で生UTF8で十分。

**デフォルトの名無しさん** · 2022/12/02(金) 17:25:39.59

えっと、RFC（現在は何番かな... 5322でおk?）に書いてあるUS-ASCII、というのは
生きてるわけですよね?
その上でMIMEを使えと

**デフォルトの名無しさん** · 2022/12/02(金) 18:40:42.32

>>669
そうだよ。US-ASCII 以外の文字コードを使用する場合は原則MIMEヘッダーで本文の文字コードを指定しなければならない。

原則というのは
・送信者と受信者の間で暗黙もしくは明示の合意がある場合は例外。
・多くのメール・クライアントは文字コードを自動推定をする機能があるのでMIMEヘッダーを省略してもたいてい機能する。
・その後に、RFC6531 で SMTPUTF8 が導入され、RFC6532でメールヘッダーもUTF8対応に拡張されている。

要はデフォルトを US-ASCII から UTF8 に置き換える方向で進んでいる。
インターネットは一気に全体が更新されるわけではないので従来的なやり方が安全といえるけど、ユーザーがメールクライアントを更新したら裏で勝手にUTF8になっている可能性がある。

**デフォルトの名無しさん** · 2022/12/03(土) 18:46:41.61

ぼくはquoted-printableちゃん

**デフォルトの名無しさん** · 2022/12/04(日) 08:41:14.63

>>671
ASCIIに関しては便利なやつね。それ以外は効率が落ちるという
まるでUTF-8のようなw
基本的な日本語が2バイトで収まるエンコーディングは無理かのう... ってUTF-16かw
いえ、UTF-8とUTF-16のいいとこ取りはできないかなあと

**デフォルトの名無しさん** · 2022/12/04(日) 10:24:48.68

>>672
みんな大好きシフトJISなんてどうですか

**デフォルトの名無しさん** · 2022/12/04(日) 10:55:56.31

絵文字のない文字コードなんて今更

**デフォルトの名無しさん** · 2022/12/04(日) 11:12:22.45

>>672
まあ ISO-2022-JP

**デフォルトの名無しさん** · 2022/12/04(日) 17:49:01.09

>>674
ドコモかauかソフバンの拡張を正式採用したらいくらかは入ったことにできる

**デフォルトの名無しさん** · 2022/12/11(日) 17:16:35.20

文字コードの、それもパーセントエンコードに詳しい方教えてください。

たとえば、π(pi)をパーセントエンコードすると、%CF%80ですが、このCF、80を生成するプログラムが本に掲載されていたので
解読しています。

πに対応するコードである、960を64で割った商15をさらに、15 Or 192で論理和を求めると207となって、
207を16進数で表すと、CFを求められるとする過程はわかったのですが、
最後の論理和を求めるところで、なぜ論理和が使われるのかということと、相手に192という値が選ばれているのかが
皆目わかりません。

論理和と論理積を解説するサイトを見ても、True と False のペアを評価するのみで
この手の応用について解説されるサイトは無さそうでした。

コードはNo.128 ～ No.2047 (0080～07FF)の範囲でお願いします。

**デフォルトの名無しさん** · 2022/12/11(日) 18:25:00.06

>>677
UTF8 で検索してみ

**デフォルトの名無しさん** · 2022/12/11(日) 19:07:45.94

>>677
パーセントエンコードの仕様はよく分からんけど、対象のコードポイントをUTF8で符号化した値そのまんまっぽい気がする
UTF8のバイト表現は可変長なので、各バイト毎に「桁」を示すbitパターンがある