文字コード総合スレ 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/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パターンがある

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

>>679
ありがとうございます。
各バイト毎に「桁」を示すbitパターンが、110X XXXX と 10XX XXXX のことだと思いますが、
論理和、論理積を適用すると、前者の場合、X XXXX がどんなビットが来ようとも
110X XXXX が損なわれずに出てくる感じですかね？
まだ全容がわかったわけではないですが、上記イメージで捉えるようにしてみます。

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

Wikipedia のUTF-8 の所に、ビットパターンの規則が書いてある

1バイト目について、
先頭ビットが0なら、1バイト文字
110なら、2バイト文字
1110なら、3バイト文字
1111なら、4バイト文字

2バイト目以降は、先頭ビットが10で始まる

**デフォルトの名無しさん** · 2022/12/14(水) 21:33:02.33

エイリアスも造れてしまうま

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

ぃぇぃ

**デフォルトの名無しさん** · 2023/01/01(日) 02:08:29.39

🎍あけましておめでとう🎍

**デフォルトの名無しさん** · 2023/01/03(火) 15:41:42.10

🐇🐰

**デフォルトの名無しさん** · 2023/01/03(火) 16:08:11.22

全身verと顔verがある動物と無い動物があるのはどういうわけなんだぜ🦖🦕？

**デフォルトの名無しさん** · 2023/01/04(水) 14:20:36.08

履歴書にバストアップ写真貼付
っていうの観て豊胸写真貼るくらいおばかなレス

**デフォルトの名無しさん** · 2023/01/04(水) 20:35:29.99

何それ

**デフォルトの名無しさん** · 2023/02/08(水) 21:44:37.67

au PAYプリペイドカードで取引履歴が表示されない不具合　中、朝、住、今、荻、塚などが含まれる加盟店で
https://www.itmedia.co.jp/news/articles/2302/08/news159.html

これはどういう原理？

**デフォルトの名無しさん** · 2023/02/09(木) 01:12:33.38

>>689
完全に推測だけど、UTF16 にCP1292用とかの特殊処理をしたとか？
そのせいで 0x92 や 0x94 などを含む一部の文字が使えなくなった。

**デフォルトの名無しさん** · 2023/02/09(木) 01:16:30.66

>>690
訂正、UTF16じゃなくてSJIS/CP932だな。

**デフォルトの名無しさん** · 2023/02/09(木) 01:22:16.09

>>690
もいっこミス、CP1292はCP1252のタイポ。英語Windowsで使われるやつのつもり。

**デフォルトの名無しさん** · 2023/02/09(木) 05:00:43.74

うーん不思議だな

**デフォルトの名無しさん** · 2023/02/11(土) 01:16:35.62

マスターカード側(?)ってのがよくわからんね

**デフォルトの名無しさん** · 2023/02/11(土) 04:28:29.30

だからSJISを英語版Windows用のライブラリかフレームワークで処理しちゃったんだろ。
例に上がってるのがどれも該当文字。

**デフォルトの名無しさん** · 2023/02/11(土) 19:52:44.79

なるほろ

**デフォルトの名無しさん** · 2023/02/11(土) 21:12:31.28

Windows, CP932, UTF16 を使っているシステムは、ヤバイ

その点、Linux はUTF8 だけ

**デフォルトの名無しさん** · 2023/02/11(土) 21:17:49.94

LinuxもUnicode文字のパースにはUTF32使ってるでしょ。じゃないと基本多言語面以外の文字を正しく使えないから。

**デフォルトの名無しさん** · 2023/02/12(日) 02:18:07.45

パースパースってここは西オーストラリア州かよ🐨🇦🇺🏴󠁡󠁵󠁷󠁡󠁿🦘

**デフォルトの名無しさん** · 2023/02/12(日) 12:22:59.98

Linux は内部的には、UTF32 も使っているけど、外には出ない。
外部とはUTF8 で統一されている

Windows のCP 何々みたいなものは地獄。
他国語のCPを誰も知らない

例えば日本人だと、CP932 しか知らない。
逆に外人は、誰もCP932を知らない

つまり、外人同士が意思疎通できないシステム

ただし、Linuxでも、iconv を使うけど、
Ruby では非推奨になって、NKF を使う

今では、CP932とか日本語を扱えるのは、Rubyだけだろ。
外人は誰も、CP932など知らない

**デフォルトの名無しさん** · 2023/02/13(月) 13:42:49.90

中 9286 ← 判る
朝 92a9 ← 判る
住 8f5a ← 判らん
今 8da1 ← 判らん
荻 89ac ← 判らん
塚 92cb ← 判る

**デフォルトの名無しさん** · 2023/02/13(月) 16:52:17.70

荻は 948b では？
cp1252 の 0x81 0x8d 0x8f 0x90 0x9d の5文字は未定義文字なので、ライブラリによってはエラーになる。
0x92 と 0x94 はクォートで特殊処理される可能性がある。

**デフォルトの名無しさん** · 2023/02/14(火) 01:45:05.11

互換性を簡単に切り捨てられたLinuxと、互換性を維持しなくてはならないMS-DOSとWindowsを比べるのはただの阿呆。

**デフォルトの名無しさん** · 2023/02/14(火) 08:08:42.98

当時ISO2022 という規格があったのに
CP932 などというふざけた規格を作ったのが悪い

**デフォルトの名無しさん** · 2023/02/14(火) 15:06:25.61

別にふざけてたわけじゃない
当時の日本のPCはJIS X 0201との互換性のほうが重要だったってだけ

**デフォルトの名無しさん** · 2023/02/14(火) 18:56:57.73

えっと、JISX0201 は ISO2022 に従ってますよ
CP932 なんていらんかったんや

**デフォルトの名無しさん** · 2023/02/14(火) 19:37:48.59

シフトJISの主目的はバイト数の節約なので、ISO2022系は許容できなかったんだよ。
当時のPCとしては1バイトでさえ貴重な資源だった。
メモリの容量が100万倍になった現在から見たら笑い話だけど。

**デフォルトの名無しさん** · 2023/02/15(水) 03:33:04.77

結局CP1252説はまだ正しいのかわからんのね

**デフォルトの名無しさん** · 2023/02/15(水) 22:31:23.74

>>706
マイクロソフトは悪くいうのに、IBMは悪くいわないのか？

**デフォルトの名無しさん** · 2023/02/15(水) 22:32:45.87

>>706
日本語がマルチバイトの先駆けだったので、中国は何もかも楽だった。

**デフォルトの名無しさん** · 2023/02/16(木) 04:27:13.71

>>710
中国語とかのコードって普通に片仮名平仮名入ってるよね

**デフォルトの名無しさん** · 2023/02/16(木) 08:17:07.88

>>709
EBCDICのこと？だってその頃はISO2022ないじゃん
でも、System 360 は素晴らしいと思うよ

**デフォルトの名無しさん** · 2023/02/16(木) 21:02:08.08

EBCDICなんでアルファベットのコードの真ん中に穴を開けたのか?

**デフォルトの名無しさん** · 2023/02/16(木) 23:08:48.64

>>713
パンチカードがBCDだったから。16進数でいう A～F が使えなかった。

**デフォルトの名無しさん** · 2023/02/17(金) 22:53:38.58

>>712
IBM932は問題ないのか？

SJISは拡張部分の定義がバラバラ。

JISはもっとひどかったから、まだいいんだが、UTF-8とUTF-16の混在という問題はまだ解決していない。

マイクロソフトのSJISは日本語キャラクタセットの統一という成功を収めたが、UTF-8とSJISの相性が悪いのはどうにもならない。

日本人が日本語のキャラクタセットを決められない状況では、中国人が決める日本語キャラクタセットに日本人は従うしかない。

**デフォルトの名無しさん** · 2023/02/17(金) 23:31:54.88

SJIS は時代遅れ。結論が出てるんだから捨てれば良い。
何が統一なんだか。一瞬足りとも統一されたことなんて無かった。

**デフォルトの名無しさん** · 2023/02/18(土) 00:27:33.20

>>716
SJISで統一して成功したシステムは多い。
UNIXとWindowsの組み合わせではSJISでの統一が正解だった。

**デフォルトの名無しさん** · 2023/02/18(土) 03:18:28.78

>>717
妄想乙

**デフォルトの名無しさん** · 2023/02/18(土) 05:11:11.00

これは興味深いなり

**デフォルトの名無しさん** · 2023/02/18(土) 06:39:14.59

>>715
時系列が無茶苦茶
CP932が作られたかIBM932が生まれた
何故わざわざ空けてあるC1領域を使ってしまったのか

**デフォルトの名無しさん** · 2023/02/18(土) 12:24:41.58

>>717
UTF-8以前の話なら
UNIXとWindows混在ならEUCが正解

**デフォルトの名無しさん** · 2023/02/18(土) 12:26:20.12

>>720
IBMは昔からわざとちょっと変な仕様追加するのが好きで
M$と不仲になってさらにその傾向が増長したのでは

**デフォルトの名無しさん** · 2023/02/18(土) 13:59:14.80

>>721
それは逆だ。Windowsを使っていると無意識にSJISになるので、UNIX側をSJISにすればポンコツがいても問題は発生しにくい。

**デフォルトの名無しさん** · 2023/02/18(土) 16:21:02.46

UTF8出来てから30年、RFCになってから20年にもなるのに未だにSJISとかアホか
お前らもう20世紀に帰れ。今の時代に不要な人材

**デフォルトの名無しさん** · 2023/02/19(日) 00:00:17.41

この話の流れはともかくとして、SJIS人材は、必要。

**デフォルトの名無しさん** · 2023/02/19(日) 13:36:16.30

そう言えば eucjp-open と Unicode にはあるのに windows--31j に無い文字って結構沢山あるのな。

**デフォルトの名無しさん** · 2023/02/19(日) 13:38:43.70

Windows では環境依存文字扱いになってメモ帳に入力できるが UTF-8 にしないと保存出来ない。

**デフォルトの名無しさん** · 2023/02/19(日) 15:08:09.17

>>724
Windowsは表面がSJIS、内部がUTF-16だ。

これをUTF-8にすべて置き換えるには、あと数十年はかかる。

**デフォルトの名無しさん** · 2023/02/19(日) 15:10:04.88

>>727
メモ帳を進化させて、環境依存文字がないようにUTF-8の文字を使うようにしたから、自動的にUTF-8になる。