文字コード総合スレ Part12

**デフォルトの名無しさん** · 2018/12/17(月) 16:48:24.47

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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 http://mevius.5ch.net/test/read.cgi/tech/1516629503/

**デフォルトの名無しさん** · 2021/04/23(金) 13:53:41.29

>>896
CはASCII互換である必要はないが、
C言語文字列互換、つまり「文字列終端が\0」互換でなければならない
EBCDICはC言語文字列互換だが、UTF-16とUTF-32は互換性がない

**デフォルトの名無しさん** · 2021/04/23(金) 22:37:45.17

>>898
意味わからない。wchar はC言語とは認めない主義の人かな？

**デフォルトの名無しさん** · 2021/04/23(金) 23:40:40.33

別にnull終端文字列を使うのがスタンダードかつ標準ライブラリもそう期待しているというだけであって、好きに実装したらいいよ
ぶっちゃけ舐めないと文字列長決められないので性能がスケーラブルでないし、null文字衝突の問題もあるし筋が良くない
マトモなCで書かれたテキスト関連アプリ、特にエディタでヌル終端文字列使ってるのなんて皆無だろ
普通はrope、もう少しカジュアルならパスカルストリング

**デフォルトの名無しさん** · 2021/04/23(金) 23:42:50.22

wcharω

**デフォルトの名無しさん** · 2021/04/23(金) 23:45:37.62

そもそも今時ゴミstdlib引いてC書く時点でアッて感じだし(組み込み等以外)

**デフォルトの名無しさん** · 2021/04/24(土) 01:15:41.82

>>899
え？C言語の仕様にwchar_tを使うmainが無いんだからら
C言語の問題でしょうが

**デフォルトの名無しさん** · 2021/04/24(土) 01:31:51.75

wmain() ってC言語じゃないの？

**デフォルトの名無しさん** · 2021/04/24(土) 11:01:26.61

>>902
Linux/Unix のプログラムはほとんど stdlib 使ってるけど、何か問題でも？
exit() とかの基本関数は stdlib にあるんだよ。

**デフォルトの名無しさん** · 2021/04/24(土) 11:04:54.55

OS l17n

**デフォルトの名無しさん** · 2021/04/24(土) 13:26:44.28

C言語を捨てろと言ってるんだろ
他の言語に移ったところで文字コードから逃れることはできないがな

**デフォルトの名無しさん** · 2021/04/24(土) 15:17:08.03

>>905
アプリケーションの話

**デフォルトの名無しさん** · 2021/04/24(土) 15:48:16.06

>>907
他の言語はWindowsのUnicodeにちゃんと対応してる

**デフォルトの名無しさん** · 2021/04/24(土) 15:57:56.64

>>893
C++はヤバすぎる
utf-8用の1B型を最近標準化したけど、まともに実装されてないし設計もユルユル
WGの中の人がサードのライブラリ引いてね発言するくらいヤバい

**デフォルトの名無しさん** · 2021/04/24(土) 16:15:59.56

結局の所Unicode対応ができてないのはC/C++の言語自体と
無能なC/C++プログラマが根本的な原因なんだよな

無能なくせにクソ言語を使うなと

**デフォルトの名無しさん** · 2021/04/24(土) 17:52:30.16

OSなどの実行環境まで含めて全部をセルフ記述できる言語だけがC言語をけなして良い。
C言語の代わりになる高級アセンブラとか存在しないのが実情。

**デフォルトの名無しさん** · 2021/04/24(土) 19:43:48.66

Windowsを全部セフル記述できる人だけが、Windowsをけなしていい

**デフォルトの名無しさん** · 2021/04/24(土) 19:44:10.19

訂正

Windowsを全部セルフ記述できる人だけが、Windowsをけなしていい

**デフォルトの名無しさん** · 2021/04/25(日) 01:01:32.24

>>912
C言語（とその派生）が無くなると世の中のほぼ全ての言語が一緒に死ぬからなあ。
ハンドアセンブルのマシン語は残るとして他に生き残りそうなやつって何があるだろうか？
汎用機のCOBOLとかなら大丈夫か？
C言語で使えない文字コードとかあったらゴミだな。

**デフォルトの名無しさん** · 2021/04/25(日) 09:44:53.64

Lisp MachineではFortranもCもlispで書かれていたのじゃよ、もうlisp専用ハードが無いけど…
今のハードがほぼC用に設計されているというだけ
それでもソフト資産が莫大だからCエミュレータは不滅だろうが

**デフォルトの名無しさん** · 2021/04/25(日) 12:49:28.15

lispマシンは滅びたのじゃよ。
javaマシンは産まれもしなかった。
別に今のCPUがCに合わせて設計されてるわけではない。
Cのオプティマイザーが頑張って今のCPUにあわせてるだけ。
lisp で lisp コンパイラと CPU オプティマイザ書けば理論的には同じことができるはずだけど誰もしようとしないだけ。
これ以上はスレチだな。

**デフォルトの名無しさん** · 2021/04/25(日) 13:07:14.30

lispマシンのタグ付き思想はBOMに近いから関係ない事もないと思う
違うのは自動でオブジェクト=型+ワードから値だけ取り出す機構が(普及して)無いところだな

動的言語がこのまま持て囃され続ければ、ハードウェアGCの可能なlispマシン風ハードが出るかもしれん、何十年後になるか知らんが

**デフォルトの名無しさん** · 2021/04/25(日) 13:18:17.37

アドレス付け単位としてのバイトが8bitでは効率良く型(あるいはエンコ)情報付けるのは厳しいな
文字単位で付けると少なくとも16bitになってしまう
やっぱり36bit時代の話だね

**デフォルトの名無しさん** · 2021/04/25(日) 13:47:52.95

Jazelle...

**デフォルトの名無しさん** · 2021/04/26(月) 14:21:24.82

lispすげーの人は夢を語りすぎ
鏡観ろ

**デフォルトの名無しさん** · 2021/04/29(木) 14:26:38.37

やっぱりヤンキーはASCIIのことしか考えてないのか

Copying non-ASCII characters from Windows to WSLg broken
https://github.com/microsoft/wslg/issues/20

**デフォルトの名無しさん** · 2021/04/29(木) 22:05:53.91

WSLgはまだプレビュー版やろ

**デフォルトの名無しさん** · 2021/04/30(金) 19:55:54.85

ヨーロッパの人もびっくりといったところでしょうか

**デフォルトの名無しさん** · 2021/05/10(月) 21:21:31.93

CP932やUTF-8で保存されたテキストファイルをバイナリエディタで見る時、
0x0Dと0x0Aは常にCR・LFに対応するという理解であっていますか

例えば"東"は以下のように保存されますが、0x0Dや0x0Aが含まれる字が存在しない事を確かめたいです。
UTF-8: e6 9d b1
CP932: 93 8c

尚、ファイルは破損しておらず、デコードできない文字は含まれていません

**デフォルトの名無しさん** · 2021/05/10(月) 21:32:43.96

>>925
WikipediaのCP932とUTF-8の記事見てみ

**デフォルトの名無しさん** · 2021/05/10(月) 21:51:44.48

>>926
ありがとうございます
難しくてわかりませんでした

**デフォルトの名無しさん** · 2021/05/10(月) 22:22:18.55

プログラミングのお題スレ Part18
https://mevius.5ch.net/test/read.cgi/tech/1594702426/453

UTF-8 では、先頭ニブル(4ビット)が0なのは、1バイト文字だけだから、
0x0D・0x0A は、1バイト文字だけしかない

**デフォルトの名無しさん** · 2021/05/10(月) 22:33:39.19

MSのCP932や、UTF8はASCIIの上位互換。
つまり 0x0A とかは同じ解釈でいける。
UTF16とかUTF32とかは上位互換じゃないので駄目。

**デフォルトの名無しさん** · 2021/05/10(月) 23:26:10.90

>>927
どのあたりが難しかった？煽りじゃなくて

**デフォルトの名無しさん** · 2021/05/11(火) 00:05:10.05

ありがとうございます

>>928
UTF-8では、0x0Dと0x0Aは常にCR・LFと対応するのですね、助かりました
CP932も同様でしょうか

>>929
アスキー文字(0x00-0x7F)のみが書かれる時、CP932もUTF-8も同じバイト列であることは知っていましたが
0x0Dや0x0Aを含む文字が存在しない事を知らなかったので質問しました
例えば「帰」はCP932だと8b 41で、0x41が含まれていますが「A」を表してはいないわけで
同様の例が0x0D 0x0Aに当てはまるのか知りたかったのです

**デフォルトの名無しさん** · 2021/05/11(火) 00:06:36.86

長すぎたので分割しました

>>930
うわ、どっちも文字がいっぱい……

UTF-8のページ
「エンコード体系」の表が関係しそうだなあ、でもよくわからんなあ。何故2進で書いたし……
今
あ、16進表記の列もあったのか。どれどれ…、あ、0x80以上なのか。じゃあ0D 0Aを含む文字はないんだなあ

CP932のページ
「構造」の表が関係しそうだなあ、でもこれはutf-8のサブセットのことを言っているのかな、それは知っているけどなあ
うーん、でも他に関連しそうな記載は見つけられないなあ
今
あ、CP932って必ず2バイトに収まるのか？そしたら第2バイトの0x00-0x3Fが未使用だから、0x0Dと0x0Aは常にCR・LFと対応すると言って良さそうだなあ

**デフォルトの名無しさん** · 2021/05/11(火) 01:30:17.15

CP932に依存するコードを車輪の再発明するのはやめたほうがいい
UTF16を介して処理するのが堅実だよ

**デフォルトの名無しさん** · 2021/05/11(火) 02:38:12.81

CP932だと絵文字が入ったファイル名とか扱えないからね
WindowsがUnicodeなんだからそれに従ったほうが良い

**デフォルトの名無しさん** · 2021/05/11(火) 06:46:10.57

>>932
わかりませんでしたって書いてたけどだいたい読めてるじゃん
「自信ないけどこう読み解きました」
「それでおｋ」
で済む(・∀・)

**デフォルトの名無しさん** · 2021/05/11(火) 09:39:59.91

>>933
今更UTF16はないよ。中途半端なゴミ。
UTF32にするべき。じゃなければUTF8で処理する方かまし。

**デフォルトの名無しさん** · 2021/05/11(火) 09:55:14.95

>>936
プログラミングやったことない人は回答しなくていいから

**デフォルトの名無しさん** · 2021/05/11(火) 10:46:32.40

>>925
読み込むとき CR を無視して LF だけ読んだとき CRLF が来たものとして処理
書き込むとき CR を無視して LF だけ書き込む
これで大抵の場合うまくいく

**デフォルトの名無しさん** · 2021/05/11(火) 10:47:04.26

>>925
ああすまんω
バイナリの話か
忘れてくれωω

**デフォルトの名無しさん** · 2021/05/11(火) 15:53:24.06

>>937
技術的な反論ができないので、プログラムしたことがないとうレッテルを貼ってごまかそうとする。
醜いな。

**デフォルトの名無しさん** · 2021/05/11(火) 15:59:10.29

なんでUTF-8で全世界統一しないんですか？
2000年問題みたいにやっちゃやーいいのに

**デフォルトの名無しさん** · 2021/05/11(火) 16:02:46.19

>>940
WindowsのCライブラリはUTF-32には対応してないんだよ

**デフォルトの名無しさん** · 2021/05/11(火) 17:51:32.38

2000年問題？

**デフォルトの名無しさん** · 2021/05/11(火) 18:03:59.53

>プログラムしたことがない

話や知識がかみあってない人は描いてる内容や雰囲気で判るけどな
プログラムしたことがあっても特定の分野に疎いとか
色々勘違いして覚えてるとか知識が偏ってるとかな

**デフォルトの名無しさん** · 2021/05/11(火) 18:12:43.26

ICUはUTF-16がメインだよ。ソースとか見たことないの？

**デフォルトの名無しさん** · 2021/05/11(火) 19:09:36.09

>>943
2000年問題の時は全世界で一斉に改修しただろ
文字コードも同様に全世界で一斉にUTF-8にすればいい
SJISとかEUCとか使ってソフトはDeprecatedに指定して
もう二年したら使えなくなるぞ、(#ﾟДﾟ) 凸ｺﾞﾙｧ!!、と伝えればすべての問題が解決

**デフォルトの名無しさん** · 2021/05/11(火) 19:17:31.49

おまえ明日から使用言語は英語な
明日まで翻訳終えられなかった日本語の文書は破棄するように

**デフォルトの名無しさん** · 2021/05/11(火) 19:31:09.73

>>947
OK, no problem.
However, you all have to speak in English, too.
Is that OK with you?

**デフォルトの名無しさん** · 2021/05/11(火) 19:51:27.17

じゃあ二年後の正月から日本全体で電気は50Hzな
例外は認めない

**デフォルトの名無しさん** · 2021/05/11(火) 20:07:39.07

>>947
OK, it doesn't matter to me.
I currently live on the 50Hz-side.

Seriously, what the fuck is the matter to change all charsets to UTF-8?
At least, we have to start writing all characters in UTF-8.
You guys are just procrastinating the problem to the later generation.

**デフォルトの名無しさん** · 2021/05/11(火) 20:37:23.10

哎呀～

**デフォルトの名無しさん** · 2021/05/11(火) 20:47:14.11

>>948
No.
I resolutely refuse to your suggestions.

◆QZaw55cn4c · 2021/05/11(火) 20:49:53.68

>>933
え？
UTF32 こそ正義なのではないですか？
UTF16 は、あくまでも特定用途のために UTF32 から変換して渋々使うものかと‥‥

◆QZaw55cn4c · 2021/05/11(火) 20:50:48.74

>>941
外に出す文字コードは UTF-8
内側では基本 UTF-32 を使うべきかと、私は考えています

◆QZaw55cn4c · 2021/05/11(火) 20:52:11.20

>>942
へんな言い方ですね
「Windows の C ライブラリ」ではなくて、Windows のシステムコール＝win32api というべきなのでは？

そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ

◆QZaw55cn4c · 2021/05/11(火) 20:55:50.64

>>945
UTF-16 は Windows 等の特定用途なのでは？
むしろ正義は UTF-32 にあるでしょう
Shift-JIS や EUC は時代遅れだ、という意見には同意せざるを得ないのですが、だからといって、UTF-16 を提案するというのは、かえって悪手というか、頭が変なんじゃないかと私は考えます

そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ
そんなんじゃ駄目だ

◆QZaw55cn4c · 2021/05/11(火) 21:02:01.91

>>949
50Hz は当時のドイツの会社「アルゲマイネ・エレクトリツィテート・ゲゼルシャフト」社から、
60Hz は当時の米国の会社「ゼネラル・エレクトリック」社から来ています

もし英語を第一言語に主張するのならば、50Hz ではなくて 60Hz が本流でしょう‥‥
実際、今で合衆国・カナダ・メキシコは 60Hz の国ですし

**デフォルトの名無しさん** · 2021/05/11(火) 21:41:17.35

>>952
No, no, no, no, ... YOU suggested first.

**デフォルトの名無しさん** · 2021/05/11(火) 21:58:18.19

>>954
いいですよ、UTF-32は一度も使ったことないですけど、
全世界で文字コードが統一されるなら協力しますよ。

自分はマなんですけど（って、ここにいる全員そうか）、
毎回文字コードの問題が浮上するたびに統一しろよと思ってきました。
UTF-8が出た時は「これでやっと統一される！」と思ってたら、ちっとも変わってない。
どこの馬鹿が舵切ってないんですか？
こんなもん、トップダウンでやらんと意味が無い。

蛇足だが、50Hz/60Hzも本気で統一すればいい。
地デジでアナログテレビを駆逐したんだからやれないことはない。
車の左側/右側通行も世界共通で左側通行にすべき。

**デフォルトの名無しさん** · 2021/05/11(火) 22:01:33.58

Ubuntu は、UTF-32 だけど、英語圏では後半の2バイトが無駄。
メモリ使用量が、UTF-16 の2倍

だからWindows などの昔のOS は、UTF-16・サロゲートペアを使っている

◆QZaw55cn4c · 2021/05/11(火) 22:28:23.04

>>959
＞50Hz/60Hzも本気で統一すればいい。

無理です……
変電・配電設備はどれも 50Hz/60Hz それぞれに専用で、もう一方の周波数には対応できません
仮に 60 Hz をやめて 50Hz に統一するとすると、西日本の電気設備は全部更新しないといけません、部品が全然足りなくて、多分西日本は3年くらい停電、電気なしの生活になりますね……

◆QZaw55cn4c · 2021/05/11(火) 22:29:39.96

>>960
いまどき 32GiB RAM が常識な世の中で、後半の 2 バイトが無駄とかみみちいですね、そんなんじゃ駄目だ……

**デフォルトの名無しさん** · 2021/05/11(火) 22:35:13.63

じゃあ明日から「円」は廃止「ドル」しか使えない
「メートル」は廃止してインチ、フィート、ヤード、マイルで
「摂氏」は廃止して華氏
「リットル」は廃止してガロン
これでアメリカと互換だぞ
便利だろ?

◆QZaw55cn4c · 2021/05/11(火) 22:37:00.60

>>963
国民皆保険すらない後進国にあわせるのですか？

**デフォルトの名無しさん** · 2021/05/12(水) 00:04:08.19

>>962
組込み用途では相変わらず厳しい制限があるだろ

**デフォルトの名無しさん** · 2021/05/12(水) 00:56:08.99

>>959
何をいってんの？　Unicodeの目的は「これからは」単一の文字コードで
世界中の文字を表現すること
過去の資産を無くすためじゃない

それからUTF-8はな、せっかくUTF-16に統一しようとしていたのに
Unicode団体でな無い所が新たに追加した文字コードだぞ

UTF-8がでたときは「また文字コード増やしたのかよ」って思うはずなんだが

**デフォルトの名無しさん** · 2021/05/12(水) 01:47:55.23

あーもー！結局次が決まらんならS-JIS使い続けようぜ！

**デフォルトの名無しさん** · 2021/05/12(水) 02:24:31.19

>>965
組み込み用途では制限が厳しいのでUTF16を使いますｗｗｗ
お前、組み込みでどれだけ文字処理してんの？
いや、UTF8やUTF32じゃ駄目でUTF16じゃんないと制限に引っかる最近の実例があったの？
あったら具体例教えてほしい。

**デフォルトの名無しさん** · 2021/05/12(水) 02:26:01.47

Cコンパイラがwchar_t型をUTF16とするかUTF32とするか次第じゃね

**デフォルトの名無しさん** · 2021/05/12(水) 02:35:18.26

>>966
だってUTF16がインターネットでの使用をまともに考慮して無かったので仕方ない。
unicode以前からインターネットは既に存在していて基本ASCIIベースだったので、それの上位互換がnetで普及するのは当然の流れ。
文字数が16ビットじゃ足りないことと、インターネットの普及を予測できなかったUnicodeコンソーシアムの不見識がUTF16の原因。

**デフォルトの名無しさん** · 2021/05/12(水) 02:49:55.29

UTF8を使うにしても、SJIS -> UTF16 or UTF32 -> UTF8 と変換するからやってることは同じなんだよ

**デフォルトの名無しさん** · 2021/05/12(水) 03:26:27.16

>>970
なんで文字コードがインターネットの使用を考慮しないといけないかもわからないし
インターネットでUTF-16が使えるのに、考慮してないというする理由もわからない
もしかしてネットサーフィン（笑）をインターネットという爺かお前

**デフォルトの名無しさん** · 2021/05/12(水) 03:27:38.25

ASCIIは7ビットなんだからUTF-8だって非対応なんだがｗ

**デフォルトの名無しさん** · 2021/05/12(水) 09:38:08.51

>>959
言いたいことは判るが
君の発言はアーカイブとか文書の問題とすりかわってないか？

βのテープなんてまだあちこちにごろごろしてるだろ？
MO/MDなんかもまだあるだろ？
そのうちHDDもなくなってSSDばかりになるだろうがHDDはなくならないだろ？
新しいものはそっちで作っても古い方は面倒だから移動なんてしないだろ？

**デフォルトの名無しさん** · 2021/05/12(水) 11:26:29.20

馬鹿メリカ式だと今日がこんなのになってしまう
5.12.2021
こんなの混ぜたら5月12日なのか12月5日なのか判別できずに混乱が生じる
混乱の対象となるのは各月12日までで月≠日のパターン(12*12-12=132通り)
年のうち36%もの日で混乱が生じている
馬鹿メリカ式さえ排除すれば大体うまくいくのだ

**デフォルトの名無しさん** · 2021/05/12(水) 11:31:17.70

>>973
プロトコルを拡張する時に上位互換の拡張が求められる、っていう常識すら知らないの？
まともに規格作ったり、実装したことないのかな。
一度動きだしたものは変更コストができるだけ小さい拡張が普及するんだよ。

◆QZaw55cn4c · 2021/05/12(水) 20:16:47.61

>>966
＞せっかくUTF-16に統一しようとしていたのに

後世の模範となる康熙字典ですら 4万7035 字が収録されているというのに、UTF-16 の 6万5536 文字のキャパシティの面では圧倒的に足りないのでは？
世の中に存在する文字、かつて存在した古代文字を全部残らず収録する、という姿勢にしては、UTF-16 は「しょぼい」としかいいようのないキャパですね…

CJK 漢字統合なんて、東洋人からみればひたすら「醜い」の一言
「UTF-16 に統一」という基本設計、あるいは基本思想の時点で既に「根本的に間違っている」と私は結論づけます

そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…
そんなんじゃ駄目だ…

◆QZaw55cn4c · 2021/05/12(水) 20:17:23.50

>>969
wchar_t は死産でしょう‥‥

◆QZaw55cn4c · 2021/05/12(水) 20:18:07.73

>>975
×馬鹿メリカ式
◎ダメリカ

**デフォルトの名無しさん** · 2021/05/12(水) 20:22:17.19

UTF-16 の最大文字数は 6万5536を遥かに超えるんだが
基礎知識がないやつとは、話にならんかな

**デフォルトの名無しさん** · 2021/05/12(水) 20:39:17.81

昔に 65536 で十分ってアホなこと言い出したやつがいたのが、今の UTF-16 っていうヘンテコ文字コードができた原因だろ。
結果は、ごらんの有様。

**デフォルトの名無しさん** · 2021/05/12(水) 20:41:59.59

UTF-8ができたのはUTF-16の後な
最初はUTF-32と同じ文字数を表現できるようにしたが
最終的にUTF-16と同じ文字数に変更した
UTF-8とUTF-16が扱える文字数は同じ

**デフォルトの名無しさん** · 2021/05/12(水) 21:12:17.60

えっなにこの流れ
UTF16で扱える文字数とUTF32で扱える文字数が違うとか言い張ってる人がいるように見えるんだけど
そんなことがあるの？？

**デフォルトの名無しさん** · 2021/05/12(水) 21:17:37.12

https://ja.wikipedia.org/wiki/CJK%E7%B5%B1%E5%90%88%E6%BC%A2%E5%AD%97

1984年、ISOの文字コード規格委員会 (ISO/TC 97 - SC2) は文字セットの切り替えを行わずに世界中の文字を単一の文字集合として扱える
文字コード規格 (ISO 10646) を作成することを決定し、専門のワークグループ (WG2) を設置した。
当初、この文字コード規格は16ビットを想定し、その中に日本や中国など各国の漢字コード表をそのまま入れることを想定していた。
しかし中国はこの方式では自国で現在策定中の漢字コードが全て入らなくなるとしてこの方針に反対し、
1989年、各国の漢字コードを統合した漢字集合HCCのアイデアを提案した。

1990年、完成したISO 10646の初版ドラフト (DIS 10646) では、漢字コードは32ビットで表現され、各国の漢字コードはそのまま入れることになった。
しかし中国は漢字を各国でばらばらに符号化するのではなく、あくまで統一して扱うことを求めてこのドラフトには当初から反対しており、
今後の漢字コードの方針を決めるため、ワークグループはCJK-JRGと呼ばれるグループを別途設置し、そこで引き続き検討することにした。

**デフォルトの名無しさん** · 2021/05/12(水) 21:37:03.94

ごめん誰か馬鹿な俺のために
(1) UTF16で表現できるがUTF32で表現できない文字
(2) UTF32で表現できるがUTF16で表現できない文字
を具体的に例示してもらえないだろうか

サロゲートペアなんてもう20年以上前には登場してたよね？
最大65536文字とか言ってる人は頭が平成１桁時代のまま取り残されてるの？

それとも、IVSや絵文字が絡むとUTF32で表現できない文字が出てきたりするんだっけ・・・？（こっちは自分が不勉強ゆえ自信なし）

**デフォルトの名無しさん** · 2021/05/12(水) 22:41:39.87

>>961
変電・配電設備だって永遠に運転できる訳じゃない。
老朽化したら修理や建て直しぐらいするから、そのタイミングで変えていけ。
一斉にやるんじゃなくて、局所的に分けて10年～15年ぐらいかけてやればいい。
その間は隣の市から電気もらうのもOK。

>>963
「円」じゃなくて基準を「金」に戻すかな。
単位に関しては世界標準無視かよ？

>>966
正直、UTF-8でもUTF-16でもUTF-32でもまったく新しい文字コードでもいいよ、統一できるなら。
何ちんたらちんたらやってんだよ？

>>967
よし、今すぐ回線切ってﾀﾋね

**デフォルトの名無しさん** · 2021/05/12(水) 22:42:55.43

>>974
βだろうがMO/MDだろうが、必要となったときに変換すりゃいいだけだろ。
少なくともその「必要となったとき」に吸い上げて変換した上で別の媒体に保存すればいい。
新しい文書は当然古い文字コードでは一切書かせてはいけない。
SJISなんぞ使った日にゃ秘密警察が見つけ出して206個ある骨をすべて砕く刑に処す。

>>975
その指摘は正しい。
ただ、一番正しい日付の表示法はヨーロッパ式で、
次に正しいのはお前が指摘しているアメリカ式で、一番馬鹿なのが日本式。

>>982
正確に数字で話せ。
で、真面目な話になるが、その中で最長の文字数を扱える文字コードはどれだ？
その最長の文字数でこの世のありとあらゆる文字は表現できるのか？
また、その最長の文字数を扱える文字コードだとデータ処理は遅くなってしまうのか？

**デフォルトの名無しさん** · 2021/05/12(水) 23:15:30.39

ISO8601よりヨーロッパ式を推すとはたまげたなあ

**デフォルトの名無しさん** · 2021/05/12(水) 23:28:53.01

場末の掲示板の場末の板でイキってるんだから可愛いよね

**デフォルトの名無しさん** · 2021/05/12(水) 23:30:48.38

>>982
>UTF-8ができたのはUTF-16の後
それ何のジョーク？
UTF−16(サロゲートペア)方式が公開されたのは UTF−8 方式の4年後なんだが。

**デフォルトの名無しさん** · 2021/05/13(木) 00:55:59.37

>>978
C++のcwcharヘッダーからもわかるとおり、wchar_tは規格の一部

**デフォルトの名無しさん** · 2021/05/13(木) 05:07:38.90

>>990
https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

> Looking around at some UTF-8 background, I see the same incorrect
> story being repeated over and over. The incorrect version is:
> 1. IBM designed UTF-8.
> 2. Plan 9 implemented it.
> That's not true. UTF-8 was designed, in front of my eyes, on a
> placemat in a New Jersey diner one night in September or so 1992.
>
> What happened was this. We had used the original UTF from ISO 10646
> to make Plan 9 support 16-bit characters, but we hated it.

要約 16bitのUTFを使っていたが嫌いだったからUTF-8を作った

**デフォルトの名無しさん** · 2021/05/13(木) 09:13:48.13

で、どこに 16bit の "UTF" って書いてあるの？
勝手に UTF を補完すんな。その頃は UTF-16 はまだ存在してない。

**デフォルトの名無しさん** · 2021/05/13(木) 11:09:24.10

>>988
ああ、ISO8601よりもヨーロッパ式の方が断然いい
なんだ、その理由も分からないのか？

**デフォルトの名無しさん** · 2021/05/13(木) 11:13:36.80

>>989
場末の掲示板の場末の板で呟いているお前の方がよっぽど可愛いわ
せめて俺に直接レスしたらどうだ、この臆病者がｗ

**デフォルトの名無しさん** · 2021/05/13(木) 13:46:00.24

成立順
UCS-2(かつてのUnicode)→UCS-4→UTF-8→UTF-16→UTF-32
ってことかな？訂正よろ

**デフォルトの名無しさん** · 2021/05/13(木) 13:51:48.50

>>980
そのせいで shift_jis と同じ失敗を繰り返した訳だ

**デフォルトの名無しさん** · 2021/05/13(木) 14:28:18.42

>>997
同じ失敗って何？
shift-jisみたいに2文字目の判定に時間がかかったり読み違えたりする可能性はないと思うけど