文字コード総合スレ 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/21(水) 22:29:47.38

お堅くwin32API叩いて書かれたバイナリの互換性は驚異的だよな
MSが気まぐれに出しては忘れるフレームワーク叩いてたら知らんが

バイナリ配布文化を育ててしまった原因でもあるが、ここまで大事にしてきたのにエンコード対応なんかで折れてもらっては残念
win10(64bit)でoffice97が元気に動くのは誇っていい

**デフォルトの名無しさん** · 2021/04/21(水) 23:04:31.38

>>876
ロケール指定する処理が省かれたC言語アプリ全般

**デフォルトの名無しさん** · 2021/04/21(水) 23:10:54.40

>>878
だからそれはどれかって聞いてる

**デフォルトの名無しさん** · 2021/04/21(水) 23:11:26.55

大部分と言う割に、事例を一個も思いつかないなら矛盾してる

**デフォルトの名無しさん** · 2021/04/21(水) 23:20:34.30

Cで書かれたレガシープログラムほぼ全部なので挙げるまでもないんだけど、有名どころだとPerlだね
システムコード以外の文字を含むファイル名をperlに引数で渡せない

**デフォルトの名無しさん** · 2021/04/21(水) 23:26:30.87

Cで書かれたmain()関数にはシステムコードページで引数が渡されるのだけど、その時点で文字化けしてるので復元不能。

**デフォルトの名無しさん** · 2021/04/22(木) 09:25:25.74

>>880
お前、もう少し黙っとけ。無知過ぎる。
アホを晒し続けてるの実は同一人物だろ。

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

このスレ読んでるとハゲそう

**デフォルトの名無しさん** · 2021/04/22(木) 11:48:03.64

>>867
勿論普及してたからはあるだろうけど、そもそも変えるとかまた作り直すとかいう発想が無かったんじゃないかな。

ASCII制定→ISO 646制定→各国で変えられるのは10文字とか足りる訳無いだろ！→
ASCIIを拡張して8ビットフルに使おう→ISO 8859制定

とかそんな流れでしょ、増やして積んでけばいいと。当時のことは資料でしか知らないけどたぶん。

**デフォルトの名無しさん** · 2021/04/22(木) 20:15:21.29

メールで添付ファイルを送ろうとしたらbase64でエンコードされたせいで容量オーバーした
ネットワークのトラフィックを減らすためにもメールでバイナリデータをエンコード無しで送れるのが標準化すればいいのに

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

いち早く国際化はずのjavaもシステムのコードページでしか引数を受け取れない制約がある

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

ほんまに？
Unicode対応していながら_wmain()とかGetCommandLineW()使ってないとは信じがたいが

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

googleで検索したら以下ページすぐ見つかったけど、探すことさえしないタイプの人？

https://blogs.osdn.jp/2020/05/20/java-unicode.html

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

Windows 専用ソフトでなくて、複数のOSに対応したソフトは当然そうなる。
特に Unix 系からの移植ならロケールをコードページに対応させるのは当たり前。
Windows独自の特殊APIで実装とか頭の悪いローカル変更は極力しない。

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

というか単にC言語がASCII互換の文字コードしか
対応できないんだよな
そこは言語側の問題だと思う

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

例えばJavaとかはUnicode前提で設計されてるから
当然Javaで作った複数のOS対応のソフトは
WindowsでもUnicodeが使える

これは殆どの言語に当てはまると思う
C#、JavaScript、Ruby、Python、などなど

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

そういやC言語はマルチバイト対応の機能は標準化されてないんだっけ？
流石にC++は標準化されてるよな？

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

<locale>ヘッダがマルチバイト対応を実現してくれる
問題は誰もlocaleの機能を使ってないことだ

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

おや？<locale>ヘッダとはなんのためにあるのでしょう？
使わなくても多言語対応できるのだったのでは？（苦笑）

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

CがASCII互換じゃないと駄目ってどこの異世界。そんなもんコンパイラの実装次第。
規格では他の文字コードも考慮されてる。
実際 EBCDIC ですら動くやつあるのに。

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

>>893
POSIX

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