文字コード総合スレ 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/14(水) 15:40:00.22

win10
コマンドプロンプトで
chcp 65001
でも
>>810
は化けたわ

**デフォルトの名無しさん** · 2021/04/14(水) 19:39:34.04

>>810
Windows 10 のIEで表示できた
色はつかんかったけど
もちろんEdgeなら色付きで表示できた

**デフォルトの名無しさん** · 2021/04/14(水) 19:47:01.17

>>811
フォントの問題だからね
echo その文字 > test.txt とかやってファイルに書き出したら
cmd /UのUnicodeモードでUTF-16LEで問題なく保存されたよ
もちろんcmd /Aだとchcp 65001でUTF-8にしたら保存される。

**デフォルトの名無しさん** · 2021/04/14(水) 19:49:01.33

× フォントの問題だからね
○ 表示周りの問題だからね

データ自体は問題なく扱えるといいたかった

**デフォルトの名無しさん** · 2021/04/17(土) 14:25:57.05

Clarify guidance for use of a BOM as a UTF-8 encoding signature
https://www.unicode.org/L2/L2021/21038-bom-guidance.pdf

・Do not use U+FEFF as a ZWNBSP character; use U+2060 WORD JOINER instead.
・Include a BOM if one is known to be required by a targeted protocol.
・Otherwise, include a BOM when authoring a UTF-8 text file that contains non-ASCII characters,
　is not targeting a specific protocol, and may be opened by applications that will not assume UTF-8 by default
　(this is useful on systems like Microsoft Windows where some applications assume text files to be encoded with the Active Code Page).
・Otherwise, do not include a BOM.

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

>>813
/u スイッチで出力されるUTF-16LEはBOMなしなんだな
開けないエディタもあった

**デフォルトの名無しさん** · 2021/04/17(土) 16:07:47.50

>>815
要約：明示的に必要とされる場合以外は UTF-8 に BOM 入れるな。

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

そうでない場合は、非ASCII文字を含み、特定のプロトコルを対象としておらず、デフォルトでUTF-8を想定していない
アプリケーションで開かれる可能性のあるUTF-8テキストファイルを作成するときに、BOMを含めるようにしてください
（これは、Microsoft Windowsのように、一部のアプリケーションがテキストファイルをActive Code Pageでエンコード
することを想定している場合に有効です）。

**デフォルトの名無しさん** · 2021/04/17(土) 19:34:14.90

>>816
BOMがなにか知っていれば、そんな感想はでてこないはずなんだがな

BOMっていうのは文字コードが「不明なモノ」を認識するためのものだよ
最初から「UTF-16である」と決まってるなら当然BOMはない

出力はUTF-16と決まってるのだから当然BOMは不要
それを文字コードが決まってないファイルに
出力したお前がつけるべきもの

ファイル形式によってはUTF-16と決まってる場合もあるだから
勝手につけるようなことはしない

◆QZaw55cn4c · 2021/04/17(土) 19:54:12.40

>>819
というか、UTF-16 における BOM って Byte Order Mark という本来の意味の方が大きいと思いますが
もっとも私はアプリ内では全部例外なく UTF-32, win32api に渡すときは UTF-16 に変換, コンテンツの外部表現は UTF-8 にしていますけれども

**デフォルトの名無しさん** · 2021/04/17(土) 19:56:30.03

だから？

◆QZaw55cn4c · 2021/04/17(土) 20:33:08.95

>>821
BOMっていうのは文字コードが「不明なモノ」を認識するためのもの、というよりは、エンディアンを知らせるためのものでは？BOM の意義はそちらの方が優勢では？

**デフォルトの名無しさん** · 2021/04/17(土) 22:23:07.48

規格では
UTF-16LE はBOM付けない
UTF-16BE はBOM付けない
UTF-16 はBOM必要
これらは別物なので混同するのは良くない。

**デフォルトの名無しさん** · 2021/04/17(土) 22:25:44.67

>>819
事実を明示しただけなのに、何ドヤってんだよ

**デフォルトの名無しさん** · 2021/04/17(土) 22:30:24.80

819はUTF-16にBOMが必要という常識すら知らない素人。

**デフォルトの名無しさん** · 2021/04/17(土) 22:57:11.23

UTF-16にBOMが必要なら、なぜついてないのか説明してくれ

**デフォルトの名無しさん** · 2021/04/17(土) 23:00:00.38

>>823
規格書ぐらい読みましょう
https://www.unicode.org/versions/Unicode12.0.0/UnicodeStandard-12.0.pdf

The UTF-16 encoding scheme may or may not begin with a BOM. However,
when there is no BOM, and in the absence of a higher-level protocol, the byte
order of the UTF-16 encoding scheme is big-endian

UTF-16 のエンコーディング方式は、 BOM で始まることも、そうでないこともあります。
しかし、BOM がない場合、また、上位プロトコルがない場合、
UTF-16 符号化方式のバイト順序はビッグエンディアンです。

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

ちょくちょく >>823 みたいな読解力ない人が沸くよね
なんでだろ

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

要するに「UTF-16」のパターンは5種類あるってことだね
UTF-16BE 00 4D
UTF-16LE 4D 00
UTF-16 BOM(BigEndian)　FE FF 00 4D
UTF-16 BOM(LittleEndian) FF FE 4D 00
UTF-16 BOMなし(=BigEndian) 00 4D

**デフォルトの名無しさん** · 2021/04/18(日) 07:59:39.77

ビッグエンディアンとリトルエンディアンの2つだけだよ
あとはBOMがあるかどうかだけ

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

base64エンコーディングを加えればバリエーションはさらに増えるよ
よかったね

**デフォルトの名無しさん** · 2021/04/18(日) 08:12:27.46

玉子とかお新香つけたらバリエーションさらに増える

**デフォルトの名無しさん** · 2021/04/18(日) 16:24:37.92

>>829
五番目と最初は全く同じバイト構成になるので4種類が正解。
BOMなしの UTF-16 は実質 UTF-16BE の別名に過ぎない。

**デフォルトの名無しさん** · 2021/04/18(日) 16:31:23.17

BOMはパターンじゃなくて追加のシグネチャだよ
もしこれがHTMLだとしてUTF-8というメタタグがない場合
それはUTF-8とは別のパターンになるかと言ったらそうはならない

パターンとしては同じUTF-8であり
シグネチャがあるかどうかの違いでしかない

**デフォルトの名無しさん** · 2021/04/18(日) 19:12:05.70

BOMでこうまで話が続くのな

**デフォルトの名無しさん** · 2021/04/18(日) 19:24:29.98

なつかしのfree論争みたいだな

**デフォルトの名無しさん** · 2021/04/18(日) 21:03:03.56

Malloc and Free
https://groups.google.com/g/fj.comp.lang.c/c/G4HRnHTdImg

**デフォルトの名無しさん** · 2021/04/18(日) 22:24:15.55

>>837
うわなつかしい、俺のアドレスもあったw

**デフォルトの名無しさん** · 2021/04/18(日) 22:45:16.09

議論の理由も似てるかも
free()が必要かどうかは環境による。基本は必要最低限で使え。
BOMが必要かどうかは環境による。基本は必要最低限で使え。
というのが正しい答えだが、特定の環境のみ前提に主張するやつや、
念のためにいれておこうと考える不届き者のせいで話が混乱する。

**デフォルトの名無しさん** · 2021/04/19(月) 00:36:54.81

ぜんぜん違うな。BOMはUnicodeの仕様

**デフォルトの名無しさん** · 2021/04/19(月) 00:38:28.03

>>837
俺はこれ知らんかったけど、太田・久野・河野…とそうそうたるメンバーですなあ懐かしい

**デフォルトの名無しさん** · 2021/04/19(月) 00:41:47.58

昔はみんなバカだった

◆QZaw55cn4c · 2021/04/19(月) 00:43:04.40

>>839
それに「そもそも BOM という名前が」云々の原理主義者もお忘れなく、あー私のことか‥‥

**デフォルトの名無しさん** · 2021/04/19(月) 01:58:51.92

つまりBOMの話題はプログラマ界隈にとって爆弾のようなものだ、とこういうことか

**デフォルトの名無しさん** · 2021/04/19(月) 03:49:32.03

>>844
ミニマム・シンプルというのがプログラムの基本というのが理解できないやつがいる。
「不必要なものは入れるな」というのは最低限の知識.

**デフォルトの名無しさん** · 2021/04/19(月) 05:11:58.25

パーセントエンコーディングした文字列を正確にURL引数に渡すには
文字エンコーディングをサーバーに教えるためのパラメーターが別途必要になる。
だが、しかしサーバー側アプリにはBOMの情報をまるっと捨て去って平然と不具合を起こす権利がある。
文字エンコーディングをサーバーに教えるためのパラメーターと同じ役割を果たすのがBOM。
テキストエディタやコンパイラやブラウザはBOMをガン無視する権利がある。

**デフォルトの名無しさん** · 2021/04/19(月) 09:26:00.95

すっげー、面白い解釈してるな。どの規格読んだの？
URI は全体で一つの文字列なので、BOM つけるのなら最初の https: とかの前につけないと意味ないんだが？
そんな規格違反の URI に対応する必要があるという主張? それとも文字列の途中に BOM を入れて解釈しろという主張？

**デフォルトの名無しさん** · 2021/04/19(月) 09:31:04.91

>>845
ギチギチしたら拡張性がなくなるだろ

**デフォルトの名無しさん** · 2021/04/19(月) 09:32:40.01

不要なもの入れるな＝16bitあれば十分＝破綻ｗ

**デフォルトの名無しさん** · 2021/04/19(月) 13:35:40.29

それは不要なもの入れる入れないではなくて、拡張性のある実装と拡張性の乏しい実装の違い。
unicode の文字の中には余計なものもあることは認めるが、それは関係ない。

**デフォルトの名無しさん** · 2021/04/19(月) 13:37:50.42

>>850
つまりUTF-32が正解ってことでしょ？

**デフォルトの名無しさん** · 2021/04/19(月) 15:24:44.16

その辺は既に結論が出てる。
UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。必要なら32bitまで拡張可能。外部コードに最適
UTF-32: 固定長。必要なら32bit分の文字まで拡張可能。内部コードに最適。
UTF-16: メリットがない。拡張性ない。オワコン。将来は特定のOSやプログラム言語やアプリで過去の遺物として残る

**デフォルトの名無しさん** · 2021/04/19(月) 16:02:17.06

UTF-32が固定長なのはすべての文字が32bit長に収まる時期限定の話でしかない
いずれUTF-64を固定長として定義してUTF-32を可変長にせざるを得ない
そしていつの日かUTF-64も可変長になる日が来る
以後ループ

**デフォルトの名無しさん** · 2021/04/19(月) 17:13:36.69

>>852
あのさ、UTF-32のBOMを無視するなよ

**デフォルトの名無しさん** · 2021/04/19(月) 17:22:51.43

> UTF-8: 可変長だが ASCII 互換。欧米の文章で長さが最短化。
って言ってるのに、これが
欧米ではない文章だとUTF-16に劣るという
意味になるってわかってないのかな？

**デフォルトの名無しさん** · 2021/04/19(月) 17:25:16.03

UTF-16だと2バイトですむのに、UTF-8だと3バイト必要だからな
データ量が33%増加する

**デフォルトの名無しさん** · 2021/04/19(月) 18:49:55.06

日本語の漢字かな中心の文章や、中国語の文章などでは UTF-16 の方が短かくなるけど
欧米のやつらは日本語での長さなんて気にもかけないので。もはや UTF-16 はオワコンで意見が固まってる。
欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。
日本のすみっこで、いくら叫んでも世界の流れは変えられないのだ。
少し腹立つけど仕方ない。

**デフォルトの名無しさん** · 2021/04/19(月) 20:32:37.17

WindowsやJavaの内部エンコードに使われている限り生き続けるだけだろ。日本がどうとか関係ない。

>欧米のやつらはラテン・アルファベットで効率が良いことと、自分たちが大量に持っている過去のASCIIの資産との互換が最優先。

そのマルチバイトエンコーディングからUTF-16に乗り換えたWindowsやJavaの中の人は欧米なんだが。
もしかしたらUTF-8を推したいのかもしれないけど論理が支離滅裂。

**デフォルトの名無しさん** · 2021/04/19(月) 21:18:27.77

U+xxxxxxxxで表現されるバイト列をRAWデータで扱うための概念としてUTF-16,UTF-32は必要とされ続ける

**デフォルトの名無しさん** · 2021/04/19(月) 21:27:04.16

合成文字があるのにいつまで固定長なんて幻想にしがみついてんだよ

**デフォルトの名無しさん** · 2021/04/20(火) 03:31:33.46

これからはUTF-16の時代だって思うやつがいるんなら英語の掲示板に行ってぜひ布教してくれ。
もう世の中の流れは変わってることがわかる。昔に戻せるならやってみてくれ。
無理だと思うが、個人的には嬉しいので。

**デフォルトの名無しさん** · 2021/04/20(火) 04:46:32.12

git diff コマンドがUTF-16テキストファイルをバイナリ扱いして困る

**デフォルトの名無しさん** · 2021/04/20(火) 08:00:32.57

これからはUTF-16の時代だなんて思う奴はまずいないだろうが、
これからもUTF-16の時代が続くと思う奴はいるだろう。

**デフォルトの名無しさん** · 2021/04/20(火) 10:21:46.36

欧米の奴らも絵文字は使いたがる、これはある意味いいことかも。

**デフォルトの名無しさん** · 2021/04/20(火) 10:27:53.52

>>861
これからもなにもずっと前からUnicodeの時代で
UTF-16もUTF-8もその表現の一つでしかないんだが
WindowsのAPIは柔軟だから両方に対応してるね

**デフォルトの名無しさん** · 2021/04/20(火) 21:54:20.56

U+xxxxxxxxで表現されるバイト列をRAWデータで扱うためとしても
UTF-16は桁が足りないんだからUTF-16を使っている箇所はUTF-32に移行すべき

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

ASCII文字も1文字=7bitを前提にした文字の並びになっているから
1文字=8bitを前提に文字の並びを変えて
ISO646による言語別の文字の変更（バックスラッシュが円マークになる）も
廃止すればシンプルになっていいね。
ISO8859でもASCII文字の部分は何も変えなかったのは
ASCIIとISO646が普及してしまって変えられなかったから？

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

文字コードとフォントは別のものだから…

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

過去のファイルは編集されずにずっと残るんだから古いファイルを
開くために仕様や規格を廃止することは不可能だよ
これからの話しか見えてないのは視野が狭すぎる

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

過去の文字コードってASCIIでしょ。だったらUTF-8でそのまま読めるじゃん。というのがアメリカンの発想。
ローカルなSJISなどというものは念頭にない。ASCIIに比べれば大した量ではないので変換でも何でもしろくらいに思ってる。
オープンソース系のアプリとか気の早いやつは、もうUTF-8以外のサポート切り捨てようとか本気で言い出してる。
まだ時期尚早と説得してるが、どうなることやら。

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

もうAltコード覚えてしまってるから勘弁して
まあ今もアプリ側でマップしてるだろうけど、文字セットの実装が失われると参照が難しくなり方言化が進む
なにより二重ループで一覧表生成出来なくなるだろうしやだー

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

コードポイント=エンコードにできるはずの128-255を捨てるutf-8一人勝ちは避けたい
欧州文字セットでも記号類とか重宝する
8-bitクリーンかを気にする機会減ってきたし、新規参入の機会では
ダイアクリティカルマークは別バイトにすれば記号いっぱい詰め込めるだろ

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

>>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの

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

>>870
あのさ頭が悪いって言われるでしょ
過去のファイルの対応を切り捨てるのは現実的じゃないか
仕様や規格からShiftJISが消えることはないという話をしてるの
誰もアプリが使う文字コードの話なんかしてないの

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

Windows用実行バイナリの場合、システムの文字コードに依存したC言語ライブラリを使ってコンパイルされた実行バイナリが大部分だから、移行は簡単じゃないよ。
新しいライブラリにリンクするよう作り直したバイナリを再配布する必要がある。動作検証がたいへん

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

>>875
例えばどんなのがありますか？

**デフォルトの名無しさん** · 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の中の人がサードのライブラリ引いてね発言するくらいヤバい