文字コード総合スレ Part11

**デフォルトの名無しさん** · 2018/01/22(月) 22:58:23.45

プログラマーなら一度は煩わされたことのある文字コードについてのスレ。
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/

**デフォルトの名無しさん** · 2018/08/06(月) 11:54:02.02

win32->win64のタイミングで変えとけばよかったのに

**デフォルトの名無しさん** · 2018/08/06(月) 12:31:26.13

もう一生UTF-16なのかな(´；ω；｀)

**デフォルトの名無しさん** · 2018/08/06(月) 15:04:26.69

>>600
ほんそれ
ついでにシステムロケールもUTF8はよ

**デフォルトの名無しさん** · 2018/08/06(月) 19:56:04.82

必要な時にUTF32を使えればいいだけなのでそんなに深刻がらなくても大丈夫でしょ。

**デフォルトの名無しさん** · 2018/08/06(月) 20:28:33.56

基本は8で臨時は32で答えが出ているよなあ
日本独自のJIS関係とかもう要らないし

**デフォルトの名無しさん** · 2018/08/06(月) 21:09:19.10

そういえば新元号合字ってJIS X 0213とかCP932とかの系統にも入るのかな？
元号合字使ってるとこはUnicodeじゃない古いとこが多そうだからここに入れないと意味半減な気がするけど

**デフォルトの名無しさん** · 2018/08/06(月) 21:18:55.92

印刷に使うワープロソフトはすべてunicode対応しているから大丈夫。

**デフォルトの名無しさん** · 2018/08/07(火) 04:59:39.09

JIS改訂汁

**デフォルトの名無しさん** · 2018/08/07(火) 17:57:38.63

日本語とか東アジア言語はバイト数の面では
UTF8よりUTF16の方が有利になるのだが。

**デフォルトの名無しさん** · 2018/08/07(火) 18:02:30.52

そうでもない

**デフォルトの名無しさん** · 2018/08/07(火) 19:58:16.46

うむ
日本語などの2バイト圏でも8やで

**デフォルトの名無しさん** · 2018/08/07(火) 21:15:40.62

お経とかならそうかも
でも普通の日本語の文書はUTF-8で１バイトになる字がわりと使われてるよね
改行もバカにならない

**デフォルトの名無しさん** · 2018/08/07(火) 21:38:24.37

中国語ならUTF-16のほうが有利？

**デフォルトの名無しさん** · 2018/08/07(火) 23:58:44.52

エディタとかUTF-32に対応してないのが多いよな。
まあ、無駄が多いからな。最上位の1バイトは必ず0x00になるから。

**デフォルトの名無しさん** · 2018/08/08(水) 00:28:20.77

UTF-16は廃止してUTF-20を策定すべき

**デフォルトの名無しさん** · 2018/08/08(水) 00:34:22.04

UTF-24じゃないの

**デフォルトの名無しさん** · 2018/08/08(水) 01:56:39.24

ランダムアクセスが一番早い文字コードはどれよ

**デフォルトの名無しさん** · 2018/08/08(水) 02:09:19.94

余ってる場所を余計なことに使う奴が絶対出てきて、
それを根絶するのに凄い辛い思いをするからヤメレ。

**デフォルトの名無しさん** · 2018/08/08(水) 04:24:19.86

もうこれ人類的に根絶できないんだろうね
一生これなんだろうね

**デフォルトの名無しさん** · 2018/08/08(水) 04:37:42.38

>>615
utf8でいいよ

**デフォルトの名無しさん** · 2018/08/08(水) 08:35:31.20

そういえば、utf9というのもあったな。３６ビットコンピュータに最適だとか。

**デフォルトの名無しさん** · 2018/08/08(水) 14:09:08.17

UTF-7と言う変態も

**デフォルトの名無しさん** · 2018/08/08(水) 16:40:51.17

Base64

**デフォルトの名無しさん** · 2018/08/08(水) 18:02:57.82

UTF-24を策定するべきだな。
全ての文字を24ビット(3バイト)で表す。
UTF-32の0x00で固定な最上位バイトを省くというので。
BMP外の文字だらけの文章には有利になるだろう。

**デフォルトの名無しさん** · 2018/08/08(水) 22:53:07.77

>>623
だな、固定長はUTF-24、可変長はUTF-8でいいだろう

**デフォルトの名無しさん** · 2018/08/08(水) 23:15:02.85

UTF16はいらないとかUTF24がよいとか、変な書き込みする人、同一人物？
CPUのレジスタは32bitまたは64bitなので、1バイトをコピーするのも4バイトをコピーするのも時間コストは同じだよ。

**デフォルトの名無しさん** · 2018/08/08(水) 23:48:28.49

1バイトと4バイトとかミクロの性能比較なんか殆ど意味無い

**デフォルトの名無しさん** · 2018/08/08(水) 23:49:21.32

固定長だなんて幻想をまだ見てるの？

**デフォルトの名無しさん** · 2018/08/08(水) 23:50:49.11

固定長の方が高速で便利ですやん

**デフォルトの名無しさん** · 2018/08/08(水) 23:57:42.55

>>626
大ありですよ。

>>627
固定長の方が条件分岐が減るので処理速度が高く、プログラミングもしやすい。

**デフォルトの名無しさん** · 2018/08/09(木) 01:13:33.46

>>626
ファイルサイズがでかくなればそれだけ処理をする回数が増えるからダイレクトに効いてくる。

**デフォルトの名無しさん** · 2018/08/09(木) 01:20:56.02

CPUひとつあたりの処理速度は10年前とあまり変わってないけど、搭載できるメモリの量は劇的に増えた。
内部実装がUTF32になって文字列リソースが2～4倍になったとしても利用できるメモリはそれ以上に激増しているのでまったく問題なし。
むしろUTF16やUTF32のほうが頭打ちのCPUにも優しい、ということがわかるはず。

**デフォルトの名無しさん** · 2018/08/09(木) 09:34:00.04

16は全然優しくない
24もアライメントを考えると優しくない

**デフォルトの名無しさん** · 2018/08/09(木) 10:29:52.60

よし128だ。

**デフォルトの名無しさん** · 2018/08/09(木) 10:44:02.84

>>625
放っとけば居なくなるのに

**デフォルトの名無しさん** · 2018/08/09(木) 11:03:48.44

>>633
合成やセレクタを撤廃できるのなら128でいいよ

**デフォルトの名無しさん** · 2018/08/09(木) 11:05:58.21

UNCODEv6

**デフォルトの名無しさん** · 2018/08/10(金) 22:27:21.22

UTF24とかメモリアクセス効率悪すぎるだろ。アライン考えろ。
情報交換用文字コードはエンディアンに依存しないUTF8。
内部用の文字コードはアクセス効率が良いUTF32。
貧乏人専用のUTF16。
それぞれ存在理由があるんだよ。

**デフォルトの名無しさん** · 2018/08/10(金) 23:01:06.31

Windowsの場合、プログラムを何も改修することなくUTF16でサロゲートペアの絵文字を使えているでしょ。
もちろん、文字フォントを描画するAPI、つまりマイクロソフトの中の人が頑張っているからだが。

**デフォルトの名無しさん** · 2018/08/10(金) 23:24:23.95

まぁ、Windowsプログラムで、動的に絵文字の肌色・髪色・性別などを変えようと思ったら、
UTF16のサロゲート処理を自分で行う必要があるけどね。

**デフォルトの名無しさん** · 2018/08/11(土) 00:03:26.88

>>637
24が駄目なら8はもっと駄目なんでないの？

**デフォルトの名無しさん** · 2018/08/11(土) 10:22:26.41

だからUTF8は内部利用じゃなくて情報交換用なんだろ。

**デフォルトの名無しさん** · 2018/08/11(土) 10:45:32.80

SJISと取り決めてあるテキストデータにUTF8をぶっこんできた取引先があって
翌朝からの日本社会に大混乱を引き起こしかねない危機に晒された経験がある
UTF8滅ぶべしと俺は本気で思っている

**デフォルトの名無しさん** · 2018/08/11(土) 10:58:00.76

エンコーディングは関係ないだろ。
決めごとを守れないその取引先と異常データを突っ込まれただけで混乱しちゃうプログラムの問題。

**デフォルトの名無しさん** · 2018/08/11(土) 11:30:16.03

何年か前に、地域の緊急速報のテストメールか何かに
エンコーディングを混在させて文字化けを地域住民に送って混乱させたのあったな
メールテンプレートのエンコーディングと、流し込む本文で混在させちゃったみたいな

**デフォルトの名無しさん** · 2018/08/11(土) 11:51:55.94

ないしほてし活復を語本日く書に左らか右どけい良もでき書横

**デフォルトの名無しさん** · 2018/08/11(土) 13:16:33.61

>>644
去年だぞ

**デフォルトの名無しさん** · 2018/08/11(土) 15:11:54.76

546<<
ケォヴわいくにみ読

**デフォルトの名無しさん** · 2018/08/11(土) 15:47:35.74

中東の言語は確か右からだったよな
やろうと思えば簡単そう

**デフォルトの名無しさん** · 2018/08/11(土) 15:56:48.16

TeXって右から書くのにも対応してるっけ

**デフォルトの名無しさん** · 2018/08/11(土) 18:33:53.99

sjisの～とcp932の～の違いって何？
～を入力して検索すると、sjisのほうはヒットしないんよね

**デフォルトの名無しさん** · 2018/08/11(土) 19:10:44.45

>>650
「入力して検索する」
どうやって入力して何を検索するのか他人に分かるように書いたらどうか
入力側がUNICODEで変換不能とかじゃない

**デフォルトの名無しさん** · 2018/08/12(日) 00:02:17.72

＞649

ArabTeX　を使えば出来ます

**デフォルトの名無しさん** · 2018/08/12(日) 14:13:27.50

Draft Emoji Candidates
http://unicode.org/emoji/future/emoji-candidates.html

**デフォルトの名無しさん** · 2018/08/12(日) 14:20:12.48

絵文字がんがん増えてるけど、ぱっと見で見分けが付かない微妙なの多いよなぁ

**デフォルトの名無しさん** · 2018/08/12(日) 14:26:24.04

馬鹿は同じ過ちを繰り返す

**デフォルトの名無しさん** · 2018/08/12(日) 14:35:29.88

そのうち洗練されて象形文字になって、やがて漢字に…あれ?

**デフォルトの名無しさん** · 2018/08/13(月) 14:33:07.24

この際1byteを32bitか64bitにしたらどうよ
1byteが8bitになったのはアルファベットや数字が固定長で表せて
2^nbitで処理しやすかったからなんだろうけど
1byteが32bitか64bitになればエンディアンの問題もなくなって分かりやすくなる

**デフォルトの名無しさん** · 2018/08/13(月) 14:58:06.25

そうなんか？
16新数で2桁でちょうどいいからだと思ってた

**デフォルトの名無しさん** · 2018/08/13(月) 14:59:26.97

あと 8bit を 1byte というけど
4bit のことをなんていうの？

**デフォルトの名無しさん** · 2018/08/13(月) 15:02:02.90

>>657
8bitや16bitのCPUはどうすんの？

**デフォルトの名無しさん** · 2018/08/13(月) 15:15:08.87

>>657

32bitでも、64bitでも、好きな長さを「word」と呼べばいい。
これで、エンディアンの問題もなくなって分かりやすくなるんだよな。

**デフォルトの名無しさん** · 2018/08/13(月) 15:19:57.39

>>659
ニブル - Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%8B%E3%83%96%E3%83%AB

> ニブルは4ビットのことである。

**デフォルトの名無しさん** · 2018/08/13(月) 16:04:07.52

Thx!
DNCL

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

無理。各コンピュータ内部なら好きなビッド数にすれば良いけど、インターネットのほぼ全ての規格はオクテットが基準になってる。
インターネット全部作り直すくらいやらないと今更変更できない。

**デフォルトの名無しさん** · 2018/08/14(火) 09:43:35.42

byteとoctetを区別すればいいだろ

**デフォルトの名無しさん** · 2018/08/14(火) 12:58:54.95

>>584
昔の ISO/IEC 10646 がそんな感じじゃなかったっけ？
UCS-4 が Four-Octet Canonical Form (4オクテット正規形) と呼ばれてて
UTF-8 や UTF-16 はあくまで Transformation Format だと。

**デフォルトの名無しさん** · 2018/08/14(火) 13:43:48.36

UTF-32に統一できないなら、UTF-8を残そうがUTF-16を残そうが
どちらも大して変わんないんだよね。
UTF-8 も UTF-16 も既存OSの互換性を保つためにあるのだから

UTF-8はANSI互換性というメリットがあるというけれど
なんてことはない、Unix/Linuxの改修が大変だったから、
文字コードのエンコーディング方式自体を作ったってだけの話
互換性のために作ったものだよ

16bitにすべての文字を収めるのは不可能だが、仮に収まったとしたら
UTF-16はサロゲートペアなどなく1文字16bitというシンプルなものになっていた。

もし最初から32bit必要だと認識していれば、UTF-32という1文字32bitに
統一された素晴らしい文字コードになっていただろう
そしてWindowsはそれを標準文字コードとして採用しただろう。
（WindowsがUTF-16なのは、その頃はUnicode = UTF-16の前身のUCS-2 だったから）

結局固定長でないなら、どちらも面倒なことに大差ないし
互換性を保つために面倒な方式を残すのであれば、
それがUTF-8でもUTF-16でも同じこと

**デフォルトの名無しさん** · 2018/08/14(火) 14:30:35.75

UTF-8はエンディアンの問題が無いのが良い

**デフォルトの名無しさん** · 2018/08/14(火) 15:00:48.27

8も16も大して変わらないと言えばそうだけど、種類が少ないに越したことはないし
どっちかひとつ残すならやっぱり8なので、16には退場願いたいね

**デフォルトの名無しさん** · 2018/08/14(火) 15:32:16.19

>>669
Windowsという重要な役目があるので無理だってわかってるだろ？

**デフォルトの名無しさん** · 2018/08/14(火) 15:39:29.46

>>667
妄想は要らん
asciiとの互換性とosの改修は関係ない
16bitに収まったとしたらとか ifを言い出したらきりがない

**デフォルトの名無しさん** · 2018/08/14(火) 15:47:44.20

>>670
昔からMSは独自文字コードが大好きだからUNICODEからUTF-16が無くなっても問題ない

**デフォルトの名無しさん** · 2018/08/14(火) 16:47:25.95

>>671
> asciiとの互換性とosの改修は関係ない

大あり。C言語はASCII互換前提となっている。
具体的に言うと、文字列の終端文字が\0なので
UTF-16やUTF-32といった、1文字の中に\0が
含まれてる場合に対応できない

UTF-8でなければprintfなどの基本的でよく使われる関数
全てをUnicode対応に改修しなければならなかった。
もしくは捨て去さるかだ

**デフォルトの名無しさん** · 2018/08/14(火) 16:48:00.48

>>672
昔からUnicode対応なんですがーｗ

**デフォルトの名無しさん** · 2018/08/14(火) 16:54:07.60

UTF-16やUTF-32も1文字の中に\0が含まれているわけじゃないがな。

**デフォルトの名無しさん** · 2018/08/14(火) 17:16:53.37

含まれるやろ

**デフォルトの名無しさん** · 2018/08/14(火) 17:17:26.99

L'\0' は含まれないが '\0' は含まれる

**デフォルトの名無しさん** · 2018/08/14(火) 17:18:41.77

http://ash.jp/code/unitbl1.htm

41 41 41 41 0041 A
42 42 42 42 0042 B
43 43 43 43 0043 C
44 44 44 44 0044 D
45 45 45 45 0045 E

右から二番目がUTF16の文字コード
見ての通り基本のアルファベットの中に0x00が含まれてる

つまり ABCは、00 41 00 42 00 43 もしくは 41 00 42 00 43 00 という並びとなり
これをprintf等にわたすとASCII文字として1文字8bitと解釈し、
00を\0とみなすので途中で切れるか全く表示されなくなる

**デフォルトの名無しさん** · 2018/08/14(火) 17:21:01.63

説明足らずな>>675が揚げ足取りだと思われると可愛そうなので（笑）
補足してあげると、UTF-16やUTF-32の1文字はそれぞれ16bit or 32bit で
16bitで\0、32bitで\0 は含まれてないと言いたいのだ

だが今は、printfなど1文字8bitと解釈する関数の話をしているので
8bitずつ見ていくと文字の途中に\0が含まれるのだ

**デフォルトの名無しさん** · 2018/08/14(火) 17:37:04.18

まあWindowsみたいにcharはロケール依存のままでwchar_tだけUnicodeという構成もあるので
UnixのUnicode対応にUTF-8が必須だったかというとわからんけどなー

**デフォルトの名無しさん** · 2018/08/14(火) 19:46:09.12

>>680
え？ Unixもwchar_tはUnicodeだけど？

**デフォルトの名無しさん** · 2018/08/14(火) 20:25:18.83

正確には、既存のコードの多くは wchar_t が使われて無くて、
その対応が大変だっていう話

WindowsはOSすべてを自分たちで作ってるからどうにかなったが、
オープンソースで他人が作ったものの寄せ集めだと対応が大変だろうね

**デフォルトの名無しさん** · 2018/08/14(火) 20:38:21.12

gcc は、 wchar_t を16bitと32bitでコンパイル時に選択できるようになっているので、のちのちWindows以上に厄介なことになるでしょう。

**デフォルトの名無しさん** · 2018/08/14(火) 22:54:07.34

>>681
Linuxではそうだけど、Unix一般の話でいうとwchar_tはcharの多バイト文字をひとつの値で表せられるならなんでもいいし
実際BSDはcharがSJISならwchar_tはJISコード

**デフォルトの名無しさん** · 2018/08/15(水) 01:31:39.17

OSの中とかプログラム言語とかどうでもいい。
インターネットとかの通信プロトコルでオクテット(8bit)単位で交信、終端は0x0A 0x0Dとかの特定のオクテットコード列を使用とかになってるのが多数ある。
内部では好きなビット数で処理すれば良いけど、通信には8bit単位の処理系も必須。
ユニコード使うかどうか以前の問題。

**デフォルトの名無しさん** · 2018/08/15(水) 01:44:12.43

ケチケチ言わずIPV6くらいドカンと拡張しようぜ

**デフォルトの名無しさん** · 2018/08/15(水) 02:10:10.66

wcharは、内部の符号化に依存しちゃいけないし、幅が 16bitか32bitかに依存するのもよくない
使うのがなかなか難しいね

但し、char と混在させるのは単なる誤り。printf に使うと途中で切れるとかいうのは使う側のミス

**デフォルトの名無しさん** · 2018/08/15(水) 05:49:51.06

wchar_tやったときない

**デフォルトの名無しさん** · 2018/08/15(水) 11:55:41.55

>>687
printfで途切れる云々は仮にLANG=C.UTF-16みたいなロケールがあったとしての話だろ？
isdigit等も実装できないし、規格上できないようになってるとは思うけど

**デフォルトの名無しさん** · 2018/08/15(水) 13:30:59.38

>>687
printfはchar（のポインタ）を受け取るんだから、wchar_tは使えないでしょ？
というかcharで表示できない文字だから、wchar_tが作られたというのが正しい

そうなると、printfだけでなく多くの文字列用関数に対して
charバージョンとwchar_tバージョンが必要になって、変更しなければいけなくなるよね
それが大変だからUnix/LinuxはUTF-16には対応するのは現実的に不可能
対応が簡単なUTF-8を作りました。という流れ。

>>689
> LANG=C.UTF-16みたいなロケールがあったとしての話だろ

Unix/LinuxはUTF-16に対応するの大変だから、
そんなロケールは実現できないだろうね

似たような理由EUC-JPは対応できたけど、SJISは対応できなかった

と思ったけど以下のような警告出るけど使えるのかｗ
> # localedef -f SHIFT_JIS -i ja_JP /usr/lib/locale/ja_JP.SJIS
> キャラクタマップ `SHIFT_JIS' は ASCII 互換ではありません, ロケールは ISO C に従っていません

こんなのまで見つけた
http://www.ossforum.jp/jossfiles/Linux_SJIS_Support.pdf
ダメ文字（文字の一部に\が含まれる場合）にさえ、あたらなければ大丈夫ってことなんかな
UTF-16と違って確率的には低いだろうけど

**デフォルトの名無しさん** · 2018/08/15(水) 15:55:17.05

>>662
シュメール文明の神アヌンナキたちの故郷の惑星のことかと思った

**デフォルトの名無しさん** · 2018/08/15(水) 16:15:54.08

乳首の甘噛み

**デフォルトの名無しさん** · 2018/08/15(水) 16:25:48.18

>>690
> 似たような理由EUC-JPは対応できたけど、SJISは対応できなかった

kwsk

**デフォルトの名無しさん** · 2018/08/15(水) 16:43:22.85

>>693
だからダメ文字だって

http://ash.jp/code/code.htm
>　また、2バイト文字の中に"\"(0x5C)を含むデータが存在するため、文字列がメタ処理されてしまい、文字化けする可能性があります。

LinuxやUnixに限った話ではないけど、
文字を1バイトずつ処理するようなもの（つまりcharポインタ）は
ASCIIと互換性がないと不具合の原因になる

だからSJISやUTF-16やUTF-32はLinuxやUnixで
ネイティブに処理するのは苦手なんだ

**デフォルトの名無しさん** · 2018/08/15(水) 17:20:00.89

中途半端な多encoding対応で不具合が出たという話。要はバグ。

**デフォルトの名無しさん** · 2018/08/15(水) 22:23:06.07

アホか、アホしか居ないか？
それともわざとボケてんのか？
なんで wchar_t の話と printf の話を一緒に語ってるんだ？

wprintf 🤔

**デフォルトの名無しさん** · 2018/08/16(木) 02:36:38.02

>>696
だからprintfで実装されているものをwprintfに修正するのが大変だって話
またwopenfなどワイド文字対応の関数が存在しない場合も存在する。

それに単純に置き換えてしまうと、今度はASCII環境で動かなくなってしまう
なぜならwchar_tは16bit または 32bitという固定サイズなので
8bitのASCIIは扱えない（当然可変長バイトのUTF-8もwchar_tでは扱えない）

だからwchart_tというものが作られたけど、Linux/Unixはそれを使用して
ワイド文字列対応にするのは現実的に不可能と判断し、
printfで扱えるASCII互換のUTF-8を使うことにした

**デフォルトの名無しさん** · 2018/08/16(木) 02:59:55.06

ダウト
wchar_t で普通に ASCII も使える。当たり前。i18n でプログラム組んだことないだろ？
UNIX 系で utf8 が好まれる最大の理由は内部コードとかじゃなくて、ファイル名。
ファイル名に直接 0x00 が入れられないので。あとはネットワークまわり。

**デフォルトの名無しさん** · 2018/08/16(木) 03:50:25.48

そりゃ16bit（つまりUTF-16）として書くか変換すりゃASCIIの範囲の文字列は
扱えるだろうさ、そうじゃなくて8bitのASCII文字が扱えないって話

charは1文字8bitとして定義されたものだが、UTF-8を扱う場合は可変長としても考えられる
wchar_tは16bit （または環境によっては32bit）であるがUTF-16を扱う場合は16bit単位の可変長、
つまりサロゲートペアを扱える。しかしwchar_tは所詮16bit（または32bit）単位なので8bitは扱えない

そのためUTF-8のファイルを読み込むときには、wchar_tに変換して読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-8に変換するとかしてだ。

このようにASCII互換のデータを扱うためには単純にchar型をwchar_t型に置換しただけでは
だめで変換処理が必要になる。それに対してUTF-8であれば、char型を可変長char型と
みなすことでそのまま扱うことができる。文字列の長さをカウントするときとか
1文字単位で処理しなければいけないところだけ、UTF-8を扱えるライブラリを使えば良い

**デフォルトの名無しさん** · 2018/08/16(木) 06:01:32.95

訂正

そのためUTF-8のファイルを読み込むときには、wchar_tに変換しながら読み込まなければいけない。
例えば8bitのASCIIコードであれば残りの8bitを\x00で埋めた16bitのUTF-16に変換するとかしてだ。