文字コード総合スレ 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/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の中の人がサードのライブラリ引いてね発言するくらいヤバい

**デフォルトの名無しさん** · 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を介して処理するのが堅実だよ