文字コード総合スレ 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/

**デフォルトの名無しさん** · 2020/09/27(日) 17:40:16.09

JIS X 0208 に「シフト符号化」として規格がある。Linux の SHIFT-JIS は基本これに従っている。
でも各社が空領域に勝手に追加した文字は、使ってはいけないことになってるのでマイクロソフトの CP932 とかとは完全な互換ではない。

**デフォルトの名無しさん** · 2020/09/27(日) 18:22:15.82

もともとShiftJISはマイクロソフトといくつかの会社で共同開発したものだよ
だからマイクロソフトがオリジナルと言っていい。

そこにNECやIBMなどが空き領域に勝手に文字を追加した。
CP932はマイクロソフトが作った文字コード（文字集合）であるが
マイクロソフトが勝手に文字を追加したのではなく、
NECやIBMの独自拡張を互換性を維持するように統合したもの

ShiftJISの亜種で困るのは、MacJapanese
アップルも同じく勝手に空き領域の文字を追加した上に同じ文字コードに
違う文字を割り当ててる。そのせいでMacとのデータのやり取りで
丸囲み数字とかで文字化けが発生する原因となった。少しは互換性を考えろって

ここに詳しく書いてあるよ
https://wiki.suikawiki.org/n/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E3%82%BD%E3%83%95%E3%83%88%E6%A8%99%E6%BA%96%E3%82%AD%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%BF%E3%82%BB%E3%83%83%E3%83%88

**デフォルトの名無しさん** · 2020/09/27(日) 19:50:11.19

そこにも書いてあるけど、最初に作られたシフトJIS には追加文字は無かった。
その後に各社が勝手に文字を追加していった。マイクロソフトもその後から互換性を無視した追加した一社。
JIS がシフト符号化方式を規格化する時の特定の会社に肩入れするわけにはいかないので、本来の空領域は使用禁止という方針を維持した。
Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。

**デフォルトの名無しさん** · 2020/09/27(日) 20:01:06.53

> マイクロソフトもその後から互換性を無視した追加した一社。
何を追加したというの？

**デフォルトの名無しさん** · 2020/09/27(日) 20:02:45.37

> Linux も OSS で多くの会社が開発に参加しているので、特定の会社には肩入れできないので、中立な JIS 規格のものを選ばざえる得なかった。

多くのソフトはCP932とかいう名前で対応してるけど？

**デフォルトの名無しさん** · 2020/09/27(日) 20:16:06.46

何この馬鹿

**デフォルトの名無しさん** · 2020/09/27(日) 20:42:09.15

>> 217
もともとマイクロソフトの CP932 には追加文字は無かったんだけベンダー各社が勝手に文字を追加することを許していた。
Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。
つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。
インターネットの正式規格(IANA)には後者に Windows-3.1J として登録されている。
両者を区別した場合に俗に後者を MS932 と呼ぶ人たちもいる。

**デフォルトの名無しさん** · 2020/09/27(日) 20:55:03.90

>>218
そう。Linux では Shift_JIS と CP932 は別の文字コードという扱いになってる。

**デフォルトの名無しさん** · 2020/09/27(日) 21:07:18.47

なんか主張がブレまくってる気がするけど、結局どういうことを主張したいの？

**デフォルトの名無しさん** · 2020/09/27(日) 21:09:23.04

SHIFT JIS には種類がいっぱいある。同じ名前でも同じものだとは思うな。互換性はない。

**デフォルトの名無しさん** · 2020/09/27(日) 22:15:06.93

>>220
> Microsoft は Windows 3.1 を出す時に NEC と IMB が拡張した文字を参考に独自に CP932 に文字を追加し、さらに各社が勝手に Windows に文字を追加することを禁止した。

だから、NECとIBMとの互換性を保つように、それら両方の文字集合を含んだCP932を作ったことでしょう？
そう言ってるじゃん

そしてさらにそこから拡張して混乱を招かないように禁止したんだね
それは当然の行為だね

> つまりマイクロソフト CP932 には昔ながらのものと、拡張されたものと2種類がある。
昔ながらのもの？なにそれ。Windows-3.1J ？MS932？同じものだけど

いちいち書いてる所探してやるの面倒くさいなと思ったけどすぐ見つかったｗ
最初にこっちを見つけてくればよかったね

Shift_JIS、CP932、MS932、Windows-31J
http://una.soragoto.net/topics/13.html

**デフォルトの名無しさん** · 2020/09/27(日) 23:12:33.54

nkfだと、sjisとcp932で扱いが異なる。
最初sjisでうまくいかないで、cp932だとうまくいった。
俺にとってのcp932事始め。

**デフォルトの名無しさん** · 2020/09/27(日) 23:17:27.83

結局、Linuxがどうたら言っていた話はなんの関係があったんだろうか

**デフォルトの名無しさん** · 2020/09/27(日) 23:21:06.50

https://weblabo.oscasierra.net/shift_jis-windows31j/

ここにはちゃんと最初の時点ではShiftJISとCP932は同じものって書いてあるな
CP932はもともとMS内部での呼び名だしな

そしてあとからNECとIBMが独自に拡張した
それじゃいろいろと困るから、あらためてMSがそれらを取り込んでCP932として再定義した。
IANAではWindows-31JでありJavaではMS932という名前になった。

MacJapaneseはどういう経緯で作ったんだろうな
NECやIBMのことなんかも考えず、アップルがShiftJISを勝手に拡張したのか？

**デフォルトの名無しさん** · 2020/09/28(月) 00:29:11.65

2022も一枚岩じゃねーのにMSシフトだけ悪者かよw

**デフォルトの名無しさん** · 2020/09/28(月) 00:45:44.06

そういやEUC-JPも亜種が多かったね

**デフォルトの名無しさん** · 2020/09/28(月) 02:22:56.82

技術の話だからな、誰が邪悪で誰が正義とかはないぞ。
種類が多数あるから気をつけろ。あえて言えば非互換な変更は可能な限り避けろ。

あと別に NEC と IBM だけが独自拡張してたわではないぞ。
Apple や Fujitsu を始めとして他も各社独自拡張してた。
マイクロソフトはビジネス上の都合で普及してた NEC と IBM のもののみから取捨選択した。
そこそこ普及してたけどライバルだった Apple のもは無視した(互換にする理由が無かった)。

**デフォルトの名無しさん** · 2020/09/28(月) 03:00:06.80

code page 932 って元々MSじゃなくて IBM の規格だけどな。
IBM が作った OS/2 とうのがあってな。それ用の文字コード名だった。
MS は IBM が OS/2 を作るのに技術協力しててな、その後に Windows 作る時にその用語をそのまま使った。
MS が拡張する前の CP932 を IBM 932 と呼ぶ人がいるのはこれが理由。

**デフォルトの名無しさん** · 2020/09/28(月) 03:09:14.91

うちがIBM社から依頼されて制作したのが始まり。
当時は広く調査する手段が無く、偏りがある事は認める。

**デフォルトの名無しさん** · 2020/09/28(月) 03:09:23.25

>>231
そういえば IBM は律義なので、文字を追加して互換性のないやつは CP943 とか別の番号を割当てて名前を変えてたんだよな。
MS はその辺を参考に文字を追加したやつも CP932 と呼び続けたのは何でだろう。

**デフォルトの名無しさん** · 2020/09/28(月) 03:39:47.21

>>233
CP932はどちらもMSが作ったコードページでMSとしては互換性があるからじゃないの？
Unicodeにバージョンがあっても文字集合が違うように
オリジナルの CP932（=ShiftJIS ）があって、そこに文字集合を
拡張したいわば CP932 2.0 という扱いだから名前を変える必要がない

IBMのは別会社だから、別の名前にするのはそこまで不思議じゃないかな
むしろNECがなんでCP932を使ってるかのほうが気になるけど
NECもMS-DOSを使っていたからかな

最初のMS製のCP932は1982年に作られて、NECとIBMが独自拡張したのは1983年なんだね
アップルは1991年にそれまた独自で拡張してる
そして再構成されたCP932ができたのは1993年のようだ

**デフォルトの名無しさん** · 2020/09/28(月) 04:20:00.06

code page 番号での管理は IBM が汎用機時代からずっとやってきた名前で、
マイクロソフトは後から、その番号をそのまま採用したって聞いたけど、違うの？

**デフォルトの名無しさん** · 2020/09/28(月) 05:06:08.90

>>235
もともとMSとIBMは1990年代まで協力してOS開発をしてた
例えばIBM PC用のPC-DOSはMS-DOSをリネームしたもの

だから共通のコードページを使用するのは当たり前
1990年代以降にOS開発の協力をやめてからはそれぞれ独立して
コードページを管理してる

古くはIBMが使っていた用語のようだがCP932がなんかができた時期は共同開発なんだろう
MS等数社でShiftJISの仕様を作ってそれをOSに実装するときにCP932という管理番号が与えられた

https://en.wikipedia.org/wiki/Code_page

**デフォルトの名無しさん** · 2020/09/28(月) 09:14:02.90

共通のコードページを使うようになったのはいつから？
そこが曖昧なんだよな。
マイクロソフトは元々 CP932 とは呼んでなかったという意見があるみたいなんだが。

**デフォルトの名無しさん** · 2020/09/28(月) 09:33:14.92

>>234
NEC は厳密に言えば CP932 に文字を追加したわけではないからなあ。
NEC や Fujitsu がやったのは漢字ROMの空き領域に字形を追加した。
これをやると OS とか文字コードに関係無く使える漢字が増える。CP/M でも BASIC でも。

**デフォルトの名無しさん** · 2020/09/28(月) 09:42:09.44

ANSI先生、シフトジスがめんどくさいです...

>>227
HTMLでcharset=Shift_JISであっても実際はWindows-31Jだったりする。
巷の大概のブラウザはWindows-31Jにしかない文字があっても開ける。はしご高とか。

そうやってある意味グダグダになっていく（った）わけやね。でもしょうがないのかな。
厳密な挙動をしても「えーこのブラウザ文字化けするー」とか言われちゃうのがオチだし。

ま、HTMLはもうだいぶUTF-8になってきてるし、いっかw

**デフォルトの名無しさん** · 2020/09/28(月) 10:30:21.69

>>237
元々というのがいつの話か知らんが、chcp "MS-DOS 3.3" で検索したら
海外のMS-DOS3.3（1987年）にはCHCPコマンドがあったようだね

http://radioc.web.fc2.com/column/pc98bas/internal-version-of-msdos-33.html
https://www.pcjs.org/documents/books/mspl13/msdos/encyclopedia/appendix-a/

ここからCP932が存在したということにはならないけど
今と同じコードページはMS-DOS当時使われていた
そこに別のものを使うとは思えないな

当時は日本ではほぼNECの独占状態で、日本専用なわけだから
コードページの切り替えはないしCHCPは存在しないから
日本では知られてなかっただけじゃないの？

**デフォルトの名無しさん** · 2020/09/28(月) 10:39:54.81

>>238
NEC の汎用機に文字が追加された。もちろんSJIS関係ない。
NEC の汎用機の端末として使えるようにするために PC9801 の漢字ROM は NEC追加文字が含まれて状態で発売された。
ちばみに IBM拡張漢字ROMは別売オプション。
PC9801 に MS-DOS を移植したら、あーら不思議、最初から使える文字が増えてた。
という順序だな。

**デフォルトの名無しさん** · 2020/09/28(月) 10:41:07.34

>>238
MS-DOS、漢字ROMの時代はOSが知っているのは文字コードだけで
そこで表示されるフォントはハードウェア搭載されてるものだったからね

ShiftJIS系は全て同じものとして扱うことしかできなかった
勝手に違う文字コードに化けさせるわけには行かないし

細かい文字コードを区別できるようになったのはフォントをOSで
処理するようになったWindowsから
だからそのときに改めて統一する必要がでてきた

**デフォルトの名無しさん** · 2020/09/28(月) 10:45:58.86

>>240
最初(1982年)からCP932だったという主張は撤回するのん？

**デフォルトの名無しさん** · 2020/09/28(月) 10:46:31.48

NEC独自の文字としては2バイト系半角文字がお気に入りだったな

数字やアルファベットが縦長で、全角半角混ぜても違和感ないんだよ
2バイトだけど文字幅は1バイトと同じでな

表示位置の調整の計算は、2バイトは1バイトの倍として
計算するだけでは駄目だったんだよ
1文字ずつ見ていって文字コードの範囲をみて計算する必要がある

ライブラリもなかったしC言語で実装するのはすっげーめんどくさかったクソ仕様

**デフォルトの名無しさん** · 2020/09/28(月) 10:47:44.81

>>243
してないよ。MS-DOSでは最初からCPxxxというコード体系が使われていたと言ってる
当時は日本で広まっていないだけ

**デフォルトの名無しさん** · 2020/09/28(月) 11:04:04.80

>>245
推測とかじゃなくて、その根拠が知りたいんだが。どこ情報？

**デフォルトの名無しさん** · 2020/09/28(月) 11:07:15.33

あ、別に否定してるわけじゃないよ。
世間一般に曖昧なんでちゃんとした根拠があるなら知りたい。

**デフォルトの名無しさん** · 2020/09/28(月) 11:21:20.86

>>246
そんなに答えを求めてるなら「今となってはわからない」が正解じゃねｗ
少なくともCP932が使われていなかったという根拠はないからね

◆QZaw55cn4c · 2020/09/28(月) 19:55:51.42

もう、PC98 に搭載されている漢字 ROM が正義、とするのがいいかと
で、PC9801 各シリーズおよび PC9821 各シリーズで差異があるかどうかが問題

私の一番すきな 98 は 98FA なので、98FA が正義でありたい

**デフォルトの名無しさん** · 2020/09/28(月) 20:15:42.82

□□□□□□□□□□□□□□□□□□□□□□□□□
□□■□■■□□□□■■□□■■■□□□■■■□□
□■■□□□□■□■□□□□□□□■□□□□□■□
□□■□■□□■□□□□□□□□□□□□□□□□□
□■□□■□□■□□□□□□□□□□□□□□□□□
□□□■■■□■□□■■□■□□□□□■□□□□□
□□□■■□□□■□□□□□■■■■□□■■■■□
□□□□□□□□□□□□□□□□□□□□□□□□□

**デフォルトの名無しさん** · 2020/09/28(月) 21:40:36.46

https://ja.wikipedia.org/wiki/Microsoftコードページ932

1982年(JIS X 0208-1983策定の前年)、JIS C 6226(JIS X 0208)を複雑にシフトさせた文字符号化方式としてShift_JISが誕生した。
この符号化方式(を利用した拡張符号化文字集合)は、マイクロソフトによりMS-DOSにおける標準日本語コードとして採用され、
「コードページ 932 (CP932)」という管理番号を与えられた。

しかし、マイクロソフトは、MS-DOSにおける唯一の日本語用コードページである「CP932」を、OEMメーカーの自由に任せていた。
そのため、NECのPC-9800シリーズ、IBMのPS/55 シリーズ、富士通のFMRシリーズなどは全て、MS-DOSを搭載し
文字符号化方式もShift_JISを採用しているコンピュータであるにもかかわらず、登録されている文字集合がバラバラだった。

**デフォルトの名無しさん** · 2020/09/28(月) 21:49:17.49

jawpをソースにするなよ

**デフォルトの名無しさん** · 2020/09/28(月) 22:15:52.03

当時としてはMS-DOSはコンピュータで動くOSの１つでしかないのに
マイクロソフトがコンピュータに搭載する文字集合を決めるなって話だろ

◆QZaw55cn4c · 2020/09/28(月) 22:32:50.70

>>253
そういう意見など、奴らは無視して漢字を 16ビットに無理やり押し込めにかかり、
あわてた中日韓が妥協させられてできあがったのが CJK 漢字統合
月日は流れ、結局 16 ビットの中に世界の文字を押し込めることなど出来ないと奴らが悟った後には、醜い CJK 漢字統合だけが残されたのであった…

**デフォルトの名無しさん** · 2020/09/28(月) 22:43:50.48

>>254
そんな話してないよ

**デフォルトの名無しさん** · 2020/09/28(月) 23:19:53.80

人はみな自分の話したいことのみを話す。

>>249
NECの漢字ROMに合わせると、旧JISになるのだが、それでよろしいか？

実はこれま語られた以外にも Shift JIS には、いわゆる旧JIS(JIS78) と新JIS(JIS83)の違いというヴァリアントがあるんだよな。
NECの漢字ROM は旧JIS準拠で、富士通の漢字ROMは新JIS準拠で、互換性が無かったりとか。
マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、
今の CP932 は新JIS準拠の字形になってるので、どこかの時点(多分 DOS/Vあたり)で、ちゃっかり入れ換えてるんだよな。

**デフォルトの名無しさん** · 2020/09/29(火) 01:44:43.55

なんとなーくNECの漢字ROMはShiftJISじゃないのか！？とかいい出す人がいいそうｗ

PC9801シリーズは漢字ROMが搭載されていて、
テキストVRAMに文字コードを書き込むだけで画面に漢字が表示される

そのときに使われる文字コードはシフトJISではなくJISコード

http://software.aufheben.info/oohpc/textvram.html
> JISコードで書き込む
> 通常MS-DOS上でプログラミングをしているのであれば、文字コードは
> シフトJISコードを使っていることでしょう。ところが、テキストV-RAMには
> JISコードで書き込まなければならないので、別途変換ルーチンが必要です。

MS-DOSはシフトJISを使っているが、文字を表示する場合はこのような簡単なアルゴリズムで変換できる
MS-DOSで使われてる文字コードはCP932といううが、実際にはシフトJIS→JISコードの変換アルゴリズムがあるだけ
だからCP932の空き領域だってJISコードにマッピングされるし、文字を表示は漢字ROMの仕事

もしPC9801シリーズにCP932を遵守しろというのであれば、
漢字ROM（JISコード）にCP932以外を乗せるな！というしかない
だがPC9801は別にMS-DOS専用のコンピュータというわけではない

ハードウェアの仕様の話なのになぜマイクロソフトに命令されなければならないのだ？という話になる

**デフォルトの名無しさん** · 2020/09/29(火) 01:52:41.35

>>256
> マイクロソフトも Shift JIS 作った時には旧JISしか無かったはずなので、旧JIS準拠だったはずなんだけど、

マイクロソフトがやったのは実質シフトJISからJISコードへの変換でしかないので
例えば古いバージョンのMS-DOSのバージョンで古い一太郎（笑）を使っていて
それを収録文字数が増えた新しいハードウェアに買い換えるとMS-DOSも一太郎も同じ古いままで
新しい文字に対応できてしまうんだよね。対応する文字は漢字ROMで決まることだから

つまりMS-DOSはCP932を想定していたとしても
実際に対応する文字はMS-DOSで決めることができない

マイクロソフトが使ってる文字コードをShiftJISと呼ぼうがCP932と呼ぼうが
NECや富士通なんかが勝手に文字を追加してしまうわけ

**デフォルトの名無しさん** · 2020/09/29(火) 03:15:45.97

そもそも IBM も NEC も富士通も、パソコンの主な使用目的の一つは、自社の大型コンピューターの端末として使うことだったからな。
だから自社の汎用機に合わせて文字を追加したんであって、MS-DOS とか眼中にはない。
追加した漢字が MS-DOS からもたまたま使えただけ。
パソコン専用の Apple の文字追加はまた別の理由だが。

**デフォルトの名無しさん** · 2020/09/29(火) 06:39:24.27

東風フォントの人元気かな

**デフォルトの名無しさん** · 2020/09/29(火) 08:26:34.17

>>252
だったらWikipedia以外のまともなソースとやらを出してくれよ
どうせ出せないんだろ？

**デフォルトの名無しさん** · 2020/09/29(火) 11:27:29.43

今となっては別に昔の名前なんてどうでもだが。
アスキー・マイクロソフトが出した最初に Shift JIS に対応した MS-DOS 2.01 では MIcrosoft Kanji Code が正式名称だった。
MS-DOS のソースコードの中でSJISの処理をする部分は KANJI という表記だった。

**デフォルトの名無しさん** · 2020/09/29(火) 13:51:59.38

https://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/JIS_and_Shift-JIS_variants.svg/2880px-JIS_and_Shift-JIS_variants.svg.png

**デフォルトの名無しさん** · 2020/09/29(火) 14:17:45.42

>>263
図をまとめる下手すぎ
わざとわかりづらくしてるようにしか見えない

**デフォルトの名無しさん** · 2020/09/29(火) 17:25:53.58

白黒の限界を感じる。後、矢印の向きが派生ではなく包含関係だったりして、
通常とは逆なので知らない人が見ても理解するのは難しいかも。努力は認める。
>>264
文句あったらお前が書き直せ(お約束)

**デフォルトの名無しさん** · 2020/09/29(火) 17:37:33.69

>>264
時系列とかメーカーで横に並べるべきだろうね

**デフォルトの名無しさん** · 2020/09/29(火) 17:39:10.32

EUC-JPとShiftJIS系とUnicode系でも分けるべきだし
包含関係でまとめられるのはまとめるべきだろう

**デフォルトの名無しさん** · 2020/09/29(火) 17:51:57.33

ぱっと見てみたけど、包含関係は、かなり正確だな。
今までここに上げられた、いい加減な図と比べるとかなりマシ。
NEC の CP932 と、IBM の CP932 を混ぜて Windows CP932 ができたなどという中途半端な説明が
間違いということが、わかるように書かかれている。

**デフォルトの名無しさん** · 2020/09/29(火) 17:55:22.30

>>268
図の真ん中、Shift-JIS Windows 932は
Shift-JIS with NEC r13 and 89-92 and IBM DBCS からできたって書いてありますが？

**デフォルトの名無しさん** · 2020/09/29(火) 18:03:23.01

そして、その「Shift-JIS with NEC r13 and 89-92 and IBM DBCS」は
「Shift-JIS with NEC r13 and 89-92」＋「Shift-JIS with IBM DBCS」のことだって書いてありますよね？

**デフォルトの名無しさん** · 2020/09/29(火) 18:17:32.15

左からも矢印が延びてるの見えない？

**デフォルトの名無しさん** · 2020/09/29(火) 18:20:25.83

左からの矢印？
そりゃいわゆるShiftJISと呼ばれたものに「NECの追加文字」と「IBMの追加文字」を加えたって言ってるんだから
左のもの（基本的な文字セット）もあるに決まってんだろｗ

**デフォルトの名無しさん** · 2020/09/29(火) 18:34:13.19

都合の悪いものは見えない目をしてる奴がいるようなので、
その図で表示されている文字集合の関係を表にしてみた。
Windows CP932 だけ他と比べて明らかに違うところあるだろ。
逆に IBM の CP932 にあって Windows 932 にないのとかも

A J K IBMex 漢 IBM漢 NEC特 NEC漢
Invaliant × ○ ○ × ○ × × ×
with NEC r13,80-92 × ○ ○ × ○ × ○ ○
with IBM DBCS × ○ ○ ○ ○ ○ × ×
IBM CP 932 × ○ ○ ○ ○ ○ × ×
with IBM DBCS & NEC × ○ ○ × ○ ○ ○ ○
Windows CP 932 ○ × ○ × ○ ○ ○ ○
IBM CP 943 × ○ ○ ○ ○ ○ ○ ○

A: ASCII
J: JIS X 0201 Romaji (JIS半角英数字)
K: JIS X 0201 Kana (JIS半角カナ)
漢: JIS X 0208 (JIS漢字)
IBMex: IBM katakana extesion (IBM半角拡張)
IBM漢: IBM DBCS extension (IBM漢字拡張)
NEC特: NEC row 13 (NEC特殊文字)
NEC漢: NEC row 89-92 (NEC漢字 + IBM選定NEC漢字)

**デフォルトの名無しさん** · 2020/09/29(火) 18:35:11.83

表ズレた。すまん。

**デフォルトの名無しさん** · 2020/09/29(火) 18:39:08.12

>>215のリンク先に書いてある

> マイクロソフト標準キャラクタセット (Windows-31J、MS932) は、
> マイクロソフト社が使用している日本語用文字コードで、シフトJISの一種です。
> [37]標準的なシフトJISに加え、NEC や IBM の拡張に由来するいくつかの追加文字を収録しています。

NEC や IBM の拡張に由来する「いくつかの」追加文字を収録していますという話を繰り返しただけか
リンク先読んでねーなこいつｗ

**デフォルトの名無しさん** · 2020/09/29(火) 18:41:53.46

再挑戦。
Ａ　Ｊ　Ｋ　Ｘ　漢　Ｉ漢　Ｎ特　Ｎ漢
×　○　○　×　○　×　　×　　×　　Invaliant
×　○　○　×　○　×　　○　　○　　with NEC r13,80-92
×　○　○　×　○　○　　×　　×　　with IBM DBCS
×　○　○　○　○　○　　×　　×　　IBM CP 932　
×　○　○　×　○　○　　○　　○　　with IBM DBCS & NEC
○　×　○　×　○　○　　○　　○　　Windows 932
×　○　○　○　○　○　　○　　○　　IBM 943

Ａ: ASCII
Ｊ: JIS X 0201 Romaji (JIS半角英数字)
Ｋ: JIS X 0201 Kana (JIS半角カナ)
Ｘ: IBM katakana extesion (IBM半角拡張)
漢: JIS X 0208 (JIS漢字)
Ｉ漢: IBM DBCS extension (IBM漢字拡張)
Ｎ特: NEC row 13 (NEC特殊文字)
Ｎ漢: NEC row 89-92 (NEC漢字 + IBM選定NEC漢字)

**デフォルトの名無しさん** · 2020/09/29(火) 19:33:37.91

ASCII 互換じゃないから Linux では SJIS は使えないｷﾘ
とかほざいてたのいたけど、実際には ASCII 互換じゃないと困るのは Windows の方だったという落ち。
樂しい♪

**デフォルトの名無しさん** · 2020/09/29(火) 19:49:07.20

>>277
仕方ないよな。UNIX 系のパス区切りは / なので ISO-646 系ならどれでも共通だけど
Windows はパス区切り \ なので国ごとに違っていて、Unicode に変換した時に困る。

**デフォルトの名無しさん** · 2020/09/29(火) 20:13:35.05

>>278
ん？
Windowsのパス区切りは、あくまでバックスラッシュで、
それぞれの言語環境で別の文字に見えてるだけでしょ？
割り当てられた文字コード番号自体は同じじゃないのか？

◆QZaw55cn4c · 2020/09/29(火) 20:34:00.58

>>279
win32api から見る限り、パス区切りは \ であっても / であっても使えます

**デフォルトの名無しさん** · 2020/09/29(火) 20:51:03.40

>>277
アプリケーション側の問題だからね
OSだけ対応していても

**デフォルトの名無しさん** · 2020/09/29(火) 20:55:47.86

mohtaの昔から文字コードの話はなんでこう揉めるんだろ

**デフォルトの名無しさん** · 2020/09/29(火) 22:01:45.11

https://docs.microsoft.com/ja-jp/previous-versions/visualstudio/visual-studio-2008/77859s1t(v=vs.90)

UNIX ではパスデリミタとしてスラッシュ (/) しか使用できませんが、Win32 オペレーティングシステムは円記号 (\) とスラッシュ (/) の両方を使用できます。

**デフォルトの名無しさん** · 2020/09/29(火) 23:21:22.59

バックスラッシュをファイル名に使えるからデリミタに使う意味がない

**デフォルトの名無しさん** · 2020/09/30(水) 00:15:57.00

それどころか多分どの制御コードやDEL、極めつけは
改行コードまでLinuxやUNIXはファイルめに使えるんだ
すごいだろー

findでどうやって改行コードが入ったファイル名を扱うのか知らんがｗ

**デフォルトの名無しさん** · 2020/09/30(水) 00:17:36.68

バックスラッシュをファイル名に使うと面白いことができて
echoでそのファイル名を表示すると、色を付けたりできるんだｗ

**デフォルトの名無しさん** · 2020/09/30(水) 00:18:07.91

間違ったｗ色をつけるのはエスケープコードだったｗ

**デフォルトの名無しさん** · 2020/09/30(水) 00:24:04.53

🐏スケープゴートに空目したわ

**デフォルトの名無しさん** · 2020/09/30(水) 00:24:37.97

>>285
たいていのシェル環境だとデフォルトは Ctrl-V の後に改行を入れる。カスタマイズ化。

**デフォルトの名無しさん** · 2020/09/30(水) 00:25:31.56

訂正。🐐ゴートは羊じゃなくて山羊

**デフォルトの名無しさん** · 2020/09/30(水) 00:27:29.17

入力でなくて出力の話なら -0 オプションで、改行区切りから Null 文字区切りに変更できる。

**デフォルトの名無しさん** · 2020/09/30(水) 01:46:35.60

ぬるぽ

**デフォルトの名無しさん** · 2020/09/30(水) 02:06:47.48

>>291
それはPOSIX準拠じゃないんだよなｗ
UNIXは改行が使えるから、UNIXで苦労するｗ

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

ファイル名にコロンが使えるから
PATHのコロン区切りで問題が出るというねｗ
制御文字と一部の記号は使えないようにするべきだっただろうな

**デフォルトの名無しさん** · 2020/09/30(水) 02:13:17.35

アホか？使いたくない文字は使わなきゃ良いだけなんやで。
わざと変な文字入れて、変な文字入れられる方が悪いとか、小波。

**デフォルトの名無しさん** · 2020/09/30(水) 02:17:17.38

>>295
論点ずれてるぞｗ
いろんな文字が使えちゃうから、それが原因でバグになるということだ

ファイル名に改行を入れられるってことを知らないで作っていたら
「bin<改行>lib<改行>etc」みたいなフォルダを消そうとして被害にあったり
「a*?」みたいなファイル名でaで始まるファイルが全部消えたりｗｗｗとか
実際に起きてるからな

**デフォルトの名無しさん** · 2020/09/30(水) 02:26:40.95

>>292
ｶﾞｯ

**デフォルトの名無しさん** · 2020/09/30(水) 02:26:53.11

制限したいやつが制限すればええんやで。Linux にはその仕組みがある。
普通の人はそんなことせんでも変は文字入れないから、困ってないだけ。

**デフォルトの名無しさん** · 2020/09/30(水) 02:49:29.19

入れたくていれるんじゃなくて
端末に文字をペーストしたら変な文字を実行しちゃったりして
その結果変な名前のファイルができたりするんだよ

*とか?とか<とか>とか!とかシェルのメタ文字は
ファイルに使えないようにするべきだった
互換性があるから手遅れなんだろうけど

普通の人は変な文字入れないというのなら
なおのこと入れられないようにしてよかったということになる

**デフォルトの名無しさん** · 2020/09/30(水) 03:03:44.88

だから、そんな間抜けなユーザー抱えてんなら管理者が制限設定入れとけや。
普通、変なファイルできても ls すれば、すぐ気付くし、シェルの補完とかも対応してる。
やってみもせずに妄想垂れ流す暇あったら触ってこい。
それでも駄目だと思うんなら、システム制限掛けとけ。

**デフォルトの名無しさん** · 2020/09/30(水) 03:11:45.53

シェルの補完にバグがないとどうしているんだ？ｗ
メタ文字とかは勝手にエスケープが入ったりする。だがそれが正しいとどうしていえる？
どうエスケープすればいいかを知らなければ、今からエンター押しても大丈夫か？なんてわからんはずだが
だから俺はGUIから消すようにしてるよ。GUIならシェルのワイルドカード展開なんて使えないからね

**デフォルトの名無しさん** · 2020/09/30(水) 03:15:35.92

お前に Linux は早過ぎた。
バグが心配ならソースでも眺めとけ。ここプログラム板やし。

**デフォルトの名無しさん** · 2020/09/30(水) 03:23:32.50

初心者「バグがあるかもしれない」
プログラマ「バグなんてあるわけない」

こういう考えかｗ

**デフォルトの名無しさん** · 2020/09/30(水) 03:39:20.46

初心者：いきなりバグとか心配しない。気になったたらドキュメントとか、ネット調べたり、試行錯誤して学習する。
プログラマ：いきなりバグとか心配しない。気になったらソースコード確認して、万一バグを見つけたら自分で直す。
お前：根拠無くバグが心配になり、5ch でOS の仕様にケチをつける。

**デフォルトの名無しさん** · 2020/09/30(水) 03:41:07.93

>>304
お前が気になったことの例を１つでも上げてみてよｗ

**デフォルトの名無しさん** · 2020/09/30(水) 03:51:15.98

なんてレスしてるうちにバグ報告したとある有名プロジェクトから
修正したってコメントが有ったわｗ

**デフォルトの名無しさん** · 2020/09/30(水) 10:44:11.67

MS「CON\CONなんてパスを指定する奴なんているはずないな」

**デフォルトの名無しさん** · 2020/09/30(水) 11:03:16.10

>>307
バグじゃなくて仕様だよ。予約されてるから。

**デフォルトの名無しさん** · 2020/09/30(水) 11:04:41.69

制約事項として明記された不具合は仕様と呼んでいい。

**デフォルトの名無しさん** · 2020/10/02(金) 03:35:07.39

>>99
それなら普遍的に使えるスタイルとの結合文字にすりゃいい話
だけどそうしないのはそもそもスタイルと文字は分ける設計だから
スタイルはCSSなり他の技術がある

**デフォルトの名無しさん** · 2020/10/02(金) 03:36:07.77

肌の色とか差別がなかったところに肌の色って概念を導入した結果結局偏りが生まれてるクソ仕様

**デフォルトの名無しさん** · 2020/10/02(金) 03:47:03.40

>>311
それはもう解決済みの問題です

**デフォルトの名無しさん** · 2020/10/02(金) 11:31:57.29

こんにちは、初めまして。

今、個人的に amazon kindle端末用の電子書籍データを作るにあたって
仕様として JIS X 0213:2004 を保証すると書いてあるのでこの文字コードのユニコードのセットをまとめて
いわゆる JIS X 0213:2004 文字チェッカーのようなものを作っています。
Webページベースでユニコードのテキストを入力して、
使用してる文字が Kindle端末オーケーかどうかをチェックするプログラムです。
JavaScript(u16)用と PHP(u8)用で二種類のチェックプログラムを作ってます。

それで資料を集めて検証しているところなのですが、ちょっと判断に迷うコードがあったので、
他に聞ける場所も無いということで、ちょっとここで質問してみることにしました。

以下のコードなのですが、方や u16 で２文字(U+025B U+0300)、方や１文字(U+1F72) になってます。

https://ja.wikipedia.org/wiki/JIS_X_0213非漢字一覧
(A) ɛ̀ 1-11-48 0x866f U+025B U+0300 グレーブアクセント付きEPSILON小文字
(A) ɛ́ 1-11-49 0x8670 U+025B U+0301 アキュートアクセント付きEPSILON小文字

https://www.asahi-net.or.jp/~ax2s-kmtn/ref/unicode/u1f00.html#u1f72
(B) U+1F72 ὲ グレーブアクセント付きEPSILON小文字
(B) U+1F73 έ アキュートアクセント付きEPSILON小文字

この文字だけに限っての判断としますが、
どちらか一方が出た場合にどちらかに変換して正規化するとした場合、
正規化後は (A) と (B) のどちらが良いと思いますか？

気が向いたらレスを付けてくれたら嬉しいです、参考にしますので。

ちなみに、Windows10等でキーボード入力される全角チルダ(U+FF5E,'～') は
JIS x0213:2004 コード規格の波線(U+301C,'〜') に正規化することにしています。
(その他、似たような文字はなるべく一種類に正規化出来ればと考えています)

**デフォルトの名無しさん** · 2020/10/02(金) 11:37:56.63

グレープってなんだって思ったらグラーブのことか