文字コード総合スレ 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/25(金) 02:48:35.22

>>160
だから、それ、お前の妄想だろ。不可能とかどこにも書かれてない。

実際やろうと思えばできる。素人じゃあるまいし。Ken って誰だか知ってるか？
ただ、互換性がないから嫌っていたという話。
Windows とかはしょちゅう非互換な変更を加えるけど、Unix とかは文化として相互の協調動作を重視するんだ。
それで、可能な限り非互換な変更を避けようとする、仕方がない場合にはやるけど。
実際問題 Plan-9 には UCS-2 と UTF-1 の両方が既に開発済みで、リリース間近だった。
ちょうど、その時に X/Open comitee の人から電話がかかって来て、UTF の改良について相談されたので、速攻でより互換性の高い新しい符号((UTF-8)を設計して提案したという話。

**デフォルトの名無しさん** · 2020/09/25(金) 02:51:32.21

>>161
そんな見苦しい言い分けしても、お前の間違いはごまかせないんだぜ。

**デフォルトの名無しさん** · 2020/09/25(金) 03:18:37.40

お前の間違いってどれよ、挙げてみｗｗｗお前が思ってるお前の発言は多分俺の発言じゃないから
一人を相手にしてると思ってるなら大間違い

**デフォルトの名無しさん** · 2020/09/25(金) 03:20:48.06

>>162
書いてある

> However, UCS and its UTF variant do not protect
> null bytes and/or the ASCII slash ("/") making these character encodings
> incompatible with existing Unix implementations.

しかしUCSとその亜種であるUTFはヌル文字とスラッシュを保護せず
存在するUnixの実装と互換性がありません。

**デフォルトの名無しさん** · 2020/09/25(金) 04:05:10.29

>>165
互換性がないとしか書いてないようだが？

**デフォルトの名無しさん** · 2020/09/25(金) 08:01:55.95

だからOSの方を書き換えるのが現実的に不可能だったんだろ

**デフォルトの名無しさん** · 2020/09/25(金) 08:06:49.98

>>162
＞ Windows とかはしょちゅう非互換な変更を加える

これって何のギャグよ

**デフォルトの名無しさん** · 2020/09/25(金) 08:14:51.08

互換性がないから嫌いとしか読めん
現実に各社 Unix でも Linux でも UTF-16 実装してるんだよなあ。
不可能とは？

**デフォルトの名無しさん** · 2020/09/25(金) 08:19:51.13

不可能なのは各コマンドをUTF-16対応にすること

**デフォルトの名無しさん** · 2020/09/25(金) 09:16:58.00

なんで？
プログラムと API を書き換えれば、普通にできるよ。
実際 Windows はそれをやったわけだし。

**デフォルトの名無しさん** · 2020/09/25(金) 09:28:26.81

>>171
Mivrosoft は愚直に全てのプログラムを書き換えた。
UNIX陣営は UTF-8 を発明して、その手間を大幅に省いた、天才。って話だわな。

**デフォルトの名無しさん** · 2020/09/25(金) 09:31:02.93

>>171
永遠の時間があればできるだろうなって話
Windows NTは最初のバージョンからUnicode対応だった

**デフォルトの名無しさん** · 2020/09/25(金) 09:36:14.75

逆だろ、Unicode 対応のために DOS-FAT から NTFS に非互換な変更したってだけだろ。
DOS-FAT はあまりにもダメダメなので、他の理由でも置き換えるのが必須だったので決断は簡単だった。
一方 UNIX 系の FS は FAT に比べれば良くできてたので、置き換える意欲に乏しかった。

**デフォルトの名無しさん** · 2020/09/25(金) 10:34:03.53

DOSは最初からSJISなんていう、これまたUnix系では（完全に）対応することができない
文字コードに対応してるわけでその理屈はおかしい

更に言うなら1995年に発売されたNT3.5（NT系としては2つ目のバージョン）に
搭載されているFATは長いファイル名をサポートし文字コードはUTF-16を使う

https://en.wikipedia.org/wiki/File_Allocation_Table#Long_file_names
> One of the user experience goals for the designers of Windows 95 was
> the ability to use long filenames (LFNs?up to 255 UTF-16 code units long)

**デフォルトの名無しさん** · 2020/09/25(金) 11:53:51.78

DOS-FATなんて使われてない用語を使ってるのは、印象操作でも目論んでるようにしか見えないが
FATの正統後継であるexFATは今も使われてるしSDカードの標準のファイルシステムとして公式採用されてる
だめだめの部分がなにか知らんがとっくに改良されておりよくできたファイルの一つとなってる

**デフォルトの名無しさん** · 2020/09/25(金) 11:57:18.65

お前はネットで検索した情報を知ったかする前に、まずは時系列順に並べ替えてみろ。

**デフォルトの名無しさん** · 2020/09/25(金) 12:43:52.40

>>177
それはお前がやるべきことだ
　　
なぜ俺が不利になる（？）ようなことを
俺がわざわざ調べないといけないんだｗ

反論があるならお前がしろ
自分が反論できないからって相手に反論の
材料を探させるという間抜けをするな
やるわけねーだろアホｗ

**デフォルトの名無しさん** · 2020/09/25(金) 14:19:51.56

ちゃんと調べれば自分が間違っていることに気づくぞ、というアドバイスなんだが。
不都合な真実は知りたくないというのなら、永遠に間違って理解してろ。
残念ながらお前は技術者には向いてないんだろうと思う。

**デフォルトの名無しさん** · 2020/09/25(金) 14:27:52.78

ANSI文字列を扱うAPIをいまだに保守し続けているWindows
デフォルトエンコーディングをEUCから突然UTF-8に切り替えたunix

互換性を軽視しているのはどちらでしょう

**デフォルトの名無しさん** · 2020/09/25(金) 14:29:21.59

>>179
調べてた結果正しかったです。調べたくない人が事実を知りたくないだと思います（笑）

**デフォルトの名無しさん** · 2020/09/25(金) 16:02:35.34

調べなくても、その辺の時系列はよく知ってるんだよ。当時、リアルタイムでおっかけてたので。
時系列誤解して、知ってるやつなら絶対に間違えないレベルの主張してるのがいたので指摘しとこうかと思っただけ。
お前は知りたくなければ知らなくて良いよ。
十分に事実は書いたので、後から奇特にもこのスレ覗きに来て、お前の妄言に惑わされる奴もいないだろうし。
p.s. 上から目線なのはジジイなので許せ。

◆QZaw55cn4c · 2020/09/25(金) 21:10:47.40

>>180
その unix とやらの具体的で正式な OS の名称を教えてください…

**デフォルトの名無しさん** · 2020/09/25(金) 21:18:32.55

しょっちゅう非互換な変更を加えるWindowsって具体的にはどれの事よ

**デフォルトの名無しさん** · 2020/09/25(金) 21:22:39.15

https://docs.microsoft.com/ja-jp/archive/blogs/nakama/win10waas-part5a

カーネル依存性のないデスクトップアプリの場合、少なくとも「まったく動作しなくなる」といった致命的な問題はほとんど出ないと思います。
Windows 7 で動作していた .NET 3.5 のアプリのほとんどは、Windows 10 上の .NET 3.5 でもまず十中八九動作するはずで、
先行検証しているあるお客様からは、「まるで非互換問題が出てこないんだけれども、名前だけ変えてお金稼ごうとしてない？」とか言われたことがあるぐらいです；。

**デフォルトの名無しさん** · 2020/09/25(金) 21:53:11.91

>>185
マイクロソフトは互換性が高いと主張しています。それは事実だと思いますが
それでも断定はできないし保証はできないので検証は必要です。

ただしお客様の方で検証していただければお金は不要です。
問題があった場合は有償でサポートしますが対応に時間がかかることがあるので
余裕を持ったスケジュールで行ってください。

って言えば良いんかな？

**デフォルトの名無しさん** · 2020/09/26(土) 04:29:55.57

>>183
そんなUNIXは存在しない。
Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。
MacOS を Unix だと主張するなら、違うかもしれない。解釈次第。

**デフォルトの名無しさん** · 2020/09/26(土) 05:50:51.04

> Unix系の OS は Unicode よりずっと前に複数文字コード対応終わってるので。
それはASCIIと互換性がある文字コードだけ

LinuxはSJISに対応しようと頑張ったやつがあるが
ASCIIと互換性がないので不完全なまま終了した

http://ossforum.jp/jossfiles/Linux_SJIS_Support.pdf
> なぜ Linux で Shift JIS ロケールがサポートされない
> 現在、日本で利用されている多くの Linux ディストリビューションでも、Unicode 系の UTF-8 がデ
> フォルトとされ、Shift JIS ロケールが用意されているケースでも、利用は推奨されていない。

> 1. Ｌｉｎｕｘの文字処理ライブラリ関数は、Unicode を扱うことを基本としているため、本ライブラリ
> 関数を使ってインプリメントされた Linux システムコマンドでは、ファイルデータの中の文字
> 処理や、ファイル名の処理で、Unicode は正しく扱えても、Shift JIS は扱えないことがある。

> 2. Shift JIS データの処理は、「特別」な扱いとなり、メールクライアント Thunderbird など、個々
> のミドルウェアに多大な開発負担を負わせている。

> 3. 特に、正統 Shift JIS ロケール sjis では、 0x5C=U+00A5 というマッピングのために、オープ
> ン系プログラム（Ｃ言語、Java など）の動作が保証されない。cp932 などでは問題ない。

**デフォルトの名無しさん** · 2020/09/26(土) 05:52:24.09

ちなみにWindows NTは最初のバージョンから複数文字コード対応が終わっている
UTF-16（初期はUCS-2）がOSの標準文字コードだからね

**デフォルトの名無しさん** · 2020/09/26(土) 08:35:16.23

その定義だと WindowsNT は ShiftJIS に対応してないんだなこれが。
あくまで対応しているのは CP932 なんだ。
Linux は正しく ShiftJIS を規格書どおりに実装している。
問題は CP932 と ShiftJIS を後出しで別物にしちゃったマイクロソフトにある。
だから Linux でMS互換の文字コードを使いたい場合、ShiftJIS ではなく CP932 と設定する必要がある。

**デフォルトの名無しさん** · 2020/09/26(土) 09:57:54.54

>>190
だからLinuxはCP932に完全対応できずに終わったって言ってるじゃん
話すり替えるなよ

**デフォルトの名無しさん** · 2020/09/26(土) 10:55:23.76

そういえば CP932 は ASCII 互換だったな。
（互換だったということにマイクロソフトがした）

**デフォルトの名無しさん** · 2020/09/26(土) 11:00:49.52

https://shellscript.sunone.me/character_code.html
＞古くから UNIX の日本語環境では EUC-JP が標準の文字コードとして使用されてきた

https://gihyo.jp/lifestyle/serial/01/ganshiki-soushi/0069
＞EUC-JPはUNIX系OSに採用されてワークステーションに，ISO-2022-JP(の前身であるJUNETコード)は電子メールやネットニュースなどインターネットを中心に広まっていきました。

https://codeaid.jp/blog/exchange-utf8/
＞UnixはEUC、WindowsはShift_JIS、MacはMacJapaneseやUTF-8など異なったエンコードタイプでテキストを扱います。

http://www.monyo.com/technical/samba/docs/Japanese-HOWTO-3.0.ja.txt
＞オープンソースの Linux、FreeBSD や、Solaris、IRIX、Tru64 UNIX といった商用 UNIX では、日本語のロケールとして通常 EUC-JP を利用しています

あとどれだけの情報を出せば納得するのかな？ww

**デフォルトの名無しさん** · 2020/09/26(土) 11:16:52.56

>>191
話そらしてるようにしか読めないのなら、それがお前の知識の限界ってやつだ。

**デフォルトの名無しさん** · 2020/09/26(土) 11:18:06.83

>>193
ちなみに Sony の NEWS とか知ってる？

**デフォルトの名無しさん** · 2020/09/26(土) 14:37:10.24

plamoっって久々に観たわ

**デフォルトの名無しさん** · 2020/09/26(土) 15:20:39.47

>>192
マイクロソフトはCP932がASCII互換なんて言ってないよ
それもあってかWindowsではANSIという呼び方をしている

**デフォルトの名無しさん** · 2020/09/26(土) 15:23:26.93

>>194
話をそらしてるのはお前でしょ。Linux および Unix が CP932 または ShiftJIS に対応してないって話なのに
Windowsがー、ShiftJISじゃなくてー、CP932なんだーってWindowsの話にすり替えてる

Linux および Unix の話に戻しましょう。

Linux および Unix が CP932 または ShiftJIS に完全対応してない
>>193にも書いてあるように日本語はASCII互換のEUC-JPを使っていた

**デフォルトの名無しさん** · 2020/09/26(土) 15:35:39.57

AIXはCP932系のCP943がデフォルトだったしSolarisも一応PCKというのを提供していた。
使うコマンド全てちゃんとlocaleに従う国際化していればできる話。

**デフォルトの名無しさん** · 2020/09/26(土) 15:56:41.68

どんどんボロが出るな。
お前のういう ANSI と ASCII の違いって何。
Linux において Shift_JIS と CP932 の違いはわかる？
Sony の NEWS って知ってる？

**デフォルトの名無しさん** · 2020/09/26(土) 15:59:25.33

>>199
IBM の Shift JIS とか教えてやんなよw
にわか君の脳がバグってこれまで以上に面白いことになりそう。

**デフォルトの名無しさん** · 2020/09/26(土) 16:25:27.51

NEWSとX68kは欲しかったな

**デフォルトの名無しさん** · 2020/09/26(土) 16:26:57.63

かつて、シフトJISは皆同じものであった。
その名は様々であったが、人々はシフトJISを使って互いに話し合うことができた。
ほんとは空き領域にメーカー独自に文字を追加してたり、外字領域として使っていたりしたが、同じものと主張していた。

傲慢になった人々はさらに多くの文字を要求した。
お怒りになられた神は Unicode をもたらされた。
各社が勝手気儘に Unicode とシフトJISの変換表を定義したので、ひとつのシフトJISは沢山のシフトJISに分割された。
人々は互いに言葉が通じなくなった。

**デフォルトの名無しさん** · 2020/09/26(土) 16:47:43.71

故・永井一郎氏でナレーションをつけたらガンダムみあってよいね。

**デフォルトの名無しさん** · 2020/09/26(土) 17:05:55.71

>>203
パソコン通信の時代
「文字化け」はノイズでテキストデータが一部壊れることを意味していた
文字化けをなくすしくみとして「MNP」があったけどそれも今では違う意味で使われている

**デフォルトの名無しさん** · 2020/09/26(土) 17:45:01.52

以前、GB18030の話したときの感じだと、素人集団だし、あまり他人のことをとやかく言っても仕方ないのでは。

**デフォルトの名無しさん** · 2020/09/26(土) 21:16:56.96

Why is the default 8-bit codepage called "ANSI"?
https://devblogs.microsoft.com/oldnewthing/20040531-00/?p=39103
Why is the OEM code page often called ANSI?
https://devblogs.microsoft.com/oldnewthing/20051027-37/?p=33593

**デフォルトの名無しさん** · 2020/09/26(土) 21:54:59.76

ｲｲﾈ

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

あんざいでいいのかな

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

あきらめたんじゃなかったのかオヤジ…

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

ANSI の本来の意味は「アメリカ国会標準協会」、日本の JIS にあたる。
一般的な読みは「アンシー」。
もちろん文字コードだけを規定しているのでなくて、色々な規格を決めてる。
でも日本で俗に文字コードのことを JIS って呼ぶ感じで、ANSI って呼んじゃう。
ちなみに ASCII のアメリカ規格での正式な名称は ANSI X3.4 だった。(国際規格だとISO 646 IRV)
Windows の人たちは ASCII だけでなくて ASCII 系の拡張コードを全て ANSI って呼ぶ(ことが多い)。
(もちろん正式名称ではないので、正式なドキュメントでは使用しない)。

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

国会じゃねえ、国家だ、「アメリカ国家標準協会」

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

あまり詳しくないけどShiftJISの規格書とかあるんだな

**デフォルトの名無しさん** · 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以外のまともなソースとやらを出してくれよ
どうせ出せないんだろ？