文字コード総合スレ 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/23(水) 12:41:36.26

U:(7) 1991年、業界団体として The Unicode Consortium が結成
- Unicode を業界共通規格にすることを目指す業界団体
- 初期メンバーは Xerox, Apple, IBM, Microsoft, など

U:(8) 1991年、The Unicode Consortium によって Unicode 1.0 vol.1 が策定
- 16ビット固定長文字コード
- 厳密にいえば結合文字とかあるので可変長だけど、約6万字しか実装できない

I:(9) 1992年、 ISO-10646 の第二の草案(DIS 10646-2)が発表
- 改良して Unicode と親和性を高くしたもの
- 31bit 文字コード (UCS: Universal Coded Character Set)
- 基本多言語面(BMP)に Unicode をそのまま採用
- 基本は4バイト文字コードとして実装(UCS-4 と命名)
- Unicode 部分(当時)のみの 2バイトの実装水準も許可(UCS-2 と命名)

I:(10) 1992年、UCS-4 の ASCII との互換性のある可変長符号化方式が考案
- UCS Transfomation Format (UTF)と呼ばれ、後に UTF-1 と呼ばれる

I:(11) 1992年、Plan9/Unix のファイルシステムで使用できる別の UTF が考案
- File System Safe UTF と名付けられ、UTF-2 とも呼ばれる。
- これが後に UTF-8 と呼ばれるようになる

I:(12) 1993年、ISO/IEC 10646-1:1993 が正式に国際規格化
- BMP に Unicode 1.1 を採用しているため Unicode の上位互換
- あくまで 31bit の文字コード規格で、16 bit の Unicode とは別の文字規格
- Unicode側へも 32bitへの拡張を打診したが領域を食い過ぎといって断わられた
- UTF-1 は規格の付録に採用されているが、UTF-8 はまだ採用されてない
(続く)

**デフォルトの名無しさん** · 2020/09/23(水) 12:43:30.64

U:(13) 1995年、サロゲートペアの考案
- Unicode 側でもあいつぐ文字の追加要求で 16 bit では破綻することが明らかに
- 現行の 2バイト方式と互換性のある拡張方式が必要
- これが後に UTF-16 と呼ばれる

X:(14) 1995年、Unicode と ISO で協調していくことに合意
- BMP 以外の面も Unicode と ISO-10646 で同じ文字を採用する
- 最大文字数はサロゲートペアで表現可能な 16面までとする

U:(15) 1996年、Unicode2.0 を発表
- 2面以降を採用
- 2面以降を符号化にサロゲートペア(UTF-16)方式を採用
- UTF-8 方式も付録A にて記載

I:(16) 1996年、ISO-10646 を追補(Amendment)で改訂
- あくまで 31 bit だが 17面以降を永久に実装しないことに
- (13)の方式を UTF-16 という名前で採用(Amd1)
- (11)の方式を UTF-8 という名前で採用(Amd2)
- UTF-1 を廃止
- その他文字の追加/変更の追補によって Unicode 2.0 と完全互換に

その後も協調しながらアップデート
(以上)

**デフォルトの名無しさん** · 2020/09/23(水) 12:50:04.51

>補足よろしく

わろす

**デフォルトの名無しさん** · 2020/09/23(水) 12:51:35.74

つまり>>106は正しいということ

> Unicodeの当初の目標でも16bit固定＝C言語の終端文字である\0が1文字の中に
> 含まれる事があるので、文字はUnicodeとして扱わなければいけないことが決定していた。

> Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが
> 可変長バイトだから、これもUnicodeとして扱わなければいけない。

**デフォルトの名無しさん** · 2020/09/23(水) 13:42:18.16

>>137
厳密には違う。
UTF-1 の時点で 0x00 は入らないくて C言語で使用可能。
でも / が 2バイト目以降にが入ってるので Unix 等のファイルシステムで使えない欠点があった。
これを改良するために考案されたのが FSS-UTF (UTF-2)、のちに UTF-8 と命名。

**デフォルトの名無しさん** · 2020/09/23(水) 13:50:08.66

>>137
業界規格としてのUnicodeは符号化方式（今のUTF-16）について，
Cやシェルのことを考えていなかったけど，
それが国際標準になる時に，
符号化方式の一つとしてUTF-8を採用してCやシェルを考慮した，
ってこと？

**デフォルトの名無しさん** · 2020/09/23(水) 13:59:02.67

重要なのは FSS-UTF (後のUTF-8) は 16 bit の業界 Unicode を符号化するために考案されたのではなくて、31 bit の国際規格 UCS-4 を符号化するために考案されたということ。
その後、Unicode が 17 bit 以上に拡張される時にサロゲートペアが考案されて、それを国際規格側では UTF-16 と名付けた。
だから UTF-8 にサロゲートペア入れるやつは×ね。

**デフォルトの名無しさん** · 2020/09/23(水) 15:18:09.77

ルーピー儲であふれてるスレ

**デフォルトの名無しさん** · 2020/09/23(水) 20:40:55.14

>>125
で、UTF-8が国際標準に入ったのは何時なの？
なんで開発された年と標準化された年を比較してるの？

**デフォルトの名無しさん** · 2020/09/24(木) 01:15:56.19

>>142
だれもそんな比較してない。よく読め
UTF8方式が提案された年とUTF16方式が提案された年を比較してる。

**デフォルトの名無しさん** · 2020/09/24(木) 01:22:18.61

>>143
え？なんでそんな話してるの？
それの何が重要なの？

**デフォルトの名無しさん** · 2020/09/24(木) 01:26:57.76

UTF16がUCS2と違うというのなら、サロゲートペアの話でもしてるんだろうが
サロゲートペアが登場してるなら16bitでは収まらないと諦めた後であるということ
だからUCS4がすでに登場している
そしてUCS4があるからこそ、UTF-8からUCS4に変換するロジックを作ることができる
つまりUTF-8があるなら、UCS4がありUTF-16もあったことになる

**デフォルトの名無しさん** · 2020/09/24(木) 01:48:26.24

>>145
何？その超理論、詳しく教えて？
どうやったらサロゲートペアより前に UTF16が存在できるの？
どの規格書に書いてある用語使ってるの？

**デフォルトの名無しさん** · 2020/09/24(木) 08:50:32.68

>>112 のツッコミ方が完全に間違ってるんだよな。
Unicodeには16bitエンコーディングしかなかったところに
後から8bitエンコーディングが追加されたって話なんだから
そこでツッコむべきはUTF-16という用語を使うのが間違っているという点。
それなのにあさっての方向にツッコむもんだから話がこじれる。

**デフォルトの名無しさん** · 2020/09/24(木) 09:22:54.19

>>147
だから、それも違うんだ。
Unicode に固定長エンコーディングしか無かったのは正しい。
一方で UTF-8 は Unicode のために作られらのでは無くて国際規格の UCS-4 のために作られた。
その後に Unicode と国際規格が事実上統合された。

**デフォルトの名無しさん** · 2020/09/24(木) 10:38:14.21

UTFがUCSにTransformするフォーマットの略って知らないのかな？

**デフォルトの名無しさん** · 2020/09/24(木) 11:57:01.94

>>149
細かいこ指摘だけど UCS に Tranmsform するのではなくて、UCS から Transform がより正確だよ。

**デフォルトの名無しさん** · 2020/09/24(木) 12:55:17.64

簡単な用語定義 (※元々は ISO における用語、後に Unicode にも取り入れられた)
ユニコード・コンソーシアムが定めている文字コードを「Unicode」という
国際規格委員会が ISO-10646 で定めている文字コードを「UCS」という
国際規格 UCS を 32 bit 固定長で符号化したものを「UCS-4」と呼ぶ
国際規格 UCS の BMP だけを 16 bit 固定長で符号化した簡易実装を「UCS-2」と呼ぶ(後に廃止)
第一次国際規格(1993年)の付録に定められた UCS の 8-bit 可変長符号化を「UTF」(UCS 変形フォーマットの意味)と呼ぶ(後に廃止)
国際規格の追補(1996年)で追加された UCS の 8-bit 可変長符号化を「UTF-8」と呼ぶ
国際規格の追補(1996年)で追加された UCS のサロゲートペアを用いた 16-bit 可変長フォーマットを「UTF-16」と呼ぶ

備考
UCS-2 は Unicode 1.1 とほぼ互換になるように定められた
UTF-16 は Unicode 2.0 (サロゲートペア有)と互換になるように定められた
後に定められた「UTF-32 」と UCS-4 は実質的に同じもの
UTF は UTF-8 と区別するために UTF-1 と呼ばれるようになった
UTF-8 は規格化される前は FSS-UTF とか UTF-2 などと呼ばれていた

**デフォルトの名無しさん** · 2020/09/24(木) 13:18:02.55

以上の用語定義で UTF-8 導入の経緯は

Unicode はもともと内部 16 bit、外部 16 bit の使用法を前提にしていたが、国際規格では内部 32 bit、外部 8 bit可変長で実装することも想定していた。

このための外部用 8 bit 可変長文字コードとして最初に提案されたのが、UTF (UTF-1) 方式。

だだこの UTF-1 方式は Unix のファイル名等に使えないという欠点があっったので、すぐに改良版の FSS-UTF (UTF-8) 方式が提案され、そっちで実装が進んだ。

第一次規格(1993年)では時間的に変更が間に合わなくて UTF-1 方式の方が規格書の付録に記載されたが、後から追補(1996年)によって UTF-1 方式と UTF-8 方式を入れ換えた。

**デフォルトの名無しさん** · 2020/09/24(木) 20:34:57.66

UTF-8の祖先にUTF-1があるから歴史が古いんだと言えるなら、同じ論理で
UTF-16の祖先にUCS-2を直接使用する原ユニコードがあるとも言えるんじゃね？

**デフォルトの名無しさん** · 2020/09/24(木) 23:00:01.78

UTF-1 があるから歴史が古いなんて言ってる人いないけど、どこ見てるの。
UTF-1 のすぐ後に UTF-8 が提案されてて間は1年もないよ。寝惚けてるの？

**デフォルトの名無しさん** · 2020/09/24(木) 23:04:21.45

論点はそこじゃなくてUTF-8はUnix系でUTF-16に対応できなかったから
しかたなく作ったものだって話だろ
外部が作って後からUnicodeに追加された仕様

**デフォルトの名無しさん** · 2020/09/24(木) 23:19:57.03

あきらめろ。
UTF-8 は Unicode ではなく UCS 用に作られた。
UTF-8 は欠陥のある UTF−1 の代わりにするために作られた。
UTF-8 が考案された時には UTF-16 は影も形も無かった。

**デフォルトの名無しさん** · 2020/09/24(木) 23:22:52.82

>>155
だから、それが間違いって指摘してるんだが

**デフォルトの名無しさん** · 2020/09/24(木) 23:31:22.25

>>157
UTF-8が開発された経緯

https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

> UTF-8 was designed, in front of my eyes, on a
> placemat in a New Jersey diner one night in September or so 1992.
UTF-8は1992年9月に私の目の前で設計された

> We had used the original UTF from ISO 10646
> to make Plan 9 support 16-bit characters, but we hated it.
Plan 9で16ビット文字をサポートするためにISO 10646の
オリジナルのUTFを使用していたが私たちはそれを嫌っていました。

> 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(金) 01:42:25.42

>>158
そこに書かれている original UTF というのは UTF-1 のことで UTF-16 のことじゃないぞ。
ちゃんと理解できてるか？

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

だからUnicodeに対応するためにUCS-2ではなくてUTF-1を使ってたんだろ
UnixがUCS-2に対応するのは現実的に不可能だったから

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

>>156
> UTF-8 が考案された時には UTF-16 は影も形も無かった。

UTF16の直接の先祖のUnicode1.0の符号化方式が厳然と存在してるのに影も形もないはないな

**デフォルトの名無しさん** · 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年のようだ