文字コード総合スレ 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/22(火) 03:34:39.51

>>110
意図してUTF-8を作ったんだよ
本来はUnicodeにはUTF-16しか無かった。
外部機関があとから作り出したもの。それがUnicode本家に採用された

**デフォルトの名無しさん** · 2020/09/22(火) 05:08:49.52

UTF8の方がUTF16より歴史が古いよ。
ユニコードが国際規格になる前からある。

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

>>98
NTTDoCoMo・au・Softbankの絵文字の時点でカラーになってたじゃん
互換性を保つために必要

**デフォルトの名無しさん** · 2020/09/22(火) 11:58:02.00

>>112
> UTF8の方がUTF16より歴史が古いよ。
> ユニコードが国際規格になる前からある。

いちいちすぐバレる適当なウソつくんじゃねーよ

https://ja.wikipedia.org/wiki/Unicode#%E6%AD%B4%E5%8F%B2
1991年10月　Unicode 1.0.0 7,161文字　初期バージョン、16ビットの文字コード
1992年6月　Unicode 1.0.1　28,359文字　CJK統合漢字を導入

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/22(火) 12:07:37.87

それは単にカラーで表示していただけで色情報を持っていたわけじゃないだろ。

発端はやっぱり肌色の問題だったらしい。
https://internet.watch.impress.co.jp/docs/special/670150.html

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

ナメック星人用に緑の肌もあるの？

**デフォルトの名無しさん** · 2020/09/22(火) 15:07:13.30

>>114
わかっていないのはお前

UCS-2≠UTF-16

1991年のUnicode 1.0.0の時点ではUnicodeの符号化文字は2バイトのみだったから2バイト固定長符号化
文字集合や符号化方式のUCS-2は当然存在していたが、サロゲートペアを使って1文字を2バイトまたは
4バイトで表現する符号化方式のUTF-16はこの時点では存在していない(存在できない)

Unicode 1.1.0より前にFSS-UTFという名称でファイルシステム安全な符号化方式として現在のUTF-8が
Plan9向けに策定され1993年のUnicode 1.1.0で導入

ttps://www.unicode.org/versions/Unicode1.1.0/appF.pdf

1996年のUnicode 2.0.0でサロゲートペアが導入されたのでサロゲートペアを利用する符号化方式の
UTF-16が概念として登場(まだ概念のみでUTF-16という名称はついていないはず)

ttp://unicode.org/versions/Unicode2.0.0/

FSS-UTFがUTF-2を経てUTF-8という名称になったのは同じくUnicode 2.0.0
ttp://www.unicode.org/versions/Unicode2.0.0/appA.pdf

ISO/IEC 10646としてはUTF-16もUTF-8も1996/10/15発行のAMD 1とAMD 2で策定

**デフォルトの名無しさん** · 2020/09/22(火) 15:35:18.08

>>117
UTF-16という名称はついてないはずとかお前の希望はいらん
証拠もってこいや

**デフォルトの名無しさん** · 2020/09/22(火) 15:37:16.35

> UTF8の方がUTF16より歴史が古いよ。
> ユニコードが国際規格になる前からある。

ユニコードってなにか知ってますか？
Unicode 1.0もユニコードなんですがｗ

**デフォルトの名無しさん** · 2020/09/22(火) 15:37:46.01

さてユニコードが国際規格になる前とはいつのことでしょうかねｗ

**デフォルトの名無しさん** · 2020/09/22(火) 16:12:08.88

TkライブラリがいまだにUCS-2のままなのはなぜなんだぜ？

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

>>98
文字の色が意味を持つトンパ文字なんてのもあるから
どのみち色情報は必要になったんじゃない？

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

utf8の歴史は知らんけど7zやrar5のヘッダの64bit値の可変長は影響されて出てきたもんだと思ってるわ

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

可変長の数値といえばMIDIかなー

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

答え出てるじゃん
UTF8方式が発明されたのは1992年
UTF16方式は1995年
国際規格(ISO)になったのは1996年

**デフォルトの名無しさん** · 2020/09/23(水) 08:26:01.74

Unicode 1.0.0 (October, 1991)
http://www.unicode.org/versions/components-1.0.0.html

**デフォルトの名無しさん** · 2020/09/23(水) 08:34:33.77

Unicodeは業界規格であって国際規格ではない
国際規格なのはISO/IEC 10646で初版は1993年

文字コード関係で専門用語を雑に扱うと議論が混乱するから正確に用語を使え

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

さらに ISO 10646 の 1993 年版は Unicode とは厳密には異なる文字コード規格。
1996年版と Unicode 2.0 で両者が統一された。

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

>>125
UCS-2はUTF-8より前からあったんだが？
話理解してる？UTF-8はUCS-2（UTF-16）で困ったから
外部機関が作り出したものって話をしてる

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

この話

110 名前：デフォルトの名無しさん[] 投稿日：2020/09/22(火) 03:30:53.25 ID:EwzeVKsQ [1/2]
>Unix/Linux系ではC言語の終端文字である\0を避けるためにUTF-8を採用したが

これは違うんじゃまいか
結果的にそうなっただけであって
意図してそうした訳じゃない

111 名前：デフォルトの名無しさん[sage] 投稿日：2020/09/22(火) 03:34:39.51 ID:Ab752W48
>>110
意図してUTF-8を作ったんだよ
本来はUnicodeにはUTF-16しか無かった。
外部機関があとから作り出したもの。それがUnicode本家に採用された

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

> UTF8方式が発明されたのは1992年
当時はUTF8という名前ではなかった。UTF-16と同時につけられた名前
最初はUTF-1という名前があった。
これの改良版としてPlan9が考えたものを採用しUTF-8と名付けた

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

>>124
この板では ruby だろ常考

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

かなり誤解しているやつがいるので業界規格(Unicode)と国際規格(ISO-10646)の反発と協調の歴史をまとめた細い部分は間違ってるかもしれないので、捕捉よろしく。
U: 業界規格(Unicode) およびその源流、I: 国際規格(ISO-10646)およびその源流

U:(0) 1980年、Xerox が独自の統一文字コードを作る
- XCCS: Xerox Character Code Standard
- 16-bit 固定長
- 漢字は日本漢字(JIS X 0208),(この時点で GB2313 とか無かった)
- Unicode とは互換性はないが、アイデアの元となった

I:(1) 1983年、国際標準規格(ISO)として統合文字コードの検討開始
- この時点では 16 bit の文字コードを想定していた

I:(2) 1984年、ISO で統一文字コード用の専用ワーキンググループ設置
- IOO-10646 という番号が決まる

I:(3) 1985年、ISO 10646 の検討案(DP 10646)が出される
- 16 bit で漢字は非統合
- 主に漢字国から拡張性(収容可能な文字数)の不足についてクレームが出る

U:(4) 1987年 Xerox の Becker と Collins が統一文字コードの研究を開始
- これが後の Unicode になる
- 16 bit 固定長で各国の漢字を統合

U:(5) 1989年 Unicode Draft 1 〜 Final Draft が発表される
- 16 bit の文字コードで最大約6万字が収容可能

I:(6) 1990年、ISO-10646 の最初の草案(DIS 10646-1)が発表される
- この時点では Unicode とは全く異なる文字コード
- 16 bit では文字数が明らかに足りないので 32bit 文字コードに
- それに合わせて基本多言語面(BMP)という考え方を導入
(続く)

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

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