WindowsはNT3.1の頃からすでにUnicode対応している

1名無し~3.EXE2018/01/09(火) 21:58:14.71ID:4bQ5N08X
Unicode対応というのは、UTF-8、UTF-16、UTF-32のいずれかが使われているということ
(他にUCS-2やUCS-4など今は殆ど使われていないものも有るが省略)

WindowsはNT3.1のころからUCS-2、Windows 2000からはUTF-16に対応している。
なぜUCS-2なのか?というとUTF-8もUTF-16も当時は存在していなかったから
つまりWindowsはかなり早い時期にとっくにUnicode対応をしている

■Windows は Shift-JISじゃなかったの!?
違う。一番わかり易い話をするならば、Shift-JISは日本語専用。言うまでもなくWindowsは多言語対応。
外国で日本語専用の文字コードが使われているわけがない。もう一つの例はファイル名に
「白抜きのハート」が使えることからも明らかにわかる。これはShift-JISにはなくUnicodeにしかない文字

どうしてこのような勘違いをする愚か者がいるのかというと、Unicodeに対応していない古いアプリの話をしてるから
Unicodeに対応していない古いアプリの互換性を維持するため(さすがWindowsの互換性は高い!!!)に、
「Unicode対応ではないプログラムの言語」の設定が日本語になっている
https://121ware.com/qasearch/1007/app/servlet/relatedqa?QID=019795
もちろんUnicode対応のアプリではUnicodeが使われる。だからWindowsはUnicode対応で、Shift-JISなのはアプリの問題
古いアプリを切りしてたら困るだろう?ちゃんとWindowsは対応してる。

■ 歴史
1991年10月 Unicode 1.0 (UCS-2登場 最大65,536文字)
1993年07月 Windows NT3.1 リリース (UCS-2対応)
1996年07月 Unicode 2.0 (UTF-16登場 最大1,048,576文字)
1996年09月 Windows NT3.5 リリース
1996年10月 ISO/IEC 10646-1:1993/Amd.1制定 Transformation Format for 16 planes of group 00 (UTF-16)
1996年10月 ISO/IEC 10646-1:1993/Amd.2制定 UCS Transformation Format 8 (UTF-8)
2000年02月 Windows 2000 リリース

■ 参考
https://ja.wikipedia.org/wiki/Microsoft_Layer_for_Unicode
https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows
https://ja.wikipedia.org/wiki/ISO/IEC_10646

2名無し~3.EXE2018/01/09(火) 22:11:55.06ID:Zy0M0o9c
無茶苦茶やな

3名無し~3.EXE2018/01/09(火) 22:12:18.95ID:SLxp5F27
)())()()())(((()(((()())(((())()))())))()))((()((()))())())()(((())((())(
)()()(()(()()((())()())(((()))))(()))())(()()))(()(((())((()(()))))(()()(
((()()()(()))))(())(()((())))))(((((()((())(())()()())))))()(())(()(((())
)()()))(()()(((((((()(()()((()())((())(()))(()(()()()()(()()))()))())))))
))((((()((())(()())())(()(()))))((((((()))))(((()(()()))))))()(()(())(())
()(()((((((()))))(())())(()))((((()())))(())))()()())))(((()()()())())(((
)(()((((()(())(())(((())((((())))((((())(())(()(())))(()())))())))))(()))
))((((())())(((()())()())((())())((()))))())()(())(()(())(()((()))))(()((
)())((()()))())))()()()))())())()()()((())()(((())(())(()((())())((()((((
)())(()(((()()(((()()))()((()))((((())(()))))()(((()(())))()()))(())(()))
)(()(((()()(()(()))()(()((((()())))()(((())(())())))))()(()(()))(()(())))
(()())(())()()))()())))())))))())())())(((()))(())((((())((())()(((((((((
)(((()()(())())))))(((()(())()))()(((()(()((((()()))(())))()(()(((())))))
))))(((()))()(()(((()(())))))()()))((()()))()()(()((()(())())()())(()((((
(((()(((())))((((())))(()))))(())))())())))()((()((()(()()()))()((())()((
(()()))())((())(()()())(()()))())()()))()(((((())))()(((((())()(()(())())
)(((((((((())))))))((((((()))()())(((()()(((())(())(()))(())))))()))))(()
((((()())))()))(()())())(())))()(()))))((())())(((((()())(((())()(())((()
))))))))((((()((())())())))()(()(()())()())(()))))()((((((())(()(((())(((
()(())())()))))())))((((()))))((())))()())((()())()))(((()(())(((((()((((
)((((()))(()()))()(()))()()()(()((()))()())()((((()(()))(()(())())()(()))
))((())()))((())()()(((())(())))((((()()()())(((((()())((())())()(())))))
)(()()()()))()())()()()()()))())()())())((()((()())())))()((()(((()((()((
())))((()))((((())))))())(())()()(((()())()()(((()))))((())((()()))(((()(
))(()))((((()()))())())()()(()()(()))))(()())(((())())((()(((())())))((((
()))(()()((((((()(()))())())())((())()())(((()))((()()))()))))()))(((()((

4名無し~3.EXE2018/01/10(水) 00:04:12.86ID:docvWLOJ
>>1
興味深いし、参考になった
プラスモデしちゃう

へぇ、へぇ、へぇ

5名無し~3.EXE2018/01/10(水) 01:12:02.30ID:4DItnmUK
10でè使ったらエラー出る
外国産のアプリなんだけど

6名無し~3.EXE2018/01/10(水) 18:41:34.13ID:fZ3RBTPj
骨がきちんと書けないなんてネタにしてたよな

7名無し~3.EXE2018/01/11(木) 01:43:23.04ID:k2x9wF8/
HPをS-jisで書かれていい迷惑だったわ。
Unicode読めるならUnicodeで書けよ。

ユーザもS-jisで読めると思ってたアホ多かったから意識も悪かったんじゃね?
いちいち文字コード変換しないといけないから、いい迷惑だったわ。

Unicode普及する前のWEB標準はEUC-JP S-jisじゃない。

8名無し~3.EXE2018/01/11(木) 04:52:34.14ID:MMO09KO4
> Unicode普及する前のWEB標準はEUC-JP S-jisじゃない。

何故かと言うとLinuxのせい
Linuxのカーネルは主にC言語で作られている
多くのアプリも直接的 または 間接的にC言語で
作られているものを利用している。だからC言語のせいとも言える

C言語では文字列は、NULL文字(文字コード0)で終わる
バイトの並びになっている。他の言語では、文字列の長さ情報+文字のバイト列 に
なっているものがあるがC言語ではそうではない。

これが何を意味するかというと、文字列を表現するバイト列にNULL文字を含められないということ
よってUTF32やUTF16はLinuxで扱うのが難しい。多バイト文字に考慮しないといけない
またC言語では、文字列の中の\マークは特殊な意味を持つため、
文字列の中に\と同じ文字コードを使うことができない、Shift-JISはこれに当てはまる

このようにLinux(C言語)ではカーネルが対応できる文字コードがWindowsよりも少ない。
EUC-JPやUTF-8のようにLinux(C言語)で安全に使えるように考慮された
文字コードしか使えない

9名無し~3.EXE2018/01/11(木) 14:46:21.59ID:8ypuLgoW
なんで急にWWWの話ししてんだ?

10名無し~3.EXE2018/01/11(木) 21:09:35.73ID:UlETQoiU
まーNTは対応していたよな。
限定的ではあったが

11名無し~3.EXE2018/01/13(土) 00:54:39.31ID:LEYBcoWj
ファイル名についても書いておきますかね?

NTFSは最初からファイル名はUnicode
Unicodeに対応してない古いアプリのために
わざわざ変換してあげているが、それはアプリの問題であり
Unicodeに対応しているアプリは普通にUnicode

12名無し~3.EXE2018/01/13(土) 00:56:28.16ID:0eoFBSR4
機種依存文字使うのがマナー違反だけなのに大げさにMS擁護するバカがいるな。

13名無し~3.EXE2018/01/13(土) 01:15:29.34ID:LEYBcoWj
もう一つzipの話についても書いておきますか

これはもうOSは全く関係ない。
zipという形式をどう扱うかの話

まず前提として初期のzipは文字コードは特に決まっていなかった。
だからASCIIコードを入れてもShiftJISを入れてもUnicodeを入れても
仕様上は問題なし。その場合、圧縮したときと展開する時とで
同じ文字コードを前提としていなければ文字化けが起きる

繰り返すがこれはOSは全く関係ない話
zipというファイルフォーマット自体の問題

後にzipにはUnicode(UTF-8)ファイル名の仕様が追加された。2006年の事だ。
(XPが2001年、Vistaが2006年、7が2009年にそれぞれリリースされている)
https://en.wikipedia.org/wiki/Zip_(file_format)#Version_history
> 6.3.0: (2006)[15] Documented Unicode (UTF-8) filename storage. Expanded list of supported hash, compression (LZMA, PPMd+), encryption algorithms.

これを受けてWindows 7用にUTF-8ファイル名の仕様に対応するためのパッチがでている
https://support.microsoft.com/ja-jp/help/2704299/japanese-characters-in-file-names-are-displayed-as-garbled-text-after
これを適用していれば、UTF-8で格納されている場合は、UTF-8ファイル名として展開することができる(Windows 8以降は標準対応)

ただしzipファイルを作成するときは「Unicode対応ではないプログラムの言語」の設定が使われる
Windowsは互換性を大切にしているのでWindows 7以前、もしくは7でパッチを当てていない人でも正しく展開できるようにしている。

端的にいうならばWindows7+パッチ以降であれば(同一言語の)Windowsで作成されたzipもMacOSで作成されたzipも
正しく展開できる。そしてWindowsで作成されたzipなら、展開PCが古くても(同一言語)のWindowsなら正しく展開できる。
それに対してMacOSで作成されたzipはUTF-8限定なので、古いWindowsだと文字化けを起こしてしまう。(新しいWindowsなら問題ない)
そしてWindowsで作成されたzipはMacOSでは対応してるソフトを使わない限り文字化けを起こしてしまう。
つまり最新の環境でzip内のファイル名の文字化けで苦しまむのはMacOSだけなのである

14名無し~3.EXE2018/01/13(土) 01:19:14.74ID:LEYBcoWj
>>12
Unicodeに機種依存文字は存在しない

まあUnicodeはバージョンが有るから、
「最新のUnicode仕様に対応して無くて表示できない文字」はあるがねw

15名無し~3.EXE2018/01/13(土) 03:01:06.48ID:LEYBcoWj
デマ流すやつを黙らさせるためにわざわざ日本語が含まれるzipを作ってやった。つかgithubだが

https://gist.github.com/anonymous/c329b5f6cc60229a59240b39ca3b3afc

右上のDownload ZIPからzip形式でダウンロードできる。
それをWindows 10のエクスプローラーから開いてみろ
ちゃんと日本語ファイル名も絵文字ファイル名も表示される。
当然だ。ShiftJISになんか変換せずに、Unicodeのまま扱ってるんだからな
ShiftJISでは絵文字なんか使えない!!!だからこれは確実にUnicode(UTF-8)のファイル名だ

16名無し~3.EXE2018/01/13(土) 20:29:39.12ID:hhvBNPzv
どこまでがOSでどこからがアプリの事なんだ??
メモ帳とかコマンドはアプリ?
OSってカーネル部分の話?

17名無し~3.EXE2018/01/13(土) 22:16:27.85ID:LEYBcoWj
>>16
Windowsに日本語版なんてのはないのだから
どの言語にも対応してるよ。

ほとんどはUnicode対応で、一部対応してないのが有るかもしれないけど
その場合「Unicode対応ではないプログラムの言語」の設定に従って動くから
言語を切り替えることができる

ちなみにメモ帳はUnicode対応しているから、UTF-8で保存できる
互換性維持のため初期値は「Unicode対応ではないプログラムの言語」の設定に従う

18名無し~3.EXE2018/01/14(日) 21:05:49.46ID:DPPGMZMU
NT3.1のメモ帳って、UTF-8で保存できた?

19名無し~3.EXE2018/01/15(月) 00:13:38.41ID:hHi/BS9j
>>18
当時UTF-8自体がないんでできるわけないよw

もちろんUnicode対応はしてる。その時に使えるエンコードはOS標準でもあるUTF-16だろう
(当時はサロゲートペアも存在しなかったのでUCS-2というべきかな?)



ちょっと調べていて面白いものを見つけた
http://yanok.net/2016/03/utf-16-unicode.html

> ちなみにUnicode 8.0仕様書ではUTF-16の "origin" について、
> 「UTF-16 is the historical descendant of the earliest form of Unicode,
> which was originally designed to use a fixed-width, 16-bit encoding
> form exclusively.」(2.5 Encoding Forms)と説明されています。
>
> なので前世紀に書かれた文書やプログラムでは「Unicode = UCS-2」という前提があり、
> それを漫然と引き継いでいると、「Unicode」と言っているのが実質的にはUTF-16を指していることがあるわけです。

20名無し~3.EXE2018/01/15(月) 22:13:53.58ID:J6cKFvH5
ちゃんと2バイト文字処理出来たらいきなりダウン事件は無かったかもな。
当時しらんお子ちゃまか。

21名無し~3.EXE2018/01/15(月) 23:33:47.57ID:hHi/BS9j
>>20
知ってる。鮫島事件のことだろ?
当時を知らん人はぐぐれ

22名無し~3.EXE2018/01/16(火) 02:27:25.59ID:F2Ozkn/8
ちがうがな

23名無し~3.EXE2018/01/16(火) 02:53:15.42ID:82oKdAtX
どっちも事件がないという点で同じ

24名無し~3.EXE2018/01/16(火) 09:58:55.57ID:UMYEkyg1
DEC出身のカトラーが作ったのでいろいろ先進的なのは当然

最初からX86以外のアーキテクチャへの移植性も考慮されているし
(※その他のCPU自体が普及するかどうかはともかく

NTFSは64ビットアドレスで今でも使えるし。

25名無し~3.EXE2018/01/16(火) 11:59:06.27ID:ZZe1BxCe
対応が早すぎた故にUTF-8が使えず
Unicodeを使うにはいちいちwchar系APIを別に用意して
明示的に使わなきゃいけないというクソ実装をせざるを得なかった
今でも引きずってる

26名無し~3.EXE2018/01/16(火) 19:06:42.06ID:F2Ozkn/8
>>23  だのヲタはしらんだろうが。かなり有名な話ななdけどね。


   
    

27名無し~3.EXE2018/01/16(火) 19:50:02.46ID:Ntl3m0Zg
>>25
VCならTCHARで普通に書いとけば
マクロで勝手に切り替わるけどな。

#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif

てな具合で

28名無し~3.EXE2018/01/16(火) 19:51:26.23ID:Ntl3m0Zg
そもそも採用が早いかどうかより
Win9xとの互換性のせいだし

29名無し~3.EXE2018/01/21(日) 01:47:43.12ID:7FGaETO4
(・∀・)ニヤニヤ

30名無し~3.EXE2018/01/21(日) 13:22:52.67ID:6zsbXn/3
サロゲとか文字変換が絡むと結局自分で書くことになるから
wchar_t決め打ちでええやんとなる

新着レスの表示
レスを投稿する