WindowsはNT3.1の頃からすでにUnicode対応している
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 )())()()())(((()(((()())(((())()))())))()))((()((()))())())()(((())((())(
)()()(()(()()((())()())(((()))))(()))())(()()))(()(((())((()(()))))(()()(
((()()()(()))))(())(()((())))))(((((()((())(())()()())))))()(())(()(((())
)()()))(()()(((((((()(()()((()())((())(()))(()(()()()()(()()))()))())))))
))((((()((())(()())())(()(()))))((((((()))))(((()(()()))))))()(()(())(())
()(()((((((()))))(())())(()))((((()())))(())))()()())))(((()()()())())(((
)(()((((()(())(())(((())((((())))((((())(())(()(())))(()())))())))))(()))
))((((())())(((()())()())((())())((()))))())()(())(()(())(()((()))))(()((
)())((()()))())))()()()))())())()()()((())()(((())(())(()((())())((()((((
)())(()(((()()(((()()))()((()))((((())(()))))()(((()(())))()()))(())(()))
)(()(((()()(()(()))()(()((((()())))()(((())(())())))))()(()(()))(()(())))
(()())(())()()))()())))())))))())())())(((()))(())((((())((())()(((((((((
)(((()()(())())))))(((()(())()))()(((()(()((((()()))(())))()(()(((())))))
))))(((()))()(()(((()(())))))()()))((()()))()()(()((()(())())()())(()((((
(((()(((())))((((())))(()))))(())))())())))()((()((()(()()()))()((())()((
(()()))())((())(()()())(()()))())()()))()(((((())))()(((((())()(()(())())
)(((((((((())))))))((((((()))()())(((()()(((())(())(()))(())))))()))))(()
((((()())))()))(()())())(())))()(()))))((())())(((((()())(((())()(())((()
))))))))((((()((())())())))()(()(()())()())(()))))()((((((())(()(((())(((
()(())())()))))())))((((()))))((())))()())((()())()))(((()(())(((((()((((
)((((()))(()()))()(()))()()()(()((()))()())()((((()(()))(()(())())()(()))
))((())()))((())()()(((())(())))((((()()()())(((((()())((())())()(())))))
)(()()()()))()())()()()()()))())()())())((()((()())())))()((()(((()((()((
())))((()))((((())))))())(())()()(((()())()()(((()))))((())((()()))(((()(
))(()))((((()()))())())()()(()()(()))))(()())(((())())((()(((())())))((((
()))(()()((((((()(()))())())())((())()())(((()))((()()))()))))()))(((()(( >>1
興味深いし、参考になった
プラスモデしちゃう
へぇ、へぇ、へぇ 10でè使ったらエラー出る
外国産のアプリなんだけど HPをS-jisで書かれていい迷惑だったわ。
Unicode読めるならUnicodeで書けよ。
ユーザもS-jisで読めると思ってたアホ多かったから意識も悪かったんじゃね？
いちいち文字コード変換しないといけないから、いい迷惑だったわ。
Unicode普及する前のWEB標準はEUC-JP S-jisじゃない。 > 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言語）で安全に使えるように考慮された
文字コードしか使えない ファイル名についても書いておきますかね？
NTFSは最初からファイル名はUnicode
Unicodeに対応してない古いアプリのために
わざわざ変換してあげているが、それはアプリの問題であり
Unicodeに対応しているアプリは普通にUnicode 機種依存文字使うのがマナー違反だけなのに大げさにMS擁護するバカがいるな。 もう一つ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だけなのである >>12
Unicodeに機種依存文字は存在しない
まあUnicodeはバージョンが有るから、
「最新のUnicode仕様に対応して無くて表示できない文字」はあるがねｗ デマ流すやつを黙らさせるためにわざわざ日本語が含まれるzipを作ってやった。つかgithubだが
https://gist.github.com/anonymous/c329b5f6cc60229a59240b39ca3b3afc
右上のDownload ZIPからzip形式でダウンロードできる。
それをWindows 10のエクスプローラーから開いてみろ
ちゃんと日本語ファイル名も絵文字ファイル名も表示される。
当然だ。ShiftJISになんか変換せずに、Unicodeのまま扱ってるんだからな
ShiftJISでは絵文字なんか使えない！！！だからこれは確実にUnicode（UTF-8）のファイル名だ どこまでがOSでどこからがアプリの事なんだ？？
メモ帳とかコマンドはアプリ？
OSってカーネル部分の話？ >>16
Windowsに日本語版なんてのはないのだから
どの言語にも対応してるよ。
ほとんどはUnicode対応で、一部対応してないのが有るかもしれないけど
その場合「Unicode対応ではないプログラムの言語」の設定に従って動くから
言語を切り替えることができる
ちなみにメモ帳はUnicode対応しているから、UTF-8で保存できる
互換性維持のため初期値は「Unicode対応ではないプログラムの言語」の設定に従う >>18
当時UTF-8自体がないんでできるわけないよｗ
もちろん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を指していることがあるわけです。 ちゃんと2バイト文字処理出来たらいきなりダウン事件は無かったかもな。
当時しらんお子ちゃまか。 >>20
知ってる。鮫島事件のことだろ？
当時を知らん人はぐぐれ DEC出身のカトラーが作ったのでいろいろ先進的なのは当然
最初からX86以外のアーキテクチャへの移植性も考慮されているし
(※その他のCPU自体が普及するかどうかはともかく
NTFSは64ビットアドレスで今でも使えるし。 対応が早すぎた故にUTF-8が使えず
Unicodeを使うにはいちいちwchar系APIを別に用意して
明示的に使わなきゃいけないというクソ実装をせざるを得なかった
今でも引きずってる >>23 だのヲタはしらんだろうが。かなり有名な話ななｄけどね。
>>25
VCならTCHARで普通に書いとけば
マクロで勝手に切り替わるけどな。
#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif
てな具合で そもそも採用が早いかどうかより
Win9xとの互換性のせいだし サロゲとか文字変換が絡むと結局自分で書くことになるから
wchar_t決め打ちでええやんとなる >>18
確かNT3.1はUnipadとおいうユニコード対応のメモ帳が普通のメモ帳とは別アプリに
なっていた希ガス。NT3.5で統合された >>1
一番大事なのはファイル名にユニコードが使えることですよ。
Windowsはそれができないんだよ。 ファイル名に使えないので多言語対応でOSが作れないだよ。
国別にWindowsの作っている。インストーラが国別になっているのはそのせい。
Macだと１つインストーラで全世界対応なので
個別の国版は基本存在しない。
結局バラバラ作っているとローカルなバグは本社に上がらない。
改造して各国版作っているので、コンパネとか英語だと機能順にならんでも
日本語の言語で並び替えを行うので、開いてクリックする直前にアイコンが飛ぶ
おかしな作動をする羽目になる。
Windowsの作りが適当すぎるところがクソなんだよ。
Macのパクリが足りない。 友達から教えてもらった簡単確実稼げる秘密の方法
関心がある人だけ見てください。
グーグルで検索するといいかも『金持ちになりたい 鎌野介メソッド』
GS0MM 友達から教えてもらったネットで稼げる情報とか
興味がある人はどうぞ
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
QT8B8 WindowsはNT3.1の頃からすでにUnicode対応しているのか 対応してない。
ファイルフォーマットとして利用可能は考えていたようだが
実際は日本語の場合Shift-JISオンリー設計なので動かない。
MS-DOS互換が足を引っ張る直接の原因になってる。
いまだに検索がうまくいかないとかはそのあたり いまさらだけど…
https://ao-system.net/note/204
Windows11、Windows10の21H2からファイル名の文字コードの扱いがUTF-8に。
カテゴリー：その他
記事作成日：2022.06.07
まっさらのWindows11を使って気付くとは… だんだん使えなくなるWindowsを持ち上げる連中が知れない Windows 3.1のTTFフォントも内部的にはUnicodeなんだよね 深夜帯からの企画引き継いで
深夜ドラマにアシガールに朝ドラ
めっちゃ美人 ヅラオ滅亡
1番少ないのに体調不良のための帰国なの
もうおっさんが美少女化してもズルズル… 
