「Windows Terminal 1.0」の登場で加速する脱ShiftJIS。Windowsの完全Unicode化まで残るはzip圧縮のみ
引用元: Windows Terminal 1.0の登場で加速する脱ShiftJIS。Windowsの完全Unicode化まで残るはzip圧縮のみ
1992年 Unicode 1.0.1登場 （大部分の漢字に対応）
1993年 UTF-8が公式発表
1993年 Windows NT 3.1 登場
OSとファイルシステムのUnicode（UTF-16の前身であるUCS-2）化が完了
ただし互換性のため、コマンドプロンプトとメモ帳はUnicode対応だが
デフォルトでは（日本語設定では）ShiftJISとなる
2000年 Windows 2000登場
UTF-16（サロゲートペア含む）に完全対応。ただしサロゲートペア対応機能はデフォルトで無効
2000年 Windows Me登場
OSのzip対応。互換性のためファイル名をShiftJISとして格納する
2001年 Windows XP登場
Meと同様にzip対応だがファイル名はShiftJIS
UTF-16のサロゲートペア対応がデフォルトで有効になりOSがUnicode（UTF-16）に完全対応する
2007年 ZIPがUnicode（UTF-8）に正式対応
新仕様なのでこれ以前にファイル名を独自でUTF-8で保存していたものはzipの正しいフォーマットではない
2008年 Unicodeファイル名のzipファイルを展開するためのWindows 7用のパッチが登場
Windows 8以降は標準対応。zipの展開のみUnicode対応が完了
2019年 メモ帳のデフォルトの文字コードがUnicode（UTF-8）となりUnicode完全対応が完了
2020年 Windows Terminal が登場しUnicodeに完全対応が完了
現在
○ OSとファイルシステム・・・NT当初からUnicode完全対応完了
○ メモ帳・・・デフォルトがUnicode（UTF-8）になることでUnicode完全対応完了
○ コマンドプロンプト・・・Windows Terminalに置き換わることでUnicode完全対応完了
○ zipファイル展開・・・Windows7用パッチ以降Unicode完全対応完了
× zipファイル圧縮・・・未対応（これだけ！）
Unicodeファイル名のzipに対応していないWindows 7のサポートが終わったので
zip圧縮時の文字コードがUTF-8になるのも時間の問題？
生き残れない。つまり
Macはそれで問題になってるよ
Windowsみたいに両対応にすればいいのに
SJISを切り捨てたから、今古いデータを開けなくなってる
それは仕方ないだろ
むしろWindows Terminalとかいうのの存在意義がわからんわ
単にシェルをタブで切り替えるだけなんだろ
おすすめ記事
アプリが個別にUTF-8に対応する度に騒ぐんだよ
> アプリが個別にUTF-8に対応する度に騒ぐんだよ
対応する度に騒ぐということは、
そういう事例が複数あったということでしょうけど
UTF-8に対応して騒いだという事例を3個ぐらい上げてくれませんか？
> UTF-8にしても割と最近までBOMありのを使わせてた邪悪設計だったし
BOMがないと文字化けしやすい
UTF-8とそれ以外の判断をすることが不可能だから
ATZ
cl.exeすらオプション指定しないとソースコードはCP932決め打ちだからな
まったくひどいもんだ
それOSの問題じゃないですよね
ロケール関係なくてアプリ（cl.exe）の問題だったということで終わりでは？
なんで結論出たのにもどす必要があるんだｗ
という話でしたよね？
ならアプリの問題ですよね
その仕様に従ってunicodeに対応したすばーらしいアプリは
入力文字列をMultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない
だから入力の文字列をそのまま処理するってアプリがOSのすばらしい設計のために極めて設計しにくく
たとえUTF-8で入力したとしてもMultiByteToWideCharで変換する必要があるクソ仕様なんだ
> たとえUTF-8で入力したとしても
入力って？どこからどこへ何を使って入力するの？
意味わかってないでしょお前ｗ
する必要ないぞ？普通に全部Unicodeで作ればいいだけ
面白い人だよね
変換してないぞ？
Unicode対応APIを使ってるだけ
UTF-8に対応する度に騒がれるアプリが自分で見つけられて良かったね
おじいちゃん。今はもう2020年ですよ？
https://pastebin.com/NSg29UdB
だと日本語環境ではinput.txtがShiftJISでないと文字化けしてしまう
UTF-8で正しく表示するためには
https://pastebin.com/CXAmWrbr
としなければならない
ようはテキストエディタが複数の文字コードに対応しているかどうかの話でしょう？
OSのロケールと関係ない
ほらよ。直してやったで（笑）５ちゃんねるがエラー吐くから一部カタカナ化してるからな
文字コードの変換は内部で勝手にやってくれるんだから
いちいちMultiByteToWideCharとか使うなや
お前がヘボなだけや
#define _CRT_SECURE_NO_WARNINGS 1
#include <windows.h>
#include <stdio.h>
#include <fcntl.h>
#include <io.h>
int メイン(void)
{
FILE* fp = fオープン(“input.txt”, “r”);
wchar_t bufw[64];
_setmode(_fileno(fp), _O_U8TEXT);
fgetws(bufw, 64, fp);
fクローズ(fp);
MessageBoxW(NULL, bufw, NULL, MB_OK);
return 0;
}
_setmodeでファイルストリームの読み込みモードを
テキストモードの一種であるUTF-8用の _O_U8TEXTにすればいいだけなんですよ
きっとコード書いたら理解できずに反論もないだろうと思ってんただろうな
今どんな気持ちだろｗｗｗ
> 入力文字列をMultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない
> たとえUTF-8で入力したとしてもMultiByteToWideCharで変換する必要があるクソ仕様なんだ
お前が言ったのは「MultiByteToWideCharで変換する必要」があるだろうが
俺が書いたコードには、明示的にUTF-16LEに変換しているコードはない
入力ファイルの文字コードを指定し、WindowsのUnicode対応のAPIを使っただけだ
ファイルの変換モードを設定します。
ShiftJISを含め、どんな文字コードであっても、内部的にはUnicodeに変換してから使ってるに決まってるだろ？
それはLinuxでも同じ。LinuxもUTF-16のファイルを表示したいならUTF-8
もしくは現在のロケールに変換しないといけない
ファイルの文字コードと内部文字コードがともにUTF-8なら変換しなくていいというのなら
WindowsだってともにUTF-16なら変換しなくていい
もう一回聞くぞ？お前がクソだといいたかったのは手動で
「MultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない」
ってことなんだろ？内部で変換されることに関しては当てはまらんだろ
少なくともお前が書いたクソコードより俺のほうがシンプルだ
平文で棋譜が書きづらいだろ
あとAA環境は死守な
勉強になります
『「Windows Terminal 1.0」の登場で加速する脱ShiftJIS。Windowsの完全Unicode化まで残るはzip圧縮のみ』へのコメント