Windows Terminal 1.0の登場で加速する脱ShiftJIS。Windowsの完全Unicode化まで残るはzip圧縮のみ
■ このスレッドは過去ログ倉庫に格納されています
0001Ψ
2020/05/28(木) 09:05:15.62ID:sXeDh99Z1992年 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になるのも時間の問題？
0002Ψ
2020/05/28(木) 09:08:56.27ID:q2sjr+3E0003Ψ
2020/05/28(木) 09:11:29.87ID:AXhZVzhl0004Ψ
2020/05/28(木) 09:12:24.67ID:kDPIiOKW0005Ψ
2020/05/28(木) 09:19:03.86ID:+Qwk6JDl生き残れない。つまり
0006Ψ
2020/05/28(木) 09:25:04.85ID:o5J4X600Macはそれで問題になってるよ
Windowsみたいに両対応にすればいいのに
SJISを切り捨てたから、今古いデータを開けなくなってる
0007Ψ
2020/05/28(木) 09:38:16.91ID:rAZzhLQE0008Ψ
2020/05/28(木) 09:53:49.08ID:WE3lxiQPhttp://jzq.elephly.net/ba?k1no5tn4/bs4s3.html
【画像】無防備に乳首ポロリしてるまんさんを見た時の勝ち組感は異常ｗｗｗｗｗｗｗｗｗｗ
http://jzq.elephly.net/bc?bdk/quzan.html
0009Ψ
2020/05/28(木) 10:06:25.30ID:EYsqH63w0010Ψ
2020/05/28(木) 10:15:43.83ID:o5J4X600それは仕方ないだろ
0011Ψ
2020/05/28(木) 10:33:41.08ID:/YqJ6ToAむしろWindows Terminalとかいうのの存在意義がわからんわ
単にシェルをタブで切り替えるだけなんだろ
0012Ψ
2020/05/28(木) 10:38:49.52ID:EYsqH63wアプリが個別にUTF-8に対応する度に騒ぐんだよ
0013Ψ
2020/05/28(木) 10:42:07.17ID:EYsqH63w0014Ψ
2020/05/28(木) 10:42:26.67ID:Tr5ntMb20015Ψ
2020/05/28(木) 12:32:40.13ID:WGyAZfM2ATZ
0016Ψ
2020/05/28(木) 12:47:28.60ID:IwDrN4Cl「私がしてきたことはしつけの範囲を超えたものだと深く反省しております。みーちゃん、本当にごめんなさい」
千葉県野田市で昨年1月、自宅のアパートの浴室で小学4年生だった栗原心愛（みあ）さん（当時10）が虐待を受けて死亡した事件。
心愛さんを虐待の末、死亡させたとして、傷害致死罪などに問われている父親の勇一郎被告（42）に対する裁判員裁判が2月21日、千葉地裁で始まった。
検察官が1つ目の起訴状を読みあげ、前田巌裁判長に認否を聞かれると、「一言申し上げてよろしいでしょうか」と用意した紙を開いた。
「私の気持ちです」。裁判長の許可を得て、書面を読み上げ始めた。
「うわーん、うわーん」心愛さん号泣動画に女性裁判員が泣き出し一時休廷 そのとき父親は……
「娘のために真実を明らかにする」と涙したが……
「娘のためにできることは、この事件にしっかり向き合い、真実を明らかにすることだと思います。知りうる限りの事実をお話ししたいと思います」と涙ながらに反省の弁を述べた。
だが、続いて「罪状認否ですが、暴行について加えたものではありません」と話し、当時小学3年生だった心愛さんが
小学校のアンケートで「お父さんにぼう力を受けています」と虐待を訴えた、2017年11月上旬の暴行については無罪を主張した。
勇一郎被告は17年11月以降、心愛さんが死亡した19年1月24日まで、心愛さんに対する虐待5件と、妻（33）に対するDV（ドメスティック・バイオレンス）1件で起訴されている。
それぞれ起訴状が読まれ、認否を問われたが、次々に虐待を否定した。
18年12月30日から19年1月3日ごろ、心愛さんの両腕をつかんで引きずったり、両腕をひっぱり上げて離し、床に打ち付けたりし、心愛さんの顔に打撲や胸骨の骨折を負わせたとする虐待。
勇一郎被告は「両腕を引きずったり、ひっぱり上げたりしたことは認めます。ですが、床に打ち付けて、顔面や胸部を圧迫・打撃していません。
娘に顔面打撲や胸骨骨折を負わせたことは知りません」と大部分を否定した。
https://headlines.yahoo.co.jp/article?a=20200223-00036263-bunshun-soci
2/23(日) 6:00配信
0017Ψ
2020/05/28(木) 12:48:53.73ID:T3ERjlW/> アプリが個別にUTF-8に対応する度に騒ぐんだよ
対応する度に騒ぐということは、
そういう事例が複数あったということでしょうけど
UTF-8に対応して騒いだという事例を3個ぐらい上げてくれませんか？
0018Ψ
2020/05/28(木) 12:50:11.97ID:T3ERjlW/> UTF-8にしても割と最近までBOMありのを使わせてた邪悪設計だったし
BOMがないと文字化けしやすい
UTF-8とそれ以外の判断をすることが不可能だから
0019Ψ
2020/05/28(木) 13:13:09.20ID:EYsqH63wcl.exeすらオプション指定しないとソースコードはCP932決め打ちだからな
まったくひどいもんだ
0021Ψ
2020/05/28(木) 13:26:24.30ID:EYsqH63w0022Ψ
2020/05/28(木) 13:27:19.12ID:T3ERjlW/という話でしたよね？
ならアプリの問題ですよね
0023Ψ
2020/05/28(木) 13:40:37.52ID:EYsqH63wその仕様に従ってunicodeに対応したすばーらしいアプリは
入力文字列をMultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない
だから入力の文字列をそのまま処理するってアプリがOSのすばらしい設計のために極めて設計しにくく
たとえUTF-8で入力したとしてもMultiByteToWideCharで変換する必要があるクソ仕様なんだ
0024Ψ
2020/05/28(木) 13:42:51.99ID:46ipLv2Iする必要ないぞ？普通に全部Unicodeで作ればいいだけ
0025Ψ
2020/05/28(木) 13:43:33.54ID:46ipLv2I> たとえUTF-8で入力したとしても
入力って？どこからどこへ何を使って入力するの？
意味わかってないでしょお前ｗ
0026Ψ
2020/05/28(木) 13:50:12.97ID:EYsqH63w0027Ψ
2020/05/28(木) 14:23:17.42ID:ZG92R/3bロケールを設定することなく、コンパイルオプションで文字コードを変えていますが？
https://torakichi.hateblo.jp/entry/2017/03/04/152827
0029Ψ
2020/05/28(木) 14:26:35.25ID:EYsqH63wUTF-8に対応する度に騒がれるアプリが自分で見つけられて良かったね
0030Ψ
2020/05/28(木) 14:26:49.13ID:ZG92R/3bロケール関係なくてアプリ（cl.exe）の問題だったということで終わりでは？
なんで結論出たのにもどす必要があるんだｗ
0032Ψ
2020/05/28(木) 14:28:36.91ID:ZG92R/3b0033Ψ
2020/05/28(木) 14:45:54.76ID:EYsqH63whttps://pastebin.com/NSg29UdB
だと日本語環境ではinput.txtがShiftJISでないと文字化けしてしまう
UTF-8で正しく表示するためには
https://pastebin.com/CXAmWrbr
としなければならない
0035Ψ
2020/05/28(木) 14:52:09.21ID:EYsqH63w0036Ψ
2020/05/28(木) 15:11:59.01ID:t/VL06ohほらよ。直してやったで（笑）５ちゃんねるがエラー吐くから一部カタカナ化してるからな
文字コードの変換は内部で勝手にやってくれるんだから
いちいち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;
}
0038Ψ
2020/05/28(木) 15:23:27.78ID:t/VL06oh_setmodeでファイルストリームの読み込みモードを
テキストモードの一種であるUTF-8用の _O_U8TEXTにすればいいだけなんですよ
きっとコード書いたら理解できずに反論もないだろうと思ってんただろうな
今どんな気持ちだろｗｗｗ
0039Ψ
2020/05/28(木) 15:27:20.10ID:EYsqH63w0041Ψ
2020/05/28(木) 15:30:43.55ID:t/VL06oh> 入力文字列をMultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない
> たとえUTF-8で入力したとしてもMultiByteToWideCharで変換する必要があるクソ仕様なんだ
お前が言ったのは「MultiByteToWideCharで変換する必要」があるだろうが
俺が書いたコードには、明示的にUTF-16LEに変換しているコードはない
入力ファイルの文字コードを指定し、WindowsのUnicode対応のAPIを使っただけだ
0043Ψ
2020/05/28(木) 15:32:15.30ID:EYsqH63wファイルの変換モードを設定します。
0044Ψ
2020/05/28(木) 16:30:13.86ID:t/VL06ohShiftJISを含め、どんな文字コードであっても、内部的にはUnicodeに変換してから使ってるに決まってるだろ？
それはLinuxでも同じ。LinuxもUTF-16のファイルを表示したいならUTF-8
もしくは現在のロケールに変換しないといけない
ファイルの文字コードと内部文字コードがともにUTF-8なら変換しなくていいというのなら
WindowsだってともにUTF-16なら変換しなくていい
もう一回聞くぞ？お前がクソだといいたかったのは手動で
「MultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない」
ってことなんだろ？内部で変換されることに関しては当てはまらんだろ
少なくともお前が書いたクソコードより俺のほうがシンプルだ
0045Ψ
2020/05/28(木) 17:57:46.65ID:6TDNf+YY平文で棋譜が書きづらいだろ
あとAA環境は死守な
■ このスレッドは過去ログ倉庫に格納されています