おすすめ記事

「Windows Terminal 1.0」の登場で加速する脱ShiftJIS。Windowsの完全Unicode化まで残るはzip圧縮のみ

引用元: Windows Terminal 1.0の登場で加速する脱ShiftJIS。Windowsの完全Unicode化まで残るはzip圧縮のみ


画像引用元:ターミナルソフトTera Termガイドブック | Amazon

Sponsored Link

1: 名無しさん 2020/05/28(木) 09:05:15.62 ID:sXeDh99Z
1991年 Unicode 1.0.0登場(よく使われる漢字のみ対応)
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になるのも時間の問題?

2: 名無しさん 2020/05/28(木) 09:08:56.27 ID:q2sjr+3E
よく調べたな スゲーわ

3: 名無しさん 2020/05/28(木) 09:11:29.87 ID:AXhZVzhl
俺はバカなので全然わからん

4: 名無しさん 2020/05/28(木) 09:12:24.67 ID:kDPIiOKW
まあ統一してくれた方がいいんだろうってのは分かる

5: 名無しさん 2020/05/28(木) 09:19:03.86 ID:+Qwk6JDl
古いデータは規格が違うから読めませんなんてシステムは
生き残れない。つまり

6: 名無しさん 2020/05/28(木) 09:25:04.85 ID:o5J4X600
>>5
Macはそれで問題になってるよ
Windowsみたいに両対応にすればいいのに
SJISを切り捨てたから、今古いデータを開けなくなってる

7: 名無しさん 2020/05/28(木) 09:38:16.91 ID:rAZzhLQE
変換ソフトありゃいいんだろ?

9: 名無しさん 2020/05/28(木) 10:06:25.30 ID:EYsqH63w
unicode対応にUTF-8じゃなくUTF-16LEなAPIを明示的に使わせるセンスのない設計だから未だにShiftJISのファイル名しか扱えないアプリが残ってる

10: 名無しさん 2020/05/28(木) 10:15:43.83 ID:o5J4X600
UTF-8ができた時期が遅かったから
それは仕方ないだろ

11: 名無しさん 2020/05/28(木) 10:33:41.08 ID:/YqJ6ToA
メモ帳のデフォの文字コードがUTF-8になってけっこう経つんだから関係なくね
むしろWindows Terminalとかいうのの存在意義がわからんわ
単にシェルをタブで切り替えるだけなんだろ

おすすめ記事

12: 名無しさん 2020/05/28(木) 10:38:49.52 ID:EYsqH63w
互換性気にして未だにロケールがCP932だから
アプリが個別にUTF-8に対応する度に騒ぐんだよ

17: 名無しさん 2020/05/28(木) 12:48:53.73 ID:T3ERjlW/
>>12
> アプリが個別にUTF-8に対応する度に騒ぐんだよ

対応する度に騒ぐということは、
そういう事例が複数あったということでしょうけど
UTF-8に対応して騒いだという事例を3個ぐらい上げてくれませんか?

13: 名無しさん 2020/05/28(木) 10:42:07.17 ID:EYsqH63w
UTF-8にしても割と最近までBOMありのを使わせてた邪悪設計だったし

18: 名無しさん 2020/05/28(木) 12:50:11.97 ID:T3ERjlW/
>>13
> UTF-8にしても割と最近までBOMありのを使わせてた邪悪設計だったし

BOMがないと文字化けしやすい
UTF-8とそれ以外の判断をすることが不可能だから

14: 名無しさん 2020/05/28(木) 10:42:26.67 ID:Tr5ntMb2
うん、ためになるスレだ

15: 名無しさん 2020/05/28(木) 12:32:40.13 ID:WGyAZfM2
ターミナルって、あれか

ATZ

19: 名無しさん 2020/05/28(木) 13:13:09.20 ID:EYsqH63w
BOMがないと文字化けしやすい(とりあえずCP932に決め打ちするアプリが大半のため)
cl.exeすらオプション指定しないとソースコードはCP932決め打ちだからな
まったくひどいもんだ

20: 名無しさん 2020/05/28(木) 13:24:12.94 ID:T3ERjlW/
>>19
それOSの問題じゃないですよね

28: 名無しさん 2020/05/28(木) 14:24:56.36 ID:EYsqH63w
>>19に戻る

30: 名無しさん 2020/05/28(木) 14:26:49.13 ID:ZG92R/3b
>>28
ロケール関係なくてアプリ(cl.exe)の問題だったということで終わりでは?
なんで結論出たのにもどす必要があるんだw

Sponsored Link

21: 名無しさん 2020/05/28(木) 13:26:24.30 ID:EYsqH63w
OSのロケール見て動いてるからあえて言うならロケールの文字コードがUTF-8になってない化石OSの問題

22: 名無しさん 2020/05/28(木) 13:27:19.12 ID:T3ERjlW/
> OSのロケール見て(アプリが)動いてるから
という話でしたよね?

ならアプリの問題ですよね

23: 名無しさん 2020/05/28(木) 13:40:37.52 ID:EYsqH63w
Windowsはなんとunicodeに対応したすばーらしいOSだから
その仕様に従ってunicodeに対応したすばーらしいアプリは
入力文字列をMultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない
だから入力の文字列をそのまま処理するってアプリがOSのすばらしい設計のために極めて設計しにくく
たとえUTF-8で入力したとしてもMultiByteToWideCharで変換する必要があるクソ仕様なんだ

25: 名無しさん 2020/05/28(木) 13:43:33.54 ID:46ipLv2I
>>23
> たとえUTF-8で入力したとしても

入力って?どこからどこへ何を使って入力するの?
意味わかってないでしょお前w

24: 名無しさん 2020/05/28(木) 13:42:51.99 ID:46ipLv2I
> 入力文字列をMultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない
する必要ないぞ?普通に全部Unicodeで作ればいいだけ

40: 名無しさん 2020/05/28(木) 15:28:27.10 ID:EYsqH63w
>>24でする必要ないって書いてるのに自分で変換するコード出してくるんだから
面白い人だよね

42: 名無しさん 2020/05/28(木) 15:31:19.20 ID:t/VL06oh
>>40
変換してないぞ?
Unicode対応APIを使ってるだけ

26: 名無しさん 2020/05/28(木) 13:50:12.97 ID:EYsqH63w
cl.exeのようにOSのロケール見て入力の文字コード決め打ちしてるアプリの話してるのに何を言い出すのやら

27: 名無しさん 2020/05/28(木) 14:23:17.42 ID:ZG92R/3b
>>26
ロケールを設定することなく、コンパイルオプションで文字コードを変えていますが?

https://torakichi.hateblo.jp/entry/2017/03/04/152827

29: 名無しさん 2020/05/28(木) 14:26:35.25 ID:EYsqH63w
ちなみにそのオプションが追加されたのはVS2015だよ
UTF-8に対応する度に騒がれるアプリが自分で見つけられて良かったね

31: 名無しさん 2020/05/28(木) 14:27:42.80 ID:ZG92R/3b
>>29
おじいちゃん。今はもう2020年ですよ?

32: 名無しさん 2020/05/28(木) 14:28:36.91 ID:ZG92R/3b
悲報 UTF-8に対応する度に騒がれるアプリ = 5年以上も前のアプリだった

33: 名無しさん 2020/05/28(木) 14:45:54.76 ID:EYsqH63w
例えばinput.txtから一行読んでダイアログで表示するプログラムを書こうとすると
https://pastebin.com/NSg29UdB
だと日本語環境ではinput.txtがShiftJISでないと文字化けしてしまう
UTF-8で正しく表示するためには
https://pastebin.com/CXAmWrbr
としなければならない

34: 名無しさん 2020/05/28(木) 14:49:05.59 ID:ZG92R/3b
>>33
ようはテキストエディタが複数の文字コードに対応しているかどうかの話でしょう?
OSのロケールと関係ない

35: 名無しさん 2020/05/28(木) 14:52:09.21 ID:EYsqH63w
unicodeの文字列をコントロールに表示したいならたとえUTF-8だろうとUTF-16LEに変換しなければならないという話

36: 名無しさん 2020/05/28(木) 15:11:59.01 ID:t/VL06oh
>>35
ほらよ。直してやったで(笑)5ちゃんねるがエラー吐くから一部カタカナ化してるからな

文字コードの変換は内部で勝手にやってくれるんだから
いちいち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;
}

38: 名無しさん 2020/05/28(木) 15:23:27.78 ID:t/VL06oh
WindowsはUnicodeに対応してるから、UTF-8のファイルを読み込むなら
_setmodeでファイルストリームの読み込みモードを
テキストモードの一種であるUTF-8用の _O_U8TEXTにすればいいだけなんですよ

きっとコード書いたら理解できずに反論もないだろうと思ってんただろうな
今どんな気持ちだろwww

39: 名無しさん 2020/05/28(木) 15:27:20.10 ID:EYsqH63w
えっUTF-16LEに変換しなきゃいけないって何度も言ってるんだけどまだ伝わってないの

41: 名無しさん 2020/05/28(木) 15:30:43.55 ID:t/VL06oh
自分で言ったセリフ忘れたんか?w

> 入力文字列をMultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない
> たとえUTF-8で入力したとしてもMultiByteToWideCharで変換する必要があるクソ仕様なんだ

お前が言ったのは「MultiByteToWideCharで変換する必要」があるだろうが

俺が書いたコードには、明示的にUTF-16LEに変換しているコードはない
入力ファイルの文字コードを指定し、WindowsのUnicode対応のAPIを使っただけだ

43: 名無しさん 2020/05/28(木) 15:32:15.30 ID:EYsqH63w

44: 名無しさん 2020/05/28(木) 16:30:13.86 ID:t/VL06oh
Windows NT系の内部コードは、最初のバージョンからUnicode(UCS-2 or UTF-16)なんだから
ShiftJISを含め、どんな文字コードであっても、内部的にはUnicodeに変換してから使ってるに決まってるだろ?

それはLinuxでも同じ。LinuxもUTF-16のファイルを表示したいならUTF-8
もしくは現在のロケールに変換しないといけない

ファイルの文字コードと内部文字コードがともにUTF-8なら変換しなくていいというのなら
WindowsだってともにUTF-16なら変換しなくていい

もう一回聞くぞ?お前がクソだといいたかったのは手動で
「MultiByteToWideCharっていうAPIでUTF-16LEに変換しなきゃいけない」
ってことなんだろ?内部で変換されることに関しては当てはまらんだろ
少なくともお前が書いたクソコードより俺のほうがシンプルだ

45: 名無しさん 2020/05/28(木) 17:57:46.65 ID:6TDNf+YY
文字の倒置ぐらい簡素に出来んもんかね
平文で棋譜が書きづらいだろ

あとAA環境は死守な

勉強になります

Pocket

おすすめ記事

You may also like...

『「Windows Terminal 1.0」の登場で加速する脱ShiftJIS。Windowsの完全Unicode化まで残るはzip圧縮のみ』へのコメント

※コメントは自動承認、スパムは自動削除されます。節度を持って楽しくコメントをお願いします。

コメントを残す