Windows 10 Insider Preview、メモ帳でBOMなしのUTF-8が選択可能に 61
ついに 部門より
Microsoftは10日、Windows 10 Insider Previewビルド18298（19H1）をファーストリング向けに提供開始した（Windows Experience Blog）。
ビルド18298のメモ帳では、保存時に文字コード（エンコード）としてBOM（Byte Order Mark）なしのUTF-8が選択可能となり、これがデフォルトの文字コードに設定されている。なお、従来は文字コードで「UTF-8」を選択して保存するとBOM付きのUTF-8で保存されていたが、本ビルドで「UTF-8」を選択するとBOMなしになり、BOM付きで保存するには「UTF-8（BOM付き）」を選択する必要がある。ステータスバーには文字コードを表示する枠が追加されており、変更後未保存のファイルにはタイトルバーのファイル名先頭にアスタリスク（*）が付記されるようになっている。
また、「ファイル」メニューの「名前を付けて保存」にはついにショートカットキー（Ctrl+Shift+S）が割り当てられ、新たに追加されたメニュー項目「新しいウィンドウ」をCtrl+Shift+Nで呼び出せるほか、Ctrl+Wで現在のウィンドウを閉じることも可能になった。このほか、パスが260文字を超えるファイルの読み込みや保存が可能になっており、「ヘルプ」メニューからフィードバックHubが呼び出せるようになるといった改良や、バグの修正が行われている。このメニュー項目とショートカットキーについては、ビルド18290で既に追加されていた模様。
メモ帳以外のビルド18298の新機能としては、各種コンソールウィンドウのプロパティに「ターミナル」タブが追加され、実験的な表示オプションを設定できるようになっている。また、スタートからフォルダー単位でピン留めを外せるようになっており、設定→アカウント→サインインオプションからセキュリティキーの管理が可能になったほか、ユーザー補助機能の改善など、数多くの改善や修正が行われている。
WSLに向けて？ (スコア:2)
WSLのLinuxでも利用できることを考えると、テキストエンコーディングはBOMなしUTF-8、改行はLFでないとね。
ひょっとすると、改行をCR+LFとするディストリビューションが出てくるかも？と思ってたけど、さすがにもうなさそうだな。ｗ
VSCodeでよくね (スコア:0)
いいよね？
Re:VSCodeでよくね (スコア:1)
それはわたしのウインドウズにはいってますか？
Re: (スコア:0)
electronもchromiumエンジンなんだっけ？
edgeがchromiumベースになって、システムにデフォルトでchromiumが入るようになれば
vscodeも可能性あるんじゃないだろうか
Re: (スコア:0)
そりゃ標準で入ってたら会社支給PCなんかでやりくりするシチュでは助かるかもしれない
でもコード書く奴なんてPC使う人数全体からしたらごく少数だろ
「何もしてないのに壊れた」とか言い出す連中のPCで
テキストファイルダブルクリックしてこれ立ち上がったらどうなるか
「ターミナルって何」「デバッグって何」「Gitって何」「変な候補が出る」「何もしてないのにスペースが入った」
想像すらしたくないわ
Re: (スコア:0)
機能が多いだけでテンパる初心者もいるし。
事務用PCとかにも片っ端からVSCode入れるのも面倒くさい。
Re: (スコア:0)
機能が多いだけでテンパる初心者もいるし。
そういう意味では、LF対応とか今回のとか、メモ帳の多機能化が進んでいて少し心配。さすがにまだ杞憂レベルだけど。
Re: (スコア:0)
Windows Serverにデフォルトで入ってるのならいいけど…。
やっとBOM取れたかー。長かった！
Re: (スコア:0)
まず重いって時点でダメだろ
Re: (スコア:0)
だめです。
Re: (スコア:0)
ちょっとしたテキストファイル見たいだけなのに、起動するまで1分近くかかる重量級エディタ使うんですか？
Re: (スコア:0)
実験したけどNTEmacsより起動速かったよw
君が20世紀からタイムスリップしてきたんならゴメン
現代のPCは1人1台あってemacs起動しても研究室のみんなに迷惑かかったりしないんだ…
Re: (スコア:0)
いや一般的なスペックだよ
未だにWin7みたいな10年前の骨董品の市場シェアがそれなりにあるんだぜ？
日本語はどうなる？ (スコア:0)
結局のところWindowsではUTF-8とその他のMBCSとの識別の為にUTF BOMを用いていたのだと思うのだけど、
これが無くなってWindowsのその他のツールは適切に追随してくれるのだろうか。
Re:日本語はどうなる？ (スコア:1)
むしろこれを機会にレガシーなエンコードへの対応を減らす方向に進んでほしい
うじゃうじゃ
Re: (スコア:0)
UTF-8とそれ以外のMBCSの識別をしよう、という程度のプログラムなら、ある程度対応できると思う。というかCP932みたいなのもまだ残ってるわけだし。
BOMがあろうとなかろうとMBCSにマトモに対応してないソフトはどうしようもない。
# WindowsというかMSが開発してるツールは比較的マトモに対応してる方だと思うけどね
Re: (スコア:0)
考え方は概ね同意なんだけど、「対応」の方向性によっては影響が大きいのが気になる。
もともと、テキストのバイナリからそのテキストがShift_JISなのかUTF-8なのかは推定しかできなくて、
しかも精度を上げるには内容全体をスキャンしなければならない。
その切り分けを先頭のマークだけで行うようにした判断は、「英断」だった。
既存でデフォルトとしてきたShift_JISのテキストファイルを正しく開け、UTF-8にはBOMが付くので超最小限のコストで判別できるからだ。
もし今後、テキストの内容によって自動判別をするのがMSのポリシーになるのだとすると、
- 1GBの最後の文字だけ日本語文字
260文字超パス名 (スコア:0)
むしろこっちが気になった。
>パスが260文字を超えるファイルの読み込みや保存が可能になっており
じゃあ最大文字数何文字なのよと調べたら32KB？今後そんなファイルが増えるのか。
SDKの記号定数MAX_PATH使ってるプログラム全滅じゃん。
Re:260文字超パス名 (スコア:1)
＞SDKの記号定数MAX_PATH使ってるプログラム全滅じゃん。
なので長いファイル名はデフォルト無効になっております
Maximum Path Length Limitation [microsoft.com]
Re: (スコア:0)
MAX_PATH が非推奨になってからの期間のほうが倍くらい長くなってるのに、今でも MAX_PATHを使ってたころの時代のアプリが、現役だということなんだよな。
いつからメンテされないのか考えたくもない。
Re: (スコア:0)
あれ？ブラウザで画像保存するとき近くにあった説明テキストをそのままコピペしてファイル名に使ったら295バイトあって（SHIFT_JIS換算。拡張子除く。フォルダ名なども除く）なぜか保存は成功してしまい、Windowsフォトビュアーでは読めるけれどMAX_PATH使った自作ツールでは読めないみたいなことがあったのですが…。（ちなみにWindows7。ブラウザはOpera12だったかFirefoxだったかちと記憶があいまい。自作ツールはUNICODEではなくANSIでコンパイル）
Re: (スコア:0)
それはプログラム側が特殊な対応をしなくてもよくなるだけの設定
逆に言えば特殊な対応をしているならそんなもんに関係なく大昔からMAX_PATHなんか超えられる
Re:260文字超パス名 (スコア:1)
現状、実際には260文字も使えないんですけどね。
Explorerでルートにファイル作って、ファイル名に300文字ペーストしたら240文字で切られます。
これに拡張子(.txt)とドライブ名と￥入れても247文字。
あと13文字はどこに行ったのか。ホスト名？
Re: (スコア:0)
エクスプローラを直に使う場合はそうかもしれませんが、
(#3533568)でも書きましたが、ファイル保存ダイアログでは出来てしまう場合があるんです。
Windows標準のファイル保存ダイアログなのか、独自実装なのか、そこまではわかりませんが。
Re: (スコア:0)
MAX_PATH を越えるファイル名を扱うか否かは、アプリ毎というか、APIコール毎にアプリ作成側が自由に選べる。
https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file [microsoft.com]
コモンコントロールのファイル保存ダイアログとかを使う場合は、保存ダイアログにファイル名を渡す側が決められるので、ブラウザが対応していたということでしょう。
Re: (スコア:0)
APIコール毎になんか選べないよ
一体どこの記述読んでんの？
Re: (スコア:0)
100回読みなおせ
Re: (スコア:0)
officeが新規保存時に長いパス名でやられてますけどね。
更新ならできるのでファイル作ってから編集しないといけないので面倒
あとは (スコア:0)
改行コードLFも対応してくれると、デフォルトのエディタとしてはとりあえず言うことないんですがねぇ。
#サーバ機とか客先の業務端末でunix系のログ見ようとして絶望する
Re:あとは (スコア:1)
Re: (スコア:0)
お使いの環境は 1809 になってませんね？
https://blogs.msdn.microsoft.com/commandline/2018/05/08/extended-eol-i... [microsoft.com]
Re: (スコア:0)
今朝やっと落ちてきたとこなのでまだ確認してなかったです。
Re: (スコア:0)
#サーバ機とか客先の業務端末でunix系のログ見ようとして絶望する
そういうときはWebブラウザという文字コードも改行コードも自動判別してくれるビューワーが便利ですよ。
Re: (スコア:0)
htmlの頭に文字コードを書いとかないと文字化けすることがですね…
Re: (スコア:0)
こうですか分かりません！
これはいいけど、気になることが… (スコア:0)
次の「Skip Ahead」がないなぁ…。
ひょっとして10は19H1が最後かな？
まぁ1809ので予定狂ってるのかも。
ただ、このメモ帳の改善はうれしい。
必要かどうかは、人それぞれだが…。
Re: (スコア:0)
過去のSkip Aheadが出てきた時期を調べてから喋れよ
前回の安定リリースから次の安定リリースまで半分も過ぎてないのに出るわけないだろ
やっと正常化 (スコア:0)
そもそも「テキストファイル」に文字を符号化したバイナリデータ以外を含んではいけなかったんだけど、
ようやくMicrosoftが誤りを認めたね。
対応が遅すぎた気はするけど、まずは歓迎。
Re: (スコア:0)
BOMはZWNBSという文字として判断されるから誤りじゃないでしょ
Re:やっと正常化 (スコア:1)
U+FEFF を zero width no-break space (ZWNBSP) として使用することはもはや強く非推奨、ではある。
メールへの波及効果 (スコア:0)
ソフトウェアのデフォルト設定値は影響が大きいことを知っていたけど、
メールをISO-2022-JPで送信している方がUTF-8のHTMLに変更を検討するレベルだったとは。
さよならシフトJIS、主なしとて春な忘れそ
https://pc.watch.impress.co.jp/docs/column/config/1158344.html [impress.co.jp]
Re: (スコア:0)
山田祥平氏がvoid氏の知り合いだったとは初耳だった。
有名?
https://pc.watch.impress.co.jp/docs/column/config/1158344.html [impress.co.jp]
>finというフィルタプログラムを日下部陽一氏の指導のもとに見よう見まねで作ってみたこともあった。
さよならシフトJIS、主なしとて春な忘れそ
Re:メールへの波及効果 (スコア:1)
https://pc.watch.impress.co.jp/docs/column/config/1158344.html [impress.co.jp] [impress.co.jp]
>finというフィルタプログラムを日下部陽一氏の指導のもとに見よう見まねで作ってみたこともあった。
ああこれ、学生時代にレポートを書く時にお世話になりました。
Void氏と山田氏の作だったんだ…。
提出したら、教官から「これってTeXで作ったの？」とか訊かれたのも良い想い出。
＃ NTT-TeXが出始めの頃で、教官もTeXを触った事のない時代……。
Re: (スコア:0)
昔PACK2000の全ソフトを眺めたときに見た覚えがあるぞと思ってベクターを調べたらまだあった。
https://www.vector.co.jp/soft/dos/util/se000958.html [vector.co.jp]
確かに作者は「日下部 陽一 山田 祥平」となってる。
つまり、、、 (スコア:0)
utf8(bom)のcsvを開き上書保存してら
excelで文字化けするようになるんですね！
Re:つまり、、、 (スコア:1)
それはExcelが糞
Re:つまり、、、 (スコア:1)
Re: (スコア:0)
逆にBOMなしUTF-8を上書き保存したとき強制的にBOMをつけられる仕様もようやく改善されるのか
Re: (スコア:0)
Excelは、未だにこの形式に対応していないらしい。
なのでフィードバックHubなどから投稿しておいた。
この調子で (スコア:0)
ZIPフォルダーの圧縮時UTF-8ファイル名対応も頼む(現在は展開のみ対応)。One Driveと仕様が一致してないのほんとひどい