『メモ帳』標準のBOMなしUTF-8に、Windows Searchは対応していない 116
ストーリー by nagazou
サイト内の検索でもよく見る問題 部門より
サイト内の検索でもよく見る問題 部門より
ASCII.jpの記事によると、最近ではUTF-8形式のテキストファイルも増えているがその反面、WindowsでUTF-8を使うとWindows Searchの利用に不便が生じることがあるそうだ。
正確にはファイル先頭にバイトオーダーマーク（BOM）のあるUTF-8は正しく認識できるものの、BOMのないUTF-8の場合、日本語などの非ASCII文字で全文検索ができないとしている。BOMはUTF-8形式において必須項目とされていないため、BOMのないUTF-8のデータも数多く出回っている。Windowsに付属するメモ帳でも「19H1」（May 2019 Update）からは標準設定ではBOMのない仕様に変更されている。
正確にはファイル先頭にバイトオーダーマーク（BOM）のあるUTF-8は正しく認識できるものの、BOMのないUTF-8の場合、日本語などの非ASCII文字で全文検索ができないとしている。BOMはUTF-8形式において必須項目とされていないため、BOMのないUTF-8のデータも数多く出回っている。Windowsに付属するメモ帳でも「19H1」（May 2019 Update）からは標準設定ではBOMのない仕様に変更されている。
BOM付きUTF8で改行コードはLF(UNIX) (スコア:1)
VisualStudio2013とLinuxGCCの両方でコンパイル可能なソースコードを書くにはと組み合わせを試した結果OKだったのがこれでした
Re: (スコア:0)
WindowsとLinuxの両方で動くPowerShellスクリプトの場合は
Windows上のPowerShell ISEで編集するためにはUTF-8 BOMありじゃないと駄目だけど
BOMありにすると 「#!/usr/bin/pwsh」の#!の前にBOMが来てしまうのでLinuxで実行できない、という問題があったなぁ
切り替えが遅すぎる (スコア:0)
ファイル名やコンソールの入出力も、さっさとUTF-8に統一しろ。
Re:切り替えが遅すぎる (スコア:1)
Win32APIもNTFSもUTF-16なんだから無理。
[Q][W][E][R][T][Y]
Re: (スコア:0)
とっととUTF-128に移行すればいいのに…
Re: (スコア:0)
ファイル名を直接いじることなんてほとんど無いんだからunicodeに対応していれば十分だしコンソールの入出力はバイナリだからアプリの問題じゃね？
切り替えが遅いんじゃなくてユーザーや開発者が切り替えていないだけのような。
Re: (スコア:0)
端末エミュレータ含めて、まともなアプリケーションはシステムのロケールを読んで切り替えるのだから、OSのデフォルトが変わらないと意味ない。
Re:切り替えが遅すぎる (スコア:1)
まともなアプリケーションなら、正常なUnicodeコードポイントが現れただけで動作不良起こさないと思うよ。
[Q][W][E][R][T][Y]
Re: (スコア:0)
まともなアプリケーションはシステムのロケールを読んで切り替える
システムロケールを切り替えていないユーザーの問題だよね？
そういうユーザーが多数存在するからデフォルト値が変わらない。
一時期デフォルト値を切り替えようという動きがあったけれど、時期尚早ということで流れたはず。
Re: (スコア:0)
まともなユーザは地雷原に突撃するようなことはしないからね
Re: (スコア:0)
ファイル名に絵文字を使って
「あのうさぎちゃんのファイルをちょうだい」
「やだ、ねこちゃん消しちゃった」
ていう優しい世界をはやく実現したいってことだよ。みなまで言わせんな。
Re:切り替えが遅すぎる (スコア:1)
絵文字の話は UTF-8 ってよりは Unicodeのバージョンの話だったりしませんかね
Re: (スコア:0)
＞うさぎちゃんのファイル
かわいらしく聞こえるけど大人向けの黒いうさぎさんかもしれませんね
Re: (スコア:0)
オタク向けの金髪ツインテール鴨
当分無理 (スコア:0)
ShiftJISやUTF-16に決め打ちしているアプリケーションが多すぎて、どうにもならない。
Re: (スコア:0)
一つのアプリケーションで、ケースバイケースで、ShiftJISとUTF-16とUTF-8を相互変換しながら使い分けているなんて珍しくもない。
逆に言えば、そういった複雑な使い分けをしているから、簡単には修正できなくなっている。
Re: (スコア:0)
そういうことしてるのに簡単に修正できないってことは結局ロケール決め打ちしてただけでしょ。日本人用アプリがShiftJIS決め打ちしてるのと変わらん。
Re: (スコア:0)
標準仕様のZIPはShift-JISだね。
teamsの機能で中身を見ると文字化けする。UTF-8だと思う。
Windows10の仕様はぐちゃぐちゃです。
うまく動かないのがWindows10の普通です。
それがWindowsの仕様だから文句言っちゃいけません。
ありもしないWindows10作ってる都合 (スコア:0, 荒らし)
手が回らなかっただけでしょ。
Shift-JISの検索でしか対応してないので
メモ帳をShift-JISで保存すれば検索されますよ。
Windows10と呼ばれるものが今だに旧型なだけです。
Windows10のサポートが切れる頃にはできるようになっているのかもしれませんね。
Windows11のサポート期間中に・・・
Re:ありもしないWindows10作ってる都合 (スコア:1)
誰か日本語に訳してお願い
Re: (スコア:0)
○未だに
Re: (スコア:0)
「未だに」は否定文のみで、肯定文では「今だに」が正しい。助詞の「だに」を知らないと意味が分からんだろうが。
Re: (スコア:0)
訳してもどうでもいい内容だけど、それでも訳してほしいですか？
Re: (スコア:0)
日本に来て日が浅いと大変ですね
過渡期 (スコア:0)
Windows は今は過渡期なんだよ。
Microsoft は外部コードを最終的に UTF-8 (BOM無し)をデフォルトにする方針を固めていて、
メモ帳がいち早く移行しただけで、全体的にはまだ移行していない。
次のメジャー・バージョンあたりデフォルトコードページを CP932 から UTF-8 に変更してくる可能性が高い。
Re: (スコア:0)
俺ここらへんさっぱり分からないままなんだが、
Windowsにおける「デフォルトコードページ」って、なんかこう、何者なんだっていうか
「OSが持っておくべき設定項目の一つ」みたいな顔してて、どっかで設定できたりするものなんだっけ？
cmd.exe の chcp コマンドは知ってるけど
もう cmd.exe は過去の互換のためだけに残してるもんじゃないんかな。
多分これもう改良されないと思う。
今や PowerShell の時代だし。
Re:過渡期 (スコア:2, 参考になる)
「コントロールパネル\時計と地域」から「管理」タブの「システムロケールの変更」で設定できます。
windows apiはwidechar版(末尾がW)はUTF-16なのですが、これが「日本」になっているとmultibyte版(末尾がA)ではコードページ932(いわゆるシフトJIS)が使われます。
「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」にチェックを入れると、multibyte版でUTF-8が使えるようになります。
multibyte apiを使っているアプリケーションで、コードページが932を前提としているものは正しく動かなくなる(例えば漢字が表示できなくなる)ので、MSも中々踏み切れないのではないかと。
Windowsの検索はデフォルトをもう少しどうにかならんものか (スコア:0)
検索式を入力しないとファイル名ですらまともに検索できない、ファイル内容や拡張子によってファイル内容もまともに検索できない
検索式なんて概念も無いユーザーからしたら、検索出来たり出来なかったりと意味が分からないレベルだと思うのだが
ファイル名検索と内容検索(まともでは無かったが)が別れていたWindowsXPの頃の検索の方が100倍マシな気がする
個人的には
検索結果をソートしたら再検索が始まる、入力してる途中から検索が始まる、ネットワークストレージなど遅いときが・・・
検索結果のフォルダを開くとアドレスバーの表示が「検索場所:～(search-ms)」になるのも地味にイラつきます
Re: (スコア:0)
部分一致検索がマトモに出来なくて痛い。
「hogehoge_2021」というファイル名に対して「oge」で検索すると結果0件だったり。
BOM有りに統一すべきだった (スコア:0)
BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。
よくある文字コードを自動判定するという動作は、ファイルの内容の一部（1KBとか）、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
BOMなら3バイト読むだけで済みます。
そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。
UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すればいいのです。
0xEF 0xBB 0xBF の3バイトがあれば、無視するだけですよ。
文字コードの自動判別と違って、たったプログラムのコード数行ですむ改修です。そっちにもってくべきでした。
複数のファイルを結合したときの問題？
インタプリタ言語でのエラー？
どこにあろうが 0xEF 0xBB 0xBF などのBOMを無視すればいいだけでしょう。
ゴミがどうのという主張に対しては、改行コードをLFじゃなくてCR+LFを使えば改行ごとに1バイト無駄になるし、
タブインデントの代わりにスペース4でインデントすればインデントのたびに3バイト無駄になりますが、そんなの気にする時代じゃないでしょう。
Re:BOM有りに統一すべきだった (スコア:2)
検索に関しては識別などしないでデフォルトコードページとUTF-8の両方ともインデックス作っておけばいいんじゃないですかね。
どっちかでマッチすればよいのだし。
Re:BOM有りに統一すべきだった (スコア:2)
時代後れすぎる。
okome
Re: (スコア:0)
個人的にはゴミデータ以前に
BOM無しで手間がかかることは有るけど困ることは滅多になく、BOMありで困る事はあっても良かったと思う事はなかったのでBOM無しに統一して欲しかったです
Re: (スコア:0)
一部の人にはとことん迷惑という意味で、往年のMacバイナリを思い出した。
Re: (スコア:0)
わかってないなー。サイズが勿体ないのではなくて、
バイトオーダーをわざわざ示す行為が二度手間で無駄なんだよ
Re:BOM有りに統一すべきだった (スコア:1)
世の中に UTF-8 だけしか存在しないならね。
現実は 8bitの文字コードなんて山のようにあるから、
ファイルの内容を解析するプログラムなら、文字コードを指定するか、
決め打ちするか、コードを推測するかのどれかが必要になる。
良くも悪くも WindowsSearch で文字化けした結果が表示されないのはBOMのおかげっていうことだ。
[Q][W][E][R][T][Y]
Re: (スコア:0)
BOMはあくまでバイトオーダーを示すために規定されたもので、BOMによってエンコードを判定できるのは結果論でしかないけどな
Re:BOM有りに統一すべきだった (スコア:1)
どちらにしろ推測が必要ならビット列の出現率からエンコード推測するよりマシでしょう。
[Q][W][E][R][T][Y]
Re:BOM有りに統一すべきだった (スコア:1)
「推測する」は「信用する」ではない
[Q][W][E][R][T][Y]
もともとは～とか言い出すと (スコア:0)
Windowsの改行コードに使われている CR (キャリッジリターン) と LF (ラインフィード) の意味はご存知でしょうか。
タイプライターでは印字装置は固定され、紙の方が上下左右に移動することで、文字送りや行送りが行われるんです。
CRは、紙を固定して移動する装置（キャリッジ）を元の位置に戻すことで、LFとは行を送る（タイプライターなら紙を進める）ことです。
CRとLFはあくまでタイプライターの動作を示すために規定されたもので、CR+LFによって改行を判定できるのは結果論でしかないのですよ。
これを考えればもともと何を目的としていたかなんて無意味であることが理解できるはず。
話をBOMに戻すと、例えば、RFC3023
Re: (スコア:0)
BOM無しUTF-8の一番の利点は既存のASCIIコードしか想定してないプログラムが修正なしで動く可能性がそこそこ有るという部分なのでBOM付きにしたらUTF-8の意味がない。
例えば売れた時刻,品名,個数がカンマ区切りで書かれているファイルを処理するプログラムがあるとする。
ここでファイルがBOM無UTF-8で品名にUTF-8文字が含まれていても、多くの場合プログラムの修正はいらない。でもBOM付だと修正しないと誤動作する。
Re: (スコア:0)
そのASCII互換というのはUTF-8を普及させる段階では最大のメリットと言えたでしょう。
しかしUTF-8が一般化した現時点においては、BOMによってUTF-8であると判定できるメリットが、UTF-8非互換のプログラムを誤動作させるデメリットを上回っていると言えるでしょう。
Re: (スコア:0)
3バイトも使うなら、タグでいいんじゃないかって気になるからな。
Re: (スコア:0)
CSVを使っているということはお手軽に書いたバッチファイルや簡易的なスクリプトだと思いますが、BOMを無視or削除するなんてコード、原始的なWindowsバッチファイルやシェルスクリプトでも数分あれば書けます。
古いプログラムなら修正すればいいですし、今時他のユーザ（社内の他の従業員を含む）がBOM付きファイルを処理することすら想定できていないならプログラマーとしての資質に問題があるでしょう。
Re:BOM有りに統一すべきだった (スコア:1)
そりゃあ cat は Unicode 非対応だから。
むしろ勝手に BOM 操作したらバイナリが壊れるから cat として使えない。
cat じゃないプログラムで連結するか input 側でBOM対応すればいいだけ。
そもそもファイルの途中で ZWNBS 出てくるのはUnicode テキストとしてはエラーじゃないから。
いつまでもテキスト連結に cat を使うというのが Unicode 推進側の怠慢である。
[Q][W][E][R][T][Y]
Re:BOM有りに統一すべきだった (スコア:1)
知らないよそんなの。
そもそも怠慢してるんだから well known なソフトは無いんじゃないの。
Unicode以外だってそれなりに文字コード処理必要なんだから
cat だけ怠慢してるのが悪い。
[Q][W][E][R][T][Y]
Re:cat に関する訂正 (スコア:1)
Re:cat に関する訂正 (スコア:1)
// Plan9 はそこからスタートしたんじゃなかったっけ
Re:cat に関する訂正 (スコア:1)
が、これだけデータがメタだらけになっている昨今コンソールだけではしんどいです…
困ることはありません。 (スコア:0)
これはバグではありません。
これは仕様です。
仕様に沿ってお使いください。