パスワードを忘れた? アカウント作成
15315989 story
Windows

『メモ帳』標準の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のない仕様に変更されている。
  • by Anonymous Coward on 2021年06月15日 14時35分 (#4051137)

    VisualStudio2013とLinuxGCCの両方でコンパイル可能なソースコードを書くにはと組み合わせを試した結果OKだったのがこれでした

    ここに返信
    • by Anonymous Coward

      WindowsとLinuxの両方で動くPowerShellスクリプトの場合は
      Windows上のPowerShell ISEで編集するためにはUTF-8 BOMありじゃないと駄目だけど
      BOMありにすると 「#!/usr/bin/pwsh」の#!の前にBOMが来てしまうのでLinuxで実行できない、という問題があったなぁ

  • by Anonymous Coward on 2021年06月15日 13時46分 (#4051099)

    ファイル名やコンソールの入出力も、さっさとUTF-8に統一しろ。

    ここに返信
    • Win32APIもNTFSもUTF-16なんだから無理。

      --
      [Q][W][E][R][T][Y]
      • by Anonymous Coward

        とっととUTF-128に移行すればいいのに…

    • by Anonymous Coward

      ファイル名を直接いじることなんてほとんど無いんだからunicodeに対応していれば十分だしコンソールの入出力はバイナリだからアプリの問題じゃね?
      切り替えが遅いんじゃなくてユーザーや開発者が切り替えていないだけのような。

      • by Anonymous Coward

        端末エミュレータ含めて、まともなアプリケーションはシステムのロケールを読んで切り替えるのだから、OSのデフォルトが変わらないと意味ない。

        • まともなアプリケーションなら、正常なUnicodeコードポイントが現れただけで動作不良起こさないと思うよ。

          --
          [Q][W][E][R][T][Y]
        • by Anonymous Coward

          まともなアプリケーションはシステムのロケールを読んで切り替える

          システムロケールを切り替えていないユーザーの問題だよね?
          そういうユーザーが多数存在するからデフォルト値が変わらない。
          一時期デフォルト値を切り替えようという動きがあったけれど、時期尚早ということで流れたはず。

          • by Anonymous Coward

            まともなユーザは地雷原に突撃するようなことはしないからね

      • by Anonymous Coward

        ファイル名に絵文字を使って
        「あのうさぎちゃんのファイルをちょうだい」
        「やだ、ねこちゃん消しちゃった」
        ていう優しい世界をはやく実現したいってことだよ。みなまで言わせんな。

    • by Anonymous Coward

      ShiftJISやUTF-16に決め打ちしているアプリケーションが多すぎて、どうにもならない。

      • by Anonymous Coward

        一つのアプリケーションで、ケースバイケースで、ShiftJISとUTF-16とUTF-8を相互変換しながら使い分けているなんて珍しくもない。
        逆に言えば、そういった複雑な使い分けをしているから、簡単には修正できなくなっている。

        • by Anonymous Coward

          そういうことしてるのに簡単に修正できないってことは結局ロケール決め打ちしてただけでしょ。日本人用アプリがShiftJIS決め打ちしてるのと変わらん。

    • by Anonymous Coward

      標準仕様のZIPはShift-JISだね。
      teamsの機能で中身を見ると文字化けする。UTF-8だと思う。
      Windows10の仕様はぐちゃぐちゃです。
      うまく動かないのがWindows10の普通です。
      それがWindowsの仕様だから文句言っちゃいけません。

  • by Anonymous Coward on 2021年06月15日 13時53分 (#4051102)

    手が回らなかっただけでしょ。
    Shift-JISの検索でしか対応してないので
    メモ帳をShift-JISで保存すれば検索されますよ。
    Windows10と呼ばれるものが今だに旧型なだけです。
    Windows10のサポートが切れる頃にはできるようになっているのかもしれませんね。
    Windows11のサポート期間中に・・・

    ここに返信
  • by Anonymous Coward on 2021年06月15日 14時56分 (#4051172)

    Windows は今は過渡期なんだよ。
    Microsoft は外部コードを最終的に UTF-8 (BOM無し)をデフォルトにする方針を固めていて、
    メモ帳がいち早く移行しただけで、全体的にはまだ移行していない。
    次のメジャー・バージョンあたりデフォルトコードページを CP932 から UTF-8 に変更してくる可能性が高い。

    ここに返信
    • by Anonymous Coward

      俺ここらへんさっぱり分からないままなんだが、
      Windowsにおける「デフォルトコードページ」って、なんかこう、何者なんだっていうか
      「OSが持っておくべき設定項目の一つ」みたいな顔してて、どっかで設定できたりするものなんだっけ?

      cmd.exe の chcp コマンドは知ってるけど
      もう cmd.exe は過去の互換のためだけに残してるもんじゃないんかな。
      多分これもう改良されないと思う。
      今や PowerShell の時代だし。

      • Re:過渡期 (スコア:2, 参考になる)

        by Anonymous Coward on 2021年06月15日 17時47分 (#4051344)

        「コントロールパネル\時計と地域」から「管理」タブの「システムロケールの変更」で設定できます。
        windows apiはwidechar版(末尾がW)はUTF-16なのですが、これが「日本」になっているとmultibyte版(末尾がA)ではコードページ932(いわゆるシフトJIS)が使われます。

        「ベータ:ワールドワイド言語サポートでUnicode UTF-8を使用」にチェックを入れると、multibyte版でUTF-8が使えるようになります。

        multibyte apiを使っているアプリケーションで、コードページが932を前提としているものは正しく動かなくなる(例えば漢字が表示できなくなる)ので、MSも中々踏み切れないのではないかと。

  • 検索式を入力しないとファイル名ですらまともに検索できない、ファイル内容や拡張子によってファイル内容もまともに検索できない
    検索式なんて概念も無いユーザーからしたら、検索出来たり出来なかったりと意味が分からないレベルだと思うのだが
    ファイル名検索と内容検索(まともでは無かったが)が別れていたWindowsXPの頃の検索の方が100倍マシな気がする

    個人的には
    検索結果をソートしたら再検索が始まる、入力してる途中から検索が始まる、ネットワークストレージなど遅いときが・・・
    検索結果のフォルダを開くとアドレスバーの表示が「検索場所:~(search-ms)」になるのも地味にイラつきます

    ここに返信
    • by Anonymous Coward

      部分一致検索がマトモに出来なくて痛い。
      「hogehoge_2021」というファイル名に対して「oge」で検索すると結果0件だったり。

  • by Anonymous Coward on 2021年06月15日 16時10分 (#4051235)

    BOMは「ゴミ」であって不要なデータが入ってくるのが無駄だと主張する人がいますが、無駄なのは文字コードの自動判別の方です。

    よくある文字コードを自動判定するという動作は、ファイルの内容の一部(1KBとか)、アプリによってはファイルの全部を読んでから文字コードを判定するので非常に負荷が大きいのです。
    BOMなら3バイト読むだけで済みます。

    そして、Unicodeに対応しているアプリであればBOMは文字コード・エンディアンの判別に使えばいいし、そうでないなら無視すればよろしい。

    UTF-8のBOMがあるだけで不具合起こすアプリなんていうのは、今時そっちの方がおかしいので修正すればいいのです。
    0xEF 0xBB 0xBF の3バイトがあれば、無視するだけですよ。
    文字コードの自動判別と違って、たったプログラムのコード数行ですむ改修です。そっちにもってくべきでした。

    複数のファイルを結合したときの問題?
    インタプリタ言語でのエラー?
    どこにあろうが 0xEF 0xBB 0xBF などのBOMを無視すればいいだけでしょう。

    ゴミがどうのという主張に対しては、改行コードをLFじゃなくてCR+LFを使えば改行ごとに1バイト無駄になるし、
    タブインデントの代わりにスペース4でインデントすればインデントのたびに3バイト無駄になりますが、そんなの気にする時代じゃないでしょう。

    ここに返信
    • 検索に関しては識別などしないでデフォルトコードページとUTF-8の両方ともインデックス作っておけばいいんじゃないですかね。
      どっちかでマッチすればよいのだし。

    • 自動判別自体が問題になるので最近はhttpでも文字コード指定が必須。
      時代後れすぎる。
      --
      okome
    • by Anonymous Coward

      個人的にはゴミデータ以前に
      BOM無しで手間がかかることは有るけど困ることは滅多になく、BOMありで困る事はあっても良かったと思う事はなかったのでBOM無しに統一して欲しかったです

      • by Anonymous Coward

        一部の人にはとことん迷惑という意味で、往年のMacバイナリを思い出した。

    • by Anonymous Coward

      わかってないなー。サイズが勿体ないのではなくて、
      バイトオーダーをわざわざ示す行為が二度手間で無駄なんだよ

      • 世の中に UTF-8 だけしか存在しないならね。
        現実は 8bitの文字コードなんて山のようにあるから、
        ファイルの内容を解析するプログラムなら、文字コードを指定するか、
        決め打ちするか、コードを推測するかのどれかが必要になる。

        良くも悪くも WindowsSearch で文字化けした結果が表示されないのはBOMのおかげっていうことだ。

        --
        [Q][W][E][R][T][Y]
        • by Anonymous Coward

          BOMはあくまでバイトオーダーを示すために規定されたもので、BOMによってエンコードを判定できるのは結果論でしかないけどな

          • どちらにしろ推測が必要ならビット列の出現率からエンコード推測するよりマシでしょう。

            --
            [Q][W][E][R][T][Y]
          • Windowsの改行コードに使われている CR (キャリッジリターン) と LF (ラインフィード) の意味はご存知でしょうか。
            タイプライターでは印字装置は固定され、紙の方が上下左右に移動することで、文字送りや行送りが行われるんです。
            CRは、紙を固定して移動する装置(キャリッジ)を元の位置に戻すことで、LFとは行を送る(タイプライターなら紙を進める)ことです。

            CRとLFはあくまでタイプライターの動作を示すために規定されたもので、CR+LFによって改行を判定できるのは結果論でしかないのですよ。

            これを考えればもともと何を目的としていたかなんて無意味であることが理解できるはず。

            話をBOMに戻すと、例えば、RFC3023

    • by Anonymous Coward

      BOM無しUTF-8の一番の利点は既存のASCIIコードしか想定してないプログラムが修正なしで動く可能性がそこそこ有るという部分なのでBOM付きにしたらUTF-8の意味がない。

      例えば売れた時刻,品名,個数がカンマ区切りで書かれているファイルを処理するプログラムがあるとする。

      ここでファイルがBOM無UTF-8で品名にUTF-8文字が含まれていても、多くの場合プログラムの修正はいらない。でもBOM付だと修正しないと誤動作する。

      • by Anonymous Coward

        そのASCII互換というのはUTF-8を普及させる段階では最大のメリットと言えたでしょう。

        しかしUTF-8が一般化した現時点においては、BOMによってUTF-8であると判定できるメリットが、UTF-8非互換のプログラムを誤動作させるデメリットを上回っていると言えるでしょう。

        • by Anonymous Coward

          3バイトも使うなら、タグでいいんじゃないかって気になるからな。

      • by Anonymous Coward

        CSVを使っているということはお手軽に書いたバッチファイルや簡易的なスクリプトだと思いますが、BOMを無視or削除するなんてコード、原始的なWindowsバッチファイルやシェルスクリプトでも数分あれば書けます。
        古いプログラムなら修正すればいいですし、今時他のユーザ(社内の他の従業員を含む)がBOM付きファイルを処理することすら想定できていないならプログラマーとしての資質に問題があるでしょう。

  • by Anonymous Coward on 2021年06月15日 17時30分 (#4051322)

    これはバグではありません。
    これは仕様です。
    仕様に沿ってお使いください。

    ここに返信
typodupeerror

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

読み込み中...