パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Windows 10のメモ帳、CRLF以外の改行コードサポート追加へ」記事へのコメント

  • by Anonymous Coward

    次はデフォルトの文字コードに手を付けてくれたまへ

    • by Anonymous Coward

      Windowsの文字コードって複数あるの?

      • by Anonymous Coward

        メモ帳のだぞ
        デフォルトだとANSIになってる
        他にUnicode、Unicode big endian、UTF-8が使える

        最近はHTMLやソースコード関連がUTF-8推奨なので
        デフォルトをUTF-8に変えても良さそう

        • Re: (スコア:5, すばらしい洞察)

          notepadだど強制的にBOM付というところも改善してほしいところ。
          • by Anonymous Coward

            BOMは文字エンコーディングやエンディアンを確実に判別できるという重要な役割を果たしているわけなんだけど
            それが無かったら判別のためにテキスト全文を読んで、どの文字コードだと解釈すれば矛盾が無いかを評価しなくてはならず
            非常に負荷が高い
            その上、本文が短い場合には複数の文字コードで矛盾が生じないケースもあって、自動判別が不可能な場合まである

            複数のファイルを結合して問題が生じる?
            いや、BOMはファイルの先頭以外では無視しなければならない(幅0の空白文字)仕様なんだから不具合が生じる方がおかしい

            そして、BOMのせいで動作しないアプリケーションはUnico

            • by Anonymous Coward

              何言ってんの、BOM 付き UTF-8 は、UTF-8 の最大の利点である、
              ASCIIの範囲の文字しか使っていない場合は、従来のプレーンテキストと一切変わらず、古いプログラムでもそのまま処理できる
              を投げ捨てているわけで、正直考えた奴は莫迦の極みでしかないエンコーディングなんだが

              # windows 以外ではまず使われることがない、よくある「標準規格からちょっとズレたMS独自仕様」の名残だと思ってる

              • by Anonymous Coward

                あくまでもテキストエディタで UTF-8 を扱う話ですよね

                ASCII 以外で不具合を起こすプログラムで扱うデータを編集するなら、
                文字コードとして ASCII が指定されている設定のテキストエディタを使うべきでしょう

                BOM が含まれるだけで不具合を起こすプログラムならば、
                どっかからコピペしたデータに不可視の UTF-8 制御コードが含まれていたりとか、
                入力ミスでうっかり ASCII外の文字がどっかに混入してしまったりというヒューマンエラーで不具合が起こりかねません

                ようするに、

                「テキストエディタで UTF-8 としてデータを編集するけど
                 万が一 Unicode の制御コードや A

              • by Anonymous Coward on 2018年05月12日 20時07分 (#3407238)

                ようするに、

                「テキストエディタで UTF-8 としてデータを編集するけど
                 万が一 Unicode の制御コードや ASCII外の文字がどっかに混入してしまったら(コピペやキータイプミス)
                 使う先のプログラムで不具合を起こしてしまう」

                というデンジャラスな環境で作業しているってことでしょ?

                あなたは、テキストを入力した環境と、テキストを使用する環境が異なる状況があることを判っていないようですね。

                # いっちゃ悪いが、入出力の環境を指定できるのならば、UTF-8 w/ BOM だろうと、 mule-internal だろうと、オレオレエンコーディングだろうと、好きなエンコーディングを使えば良いんです。

                入出力を揃えられない可能性があるときに、共通規格としてテキストの交換用符号があるわけで..
                元の UTF-8 ができるだけ従来のプログラムでもそのまま使える様に配慮しているのに、BOMがそれをぶち壊しにするわけです。

                BOM は標準規格に存在するんですけど

                規格に入っているけど、歓迎されていない感じしませんか? Unicode 10.0規格(sec 2.6)には

                Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature. See the “Byte Order Mark” subsection in Section 23.8, Specials, for more information.

                とありますし、W3C も、HTMLにおけるBOMの扱いの文章 [w3.org]で

                We strongly recommend that you don't change the encoding of a UTF-8 file from a Unicode encoding to a non-Unicode encoding, but if, for some exceptional reason, you do you must ensure that the BOM is removed. If you don't, either the browser will continue to treat your content as UTF-8, or you will see strange characters at the beginning of the page.

                と書いてます。

                UTF-8 にBOM が許容されている経緯は詳しく知りませんが、Unicode に大きな影響力を持つ MS が広めてしまったので仕方なく許容としたんじゃないかと思ってます。

                # もし、「そうじゃない、UTF-8 に BOM は歓迎されているんだ」という情報をお持ちでしたら、提示していただけるとうれしい

                親コメント
              • by Anonymous Coward

                なんか必死ですね

              • by Anonymous Coward

                あなたは、テキストを入力した環境と、テキストを使用する環境が異なる状況があることを判っていないようですね。

                これが何の反論になっているか、よく意味が分からないのですが。

                Windowsのメモ帳は、BOMの有るファイルも、無いファイルも両方正常に読めますよ。書き込み時にはBOM有りになりますけどね。

                メモ帳で、BOMが入ったら不具合が起こる可能性のあるプログラムで扱うファイルを編集しない限り、何の問題もありません。そして、BOMが入ったら不具合が起こる ASCII 全体のプログラムで扱う可能性のあるデータを出力するなら、エディタのBOM出力の有無に関わらず、そもそも UFT-8 として編集すべきではあり

              • by Anonymous Coward

                そりゃBOMなんて無い方が良い世界でしょう。
                でも歓迎するか否かに関わらずBOMは必要だから
                存在して許容されているんじゃないでしょうか?

                何か前半の話と後半の話が
                全く逆のことを言っているような気がするんですけど。
                HTMLの件に関しては#3407238が何を言いたいのかさっぱり分かりません。

              • by Anonymous Coward on 2018年05月12日 20時45分 (#3407256)

                BOM有りのメリット:
                文字コードやエンディアンの誤認識を防げる

                BOM無しのメリット:
                ASCIIしか扱えないプログラムとの互換性を保てる
                ただし、ASCII文字以外を含めない場合に限る

                BOM無しのメリットが弱すぎると思うのですが
                BOM有りのBOMを消すのは簡単だけど、BOM無しUFT-8で文字コード誤認識を完全に防ぐのは技術的に不可能ですからね

                色々な環境で扱う可能性を考慮するなら、BOMが無いせいで文字コードが誤認識される場合も考慮すべきでは

                親コメント
              • by Anonymous Coward

                BOMなしUTF-8のファイルにEUCのファイルをくっつけて判別不可能なゴミにするのだ
                これを防ぐには入力すべてがUTF-8だということを設計者が保証しなければならないが、素直にBOMなしをはじく方が楽かつ確実ですね

              • by Anonymous Coward

                なんというか、何か問題があるとすぐMSガーとかIEガーとか言って、自分の能力のなさを
                人のせいにする、Web屋によくいるタイプの人のように見えますね。

              • by Anonymous Coward

                > 書き込み時にはBOM有りになりますけどね。
                ここじゃね?

              • by Anonymous Coward

                文字コードが誤認識されて困るケースってあります?

              • by Anonymous Coward

                文字化けでテキストが読めなくなります
                そのままうっかり保存したらもう

              • by Anonymous Coward

                BOM有はBOM有。BOM無しはBOM無しで保存してくれたら何も問題はない。
                強制的にBOMつけるのが問題で、新規でBOM有だけならしょうがない。

              • by Anonymous Coward

                テキストファイルをドキュメントとして考えてるか、言語仕様の一部として考えてるかで全く立場が変わってるよね。

                シェルスクリプトの存在を考慮すればBOMなんて発案されることもないレベルなので、MSの関与が大きいんだろう。
                むしろ知っててライバル勢力に嫌がらせした可能性すらあるんだけど。

                Windows以外の世界では「UTF-8N」が標準なので、仕様改訂があるとすればBOMは廃止もしくは非推奨に変更でしょう。
                そもそもUTF-8は他のコードと誤認されることはないのでBOMは余計なもの。

              • by Anonymous Coward

                個人的にMSに悪意を見出すのは勝手ですが規格は規格です。

                UTF-8は他のコードと誤認されることはない

                斬新な意見ですね。

              • by Anonymous Coward
                反例は?そこまで言うならスグ出せるよね?
              • by Anonymous Coward

                縺ゅ⊇

                # UTF-8はかなり冗長な符号なので他のコードをUTF-8に誤認することは少ないだろうが逆はいくらでも起こる

              • by Anonymous Coward
                だからBOMつけろって言ってんだろ
                話読めてる?
              • by Anonymous Coward

                えぇぇぇぇ。
                (#3407491) は「BOMは余計なもの」って言ってるんだけど、余計だけどつけろってこと?
                それとも(#3407639) は(#3407495) の1行目の反例(?)を聞いてるってこと?

              • by Anonymous Coward

                BOM有りのBOMを消すのは簡単だけど、BOM無しUFT-8で文字コード誤認識を完全に防ぐのは技術的に不可能ですからね

                BOMが有ったところで文字コード誤認識を完全に防ぐのは不可能だよ。

                0xEF 0xBB 0xBF って Shift_JIS-2004 では "鬠ソ" だし、 EUC-JP でも
                "鏤" + (31区の文字の 1バイト目) だから、先頭 3バイトだけ見ても
                Shift_JIS-2004 なのか EUC-JP なのか、それとも BOM 有りの
                UTF-8 なのかすら確定できない。

              • by Anonymous Coward

                まさか完全じゃなきゃ意味がないとでも?

                BOMは先頭にあることに意味があるんです。
                鬠ソや鏤から始まってUTF-8と解釈されて困るテキストがどれだけありますか?
                テキストの途中に文字コードの曖昧さがないことを検証することは非常にコストがかかります。
                マッピングが多対多だからです。
                一方でどうしてもBOM付きUTF-8と解釈されて困るテキストがあったなら
                それについてのみ対策すればいいのです。

              • by Anonymous Coward

                困る困らないじゃなくて、そんなのリッチテキストでやれって話だろ。
                っつか、テキストファイルってUnicode以外は余計なメタデータを含まないraw-dataなんだよ。
                rawだからこそOSが直接解釈できる命令文を埋め込むことが出来たりしたのに、
                「当たり前に出来たこと」をBOMの存在が全てぶち壊している。

                # もう実際のデータではBOM無しばかりになってるから、メモ帳が「データを汚す」こと
                # さえしなければいいだけの話なんだけどな。

              • by Anonymous Coward

                > っつか、テキストファイルってUnicode以外は余計なメタデータを含まないraw-dataなんだよ。

                それでみんな酷い目にあってきたのに、web屋は本当に馬鹿だね

              • by Anonymous Coward

                >まさか完全じゃなきゃ意味がないとでも?

                完全じゃなきゃ意味がないと思っているのは BOM 強制肯定派では?
                BOM があれば完璧だと思ってるから、 UTF-8 では BOM を付けろ、
                あらゆる場面で BOM 付を扱えるようにしろとうるさいんでしょ。

                実際には BOM 付けても完璧じゃないのだから、 OS やシェルの
                ようなシステムの中枢部では、従来の仕様を崩してまでそんな
                あいまいなものに頼った処理を入れるべきではないと思う。

                別に BOM を全否定しているわけじゃないんで、付けてメリットが
                ある場面では付けたって良いとは思うよ。

              • by Anonymous Coward

                なんか「web屋」って単語で煽ってるの1人だと思うんだけど、BOMの件でムカついてるのは主にUNIXユーザだと思うぞ。

              • by Anonymous Coward

                1990年代のunix屋は本当にエンコーディングに苦労していて、高橋さんはニューラルネットワークで判別させるプログラムを書いたりしてたんだけど、
                今日のunix屋は先頭の数バイトの処理もできないボンクラばかりになりましたか

              • by Anonymous Coward

                うーん、完全を求めているところが違う気がします。

                「先頭3ByteがBOMと一致したらそれはUTF-8とみなしてください」という
                紳士協定のようなものなんじゃないでしょうかね。
                文字コードの判定においてではなく
                責任範囲を明確化において完全さを求めていると言えばいいんでしょうか。

              • by Anonymous Coward

                unix屋にとってのBOMは、そんなもの無くても問題なくやってきたのに
                Winやってる奴らが持ち込んできた余計なものなんだよ。
                処理できるできないで言えばできないわけじゃないけど、
                なんでうちらがそんな余計なことをしなきゃいけないんだと怒ってる。

              • by Anonymous Coward

                >BOM無しのメリットが弱すぎると思うのですが

                過去の膨大な ASCII ファイルの資産が、変換なしに扱えるというのが
                どれほど大きいメリットか想像できませんか?

              • by Anonymous Coward
                未来の膨大なBOMつきファイルを変換しなきゃ使えないでしょ
                それはおそらく過去の資産より多い
              • by Anonymous Coward

                BOM を付けない環境向けの資産をわざわざ BOM 付きで残す人がどれだけいるの?

              • by Anonymous Coward

                > unix屋にとってのBOMは、そんなもの無くても問題なくやってきたのに

                ぎゃはははははは

              • by Anonymous Coward

                BOM無しにすることで活用できる(BOM有りでは活用できない)資産は
                ASCIIにのみ対応した「プログラム」であって
                ASCII「テキスト」ではありません。

                ・BOM有りだろうと無しだろうとUTF-8とみなす
                →ASCIIはBOM無しUTF-8として受理される

                ・BOM有りならUTF-8とみなし無いならロケール設定に従う
                →UTF-8, EUC等のASCII互換ロケール設定においてはASCIIは受理される

                ・BOM有りならUTF-8とみなし無いなら文字コード推定を行う
                →ASCIIまたはUTF-8, EUC等のASCII互換文字コードとしてASCIIは受理される

                ASCII互換はUTF-8だけのものではありません。
                ASCIIとの共存は今更心配するような話じゃないのです。

人生unstable -- あるハッカー

処理中...