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

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 on 2018年05月12日 17時42分 (#3407179)

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

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

            そして、BOMのせいで動作しないアプリケーションはUnicode自体に非対応なのだから、Ascii だけ使ってればいいのでは
            BOMで不具合を起こすようなアプリケーションは、UTF-8 が読めているように思えてもたまたま動いているだけで、
            その他のUnicode制御文字も扱えないでしょう
            シェルスクリプトから Ascii しか扱えないような古いスクリプトを呼び出して使いたいとかだったら
            その前にBOM消してから渡す処理書けばいいだけでは、そんなの1分ありゃ書けるでしょ

            UTF-8 において、BOMは必須でも推奨でもないけど、付けたからといって仕様違反ではない
            扱えないアプリがタコ

            親コメント
            • by Anonymous Coward on 2018年05月12日 18時58分 (#3407206)

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

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

              親コメント
              • by Anonymous Coward

                なんというか、考えの浅いやつほど規格をバカ呼ばわりするよね

              • by Anonymous Coward

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

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

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

                ようするに、

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

              • by Anonymous Coward

                そんなもの利点でもなんでもなくてバグと同レベル。そんなものを利用しようという発想からして技術者に向いていないよ。

              • by Anonymous Coward

                ようするに、

                「テキストエディタで 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]

              • 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

              UNIX系のシェルスクリプトとPHPがタコなんだな。
              他で問題になったことはほぼないので。

              • by Anonymous Coward

                まぁ、その「タコな環境」が多く存在するから問題になるんだが。
                BOMってWindowsと規格文書以外には実装しないものってのが話をややこしくしてる。

                マイナーな仕様は「規格」も含めてデファクトスタンダードで上書きされるってのは、
                繰り返してきた歴史でもある。

                # っていうか、先頭の「#!」はUNIX系のシステムコールなのでタコって話じゃないだろ。
                # 歴史的に重要な部分に仕様変更をねじ込むのは規格の方に問題がある。

              • by Anonymous Coward

                The Unicode Consortium の見解としては一律 BOM を付ける/付けないではなく
                適切に選択しろ [unicode.org]ということだから、 BOM が禁止されているシステムではなく
                適切に BOM を付ける/付けないを選択できないユーザーの方がタコということだろう。

            • by Anonymous Coward

              > 扱えないアプリがタコ
              シェル……いやカーネルかも。#!を処理してるの誰だろう。昔のUNIXのカーネルで見たことあるけど。
              色んな環境でファイルをやりとりしてるとたまにシェルスクリプトにBOM入れられることがあるもんで。

            • by Anonymous Coward

              は?
              お前、符号化の仕組みを全く理解してないだろ。
              BOMに文字エンコーディングを判別する役割なんかねぇぞ。
              それにUTF-8はエンディアン関係ない。
              UTF-16等はエンディアンによってバイトオーダー変わるから必要ってだけだ。
              BOMは先頭以外で無視?バカか、バイトをCPUでなくBOMで指定されたエンディアンで処理しないといけないんだからんなわけないだろ。

              • by Anonymous Coward

                みんなUTF-8の話をしていて理解してると思いますよ
                UTF-8のBOMが「バイトオーダーマーク」でないのは事実ですが
                CRもLFも元々の意味と違いますよね?
                そもそも論がしたいならコメント付ける場所間違ってますよ

            • by Anonymous Coward

              シバンが使えなくて困るので却下

            • by Anonymous Coward

              > BOMは文字エンコーディングやエンディアンを確実に判別できるという重要な役割を果たしているわけなんだけど
              UTF-8 にエンディアン関係ないじゃん。
              文字エンコーディングの判別に BOM を使うとか意味が分からない。
              SJISやEUC,JISにもBOMが付いてるとでも思ってるの?
              BOMが付いてる->Unicodeかな?くらいしか判別できないじゃん。

              • by Anonymous Coward

                #3407358と同じACですか?

                UTF-8自体にエンディアンは関係ありませんが
                UTF-8を処理するアプリケーションがどちらのCPUで動くかは関係あります。
                1byteずつ処理すると効率が悪いですから。
                勿論それはBOMの本来機能ではありません(むしろ目的の逆の使い方です)が
                本来機能を支障しない限りどう使おうとアプリケーション側の自由です。

                BOMが付いてる->Unicodeかな?くらいしか判別できないじゃん。

                そうですね。
                でも100%正しく判定できる手段が存在しないことは自明なので
                普通は「実用上十分」くらいの意味に捉えるんじゃないでしょうか。

                あとこの議論は散々なされて新しい建設的で実際的なアイデアなど生まれる余地はないので
                メモ帳の記事でおしゃべりするのはもう止めませんか?

            • by Anonymous Coward

              エディタの仕様としてBOMがついてなければ勝手につけるべきではない
              よって強制でつけるエディタ(Notepad,Sakura)はタコ

              • by Anonymous Coward

                いや、強制で付けてほしい

            • BOM「強制」が問題なのでは
            • by Anonymous Coward

              そういう理想論は今はいいです。

              • by Anonymous Coward

                理想論?
                地に足の着いたというかそれを超えて泥臭い意見だと思うが。
                そういうBOM有りの泥臭さを嫌うなら理解できるが何を理想と思っているのだろうか。

            • by Anonymous Coward

              後方互換性を壊すような規格の方がタコですね。
              そして BOM の解釈は文字コードより上位の規格により規定される事がある。

              例えば JSON は BOM の付与を禁止しました。XMLでは文字コードの判断にはXML宣言より優先してBOMの情報を使うように規定されています。
              「シェルがファイルをテキストとして解釈出来ること」
              「シェルがファイルをシェルスクリプトとして処理できる事」
              は両立しなくても構わないのです。

              そして、シェルスクリプトが動かないのはシェルのせいではありません。

              • by Anonymous Coward

                > 後方互換性を壊すような規格の方がタコですね。

                web屋って本当にバカですね
                必要だから、わざわざ互換性をなくしているのです
                設計ミスではないよ

              • by Anonymous Coward

                コメント付ける場所間違えていませんか?
                他の枝を見て誤解したのだと思いますが
                (#3407179) のどこにもBOM付きのシェルスクリプトの話なんて書いてありませんよ。

                文字コードより上位の規格があればそれに従うのは当然ですね。
                タコと呼ぶにふさわしいアプリにはそういう規格があるのですか?

                後方互換性を壊すという意味も分かりません。
                BOM付きUTF-8は「ASCIIとして扱ってはダメ」という意思表示です。
                JSONがBOMを禁止したのはUTF-8の使用とセットで
                もはやASCII関係ないですよね?

                テキストを食わせる側と読む側の立場の違いを考えてください。
                BOMを除くかどうかは食わせる側が責任を持って判断するべきです。
                テキストエディタが自動で判断できるものではありません。
                (なのでメモ帳がBOMなしUTF-8出力に対応してほしいというのは正当な要求でしょう)
                一方でそう言った面倒を食わせる側に押し付けている読む側アプリは
                タコかどうかともかく親切ではありませんね。

普通のやつらの下を行け -- バッドノウハウ専門家

処理中...