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

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

  • by Anonymous Coward on 2018年05月12日 11時44分 (#3407011)

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

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

      うむ。

      しかし20年前にやって欲しかったよなw

      親コメント
      • by BlueRain (37857) on 2018年05月12日 12時55分 (#3407039)
        ちょっとしたテキストをnotepadを起動すると勝手にwordpadにされてしまったのでWindowsでそこそこ使えるエディターが出てきたら普通にエディターを使うようになりました。

        そういえば全然ハイパーでないハイパーターミナルも緊急時には使っていたけどDOS窓でDOSの通信ソフトを動かした方がまともだったりしたなぁ。
        親コメント
      • by Anonymous Coward

        確かに今更感はありますねw

        ※マルチプラットフォーム開発だと地味に面倒くさい

        • by Anonymous Coward

          PHPがプラットフォーム関係なくLFだぞって規格で決めててくれるのありがたいね。

          • by Anonymous Coward

            いやPHPは存在そのものが迷惑だから……

      • by Anonymous Coward

        20年前ってUTF-8あったっけ。
        (ググる)
        92年生まれらしいから93年のWindows NTに間に合わせようと思えば間に合ったのか。

    • by Anonymous Coward

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

      • Re:いいぞ (スコア:3, 参考になる)

        by Anonymous Coward on 2018年05月12日 12時02分 (#3407020)

        ありますよ。
        日本語版WindowsはデフォルトではShift_JISの派生のCP932ですし、各言語でデフォルトの文字コードが違います。
        関連ストーリーでUTF-8をデフォルトに変更可能になった [srad.jp]というのも有ります。
        その気になればMacの文字コードやメインフレームに使われていたEBCDICも扱えます。
        参考:扱える文字コード一覧 [microsoft.com]

        親コメント
        • by Anonymous Coward

          > その気になればMacの文字コードやメインフレームに使われていたEBCDICも扱えます。

          え、これは初耳と思ったが、「Macの文字コード」や、「EBCDIC」も使えるって話か
          なーんだ。

        • by Anonymous Coward

          こんなところでEBCDICが出てくるとは
          コードページなんてDOS窓の中だけの話だと思ってたよ......

      • by Anonymous Coward

        地域と言語によって違ってたはず。

      • by Anonymous Coward

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

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

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

          by miishika (12648) on 2018年05月12日 13時03分 (#3407045) 日記
          notepadだど強制的にBOM付というところも改善してほしいところ。
          親コメント
          • by Anonymous Coward on 2018年05月12日 15時19分 (#3407116)

            いや、むしろ他がBOMを必須にしてほしい

            親コメント
            • by Anonymous Coward

              必須じゃなくていいけどちゃんと受け付けるようにしてほしい

              • by Anonymous Coward

                最悪受け付けないなら受け付けないでいいけど、BOM対応してないプログラムにBOM付きテキスト食わせて
                自分以外の何かの所為にするバカを黙らせて欲しい。

              • by Anonymous Coward

                UnicodeコンソーシアムがBOM対応してないプログラムに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

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

              • by Anonymous Coward

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

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

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

            • 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困るよね。
            スクリプトとか設定ファイルとかメモ帳で弄っちゃって、BOMのせいで動作しないってケースが希にある。

            • by Anonymous Coward

              改行コードが CRLF になっているくらいで command not found とか言う
              シェルのうんこっぷりを直す方が良い気がする。頑なにCRを無視するように
              しないのは、したらいけない理由がなんかあるんだろうか

              • by Anonymous Coward

                シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。
                あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。
                Windowsで言えばexeファイルの先頭が「0x5A4D」以外でも動作しろって言ってるレベルで酷い。

                OSは#!で始まるファイルが起動されたら、それが参照するバイナリをロードするって厳然とした規格なので
                1行目だけは「柔軟な対応」は出来ないし、やってはいけない。
                2行目以降なら起動されたプログラム側(/bin/shや/usr/bin/perlなど)が好きに処理できるが。

                https://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%90%E3%83%B3_(Unix) [wikipedia.org]

              • by Anonymous Coward

                シェルスクリプトってものが分かってない奴が好き勝手に書いてるな。
                あれは人間から見たらテキストファイルだけど、カーネルから見たらプログラム(実行ファイル)だぞ。

                だから何なの?
                "#!" の前に Unicode の BOM を認めらばよいだけ。
                #! (BOM無し)
                0xEF 0xBB 0xBF #! (UTF-8)
                0xFE 0xFF #! (UTF-16 BE)
                0xFF 0xFE #! (UTF-16 LE)
                0x00 0x00 0xFE 0xFF #! (UTF-32 BE)
                0xFF 0xFE 0x00 0x00 #! (UTF-32 LE)
                上記の6通りを実行できるようにカーネルを書き換えれば良いだけ。
                何故やってはいけないの?
                セキュリテ

              • by Anonymous Coward

                プロセス起動に分岐なんて入れたら全プロセスが単純に6倍遅くなるぞ。
                バカじゃねーの?

              • by Anonymous Coward

                ぜひパッチを作ってLinux Kernelへ貢献してください。

      • by Anonymous Coward

        PCゲームの海外版の開発に関わっていたとき、あるキャラクタのロードでクラッシュするという謎の現象を追いかけていたらテクスチャのファイル名にいわゆる全角の漢字が含まれていたのが原因だった。

    • by Anonymous Coward

      世界で初めてデフォルトの文字コードがUTF-128 [ietf.org]なOSとなるのですね。わかります。

    • by Anonymous Coward

      Notepadのですか?Windowsのですか?
      Windowsのなら10ならβですけどUTF_8モードありますよ

弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家

処理中...