>>294
同じことを繰り返しますが、
①過去、エンコードの違うテキストを各種取り扱っていたからといって、「テキストの内部に恣意的にエンコードを示すマークを入れる」などという自己中心的なことをした歴史はなかったのです。
　特にそういうことをしたいときは、ソースコードにその言語のコメントでエンコードを示す、くらいの配慮をしていたものです
②UTF-8 でエンコードされている限り、そのコンテンツがアスキーコードのみで構成されているのならば、特にバイトオーダーコードは不要で、as is で使えるように、欧米諸国に配慮した設計です

特に②が重要で、バイトオーダーコードを要れずとも、C のソースコードは UTF-8 であれば普通にコンパイルできる、はず、なのに、なぜわざわざバイトオーダーコードを付加して既存の処理系がそのままでは使えなくなってしまったのか？
コンパイラは MS-VC だけではなく、gcc も clang も lsi-c （ｗ）もあるというのに、既存のコンパイラの動作を妨害してまで、バイトオーダーコードを付加するエディター側の方が自己中心的といえるのではないでしょうか？
そしてエンコードを示すマークなどではないバイトオーダーマークをエンコード種を示すマークに乱用するしている二重の矛盾も指摘しなければなりますまい

私の言っていることがわかりますか？