Unicode署名BOMによる事故原因の分析

今日、JS スクリプトを書いているときに別の BOM 事故に遭遇しました。
外部 JS をページに挿入したところ、その中に次の文がありました: $.getJSON("/my/newmsg", function(data){alert(data);}); 他のブラウザでは正常にコンテンツがポップアップ表示されましたが、IE では表示されませんでした。私は 1 時間近く落ち込んでいました。この文が間違って書かれているのではないか、JSON データ形式が間違っているのではないか、私の性格に問題があるのではないかと思いました...
その後、エンコードが間違っているのではないかと疑い、BOM をチェックしてみました。それを削除するとすぐに、暗雲の下から奇跡が現れました。
私は怠け者でめったにブログを更新しませんが、この事件は本当に予想外だったので思いついて記録しなければなりません。JS も BOM による事故を引き起こす可能性があります - -|

Unicode 仕様には BOM の概念があります。
BOMとはByte Order Markの略で、バイトオーダーマークのことです。これは普通のテキストエディタでは見ることができません。ファイルヘッダーと言えるのでしょうか？バイナリエディタでのみ表示されますか?そうかもしれません。
UCS エンコーディングには、「ZERO WIDTH NO-BREAK SPACE」という文字があり、そのエンコーディングは FEFF です。 FFFE は UCS には存在しない文字なので、実際の送信では表示されません。 UCS 仕様では、バイト ストリームを送信する前に「ZERO WIDTH NO-BREAK SPACE」文字を送信することを推奨しています。このように、受信側が FEFF を受信した場合、バイト ストリームはビッグ エンディアンであることを意味し、FFFE を受信した場合、バイト ストリームはリトルエンディアンであることを意味します。そのため、「ZERO WIDTH NO-BREAK SPACE」という文字は BOM とも呼ばれます。
UTF-8 ではバイト順を示すために BOM は必要ありませんが、エンコードを示すために BOM を使用できます。文字「ZERO WIDTH NO-BREAK SPACE」の UTF-8 エンコードは EF BB BF です。したがって、受信側が EF BB BF で始まるバイト ストリームを受信すると、それが UTF-8 でエンコードされていることがわかります。 Windows は BOM を使用してテキスト ファイルのエンコードをマークします。