javaコンパイル時のエラー：不正な文字 '\ufeff' に対する解決策です。

元記事へのリンク： https://blog.csdn.net/shixing_11/article/details/6976900

最近、開発者がxxx.javaファイルをSVN経由で提出し、リリースに問題があるためパッケージをロールバックする必要があり、SCMはxxx.javaファイルをeditplusで開き、新しく追加した行を削除し、パッケージを再コンパイルすると、次の例外が報告されました。

java:[1,0] illegal character: \65279

問題のあるファイルのプロパティをコンパイルする：( 最下行のバイトオーダーマークがUTF-8（BOM）であることに注意 )

通常のファイル属性をコンパイルします。

Byte Order Mark is UTF-8 (BOM)に問題があるようです。問題が確認できなかったので、UltraEditで両方のファイルを開き、16進数で表示すると以下のようになりました。

問題のあるファイルのヘッダーです。

無題のドキュメントヘッダーです。

問題のファイルヘッダの前に3バイトのEF BB BFが追加されているように見えます。

具体的な原因は以下の通りです。

        エディタによっては、utf8ファイルにutf8タグ（editplusではシグネチャと呼ぶ）を追加し、ファイルの先頭に3つの見えない文字（0xEF 0xBB 0xBF、BOM）を挿入し、ユニコードマークアップ（BOM）を表すものがあります。 そこで、この問題を解決する鍵は、このマーカーオプションを削除することであり、以下のように行うことができます。 
        まずeditplusでファイルを開き、DoucumentメニューからPermanet Settingsを選択します。一般、ファイル、ツールの3つのカテゴリがあります。OKをクリックします。中国語版Editplusは、以下のようなメニュー構成で動作します。Document->Parameter Settings->File->UTF-8 signature->Always remove signature->OK , で、ファイルの前にマーカーを付けなくてもUTF-8形式が設定され、最後にutf-8形式で保存されるようになっています。

<スパン 関連情報（抜粋）オンラインはこちら

         UTF-8はバイトを符号化単位とするため、バイトオーダーの問題はない。UTF-16は2バイトを符号化単位としているので、UTF-16のテキストを解釈する前に、まず各符号化単位のバイトオーダーを把握する必要があります。例えば、Unicodeのエンコーディングが"奎"の594Eと"乙"の4E59の場合、UTF-16のバイトストリームを受信すると"594E "というバイトオーダーをマークする推奨方法はBOMですが、BOMはちょっと賢いのです。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を使用することができます。UTF-8の文字 "ZERO WIDTH NO-BREAK SPACE" のエンコーディングはEF BB BFです（読者は先に紹介したエンコーディング方法で確認することができます）。つまり、受信者がEF BB BFで始まるバイト列を受信すれば、それがUTF-8エンコーディングであることがわかるわけです。BOMは、ファイルの先頭にマーカーとして数バイトを追加することが判明しています。

<スパン 読み聞かせの延長。

UTF-8, UTF-16, UTF-32 & BOM。 http://www.unicode.org/faq/utf_bom.html#BOM

W3Cの公式ノートです。 http://www.w3.org/International/questions/qa-utf8-bom