創造を続け、成長を加速させましょう！「ナゲッツデイリーニュープラン・6月アップデートチャレンジ」に参加して2日目です。クリックしてイベントの詳細をご覧ください。
問題解決の概要
解決策は、ファイルのエンコード形式を他のエンコード形式からUTF-8形式に変換することです。
最初の方法：
ステップ1：エラーファイルを開き、以下に示すように、IDEAの右下隅にある[ファイルエンコード]ロゴをクリックします。
GBKなどの別のエンコーディングを選択してください。（私はGBKを選びました）。
ステップ2：ステップ1を繰り返してから、エンコードを選択し直します。つまり、UTF-8エンコードを2回目に選択します。
ステップ3：ええと、3番目のステップはありません。この時点で、問題は解決されているはずです。
2番目の方法：
エディタソフトウェア/IDE（Windowsメモ帳プログラムを除く）を使用して、ファイルコンテンツのコピーを作成して再度保存し、古いファイルを削除します。
原因
以前のプロジェクトはEclipseを使用して開発されました。最近、チームのほとんどの人がIDEAに切り替えています。短期間の使用の観点から、IDEAは現在、Eclipseと比較して「検索」の最良の部分です。
アイデアを使用してMavenプロジェクトをインポートする前は、それは正常でした。最近、アイデアを使用して従来の非Maven Webプロジェクトを開くと、常にさまざまな奇妙なエラーが報告されました。パスが見つからないことが最も広範なカテゴリですが、ほとんどの場合、それらの解決方法を知っています。
今日、奇妙な小さなバグがあります：
赤いテキストは次のとおりです。
Java: 非法字符： '\ufeff'
复制代码奇妙なバグ。そして、間違ったファイルリンクをクリックしてファイルを開くと、ファイルの先頭でカーソルがロックされます。
良い
好奇心から、このエンコーディング\\ufeffが何であるかを確認しましょう。クエリは、これがバイトの格納順序を識別するエンコーディングであることを示しています。
これには名詞BOMが含まれます。
BOM：**バイトオーダーマーク、**中国名は「バイトオーダーマーク」として翻訳されます。UNICODEエンコーディングの漢字は主に2バイトを占めることがわかっていますが、これらの2バイトのうち、ストレージアドレスの上位に格納されているのはどれですか、下位に格納されているのはどれですか。
Unicode编码中，FEFF表明字节流是Big-Endian（大端序，内存低地址存放高位数据），FFFE则表明字节流是Little- Endian（小端序，内存的低地址存放低位数据）。
(可以巧妙区分为：内存低地址存的是低位就是小端序，内存低地址存的是高位就是大端序)
如“0x11223344”，这个变量的高字节是”0x11“，最低字节是为”0x44“，大端存储时为：
| 内存地址 | 数据 | |
|---|---|---|
| 0x0010 | 0x11 | 低内存地址，高位数据 |
| 0x0011 | 0x22 | |
| 0x0012 | 0x33 | |
| 0x0013 | 0x44 | 高内存地址 |
而小端时数据的顺序则是相反的：
| 内存地址 | 数据 | |
|---|---|---|
| 0x0010 | 0x44 | 低内存地址，低位数据 |
| 0x0011 | 0x33 | |
| 0x0012 | 0x22 | |
| 0x0013 | 0x11 | 高内存地址 |
UTF-8-BOM与UTF-8
而UTF-8实际上不需要使用BOM来标识字节顺序。
在使用常用编辑器，如Notepad++时，在编码一栏下拉列表中，我们可以发现，除UTF-8编码外，还有一个UTF-8-BOM编码，而实际是，UTF-8-BOM文件就是比UTF-8文件多出文件头中的三个字节。
我们可以在自己电脑上实验一下，新建TXT文件，然后使用编辑器软件查看分别将其设置为UTF-8与UTF-8-BOM文件时的大小，如上图所示。
Windows基于其历史原因，在使用其记事本工具打开文件时，总是会将文件设置为UTF-8-BOM格式。
所以出现问题的文件大概率是曾经使用windows记事本打开过或者创建的。
借助一些工具，我们可以更直观的理解这一点。
HEX-Editor插件
Notepadd++中的插件HEX-Editor插件可以辅助我们查看文件的十六进制编码，进而帮助理解大端小端。UTF8与UTF-8-BOM等编码格式。
HEX-Editor插件安装
点击Notepadd++菜单栏“插件”->插件管理，查找或搜索"HEX-Editor"，勾选之后，点击右侧“安装”，安装完成之后重启Notepadd++，此时再点击“插件”，可以看到“HEX-Editor”选项，鼠标移动上去之后，可以看到“View in HEX”选项，点击即可查看文件的十六进制编码。
纯数字或字母的UTF-8与UTF-8-BOM
通过Notepadd++我们编辑一个文件，简单的输入“012”，通过操作栏“编码”分别设置为UCS-2大端，UCS-2小端，UTF-8，UTF-8-BOM，其十六进制编码分贝如下：
UCS-2大端：012
UCS-2小端：012
UTF-8：012
UTF-8-BOM：012
在笔者的机器上，一个数字使用Unicode编码时占用两个字节，也就需要约定地位地址到底是存高位数据还是地位数据，此时约定是必要的；而使用UTF-8时，可以看出，其只占用一个字节，约定顺序是没有意义的。
问题来了，一个字节，8位数据肯定是不能表达出所有的中文字符的，那么中文字符又是如何在UTF-8中编码的呢？此时BOM是否需要呢？
中文的UTF-8编码有约定大小端的必要吗
“你好”的UTF-8字节信息：
“你好”的UTF-8-BOM字节信息：
我们通过查询“你”和“好”的UTF-8编码，发现他们分别占用三个字节：“0xE4BDA0”（你）,“0xE5A5BD”（好），编码必然是完整而次序一致的，也就是说，0xE4BDA0不能按照字节逆序成“0xA0BDE4”，这样只会增加解码的计算量。所以，即使多字节情况下，UTF-8仍然不需要去约定字节标识顺序。
解决问题速看
解决的思路是将文件编码格式由其他编码格式转为UTF-8格式。
第一种方式：
第一步：打开报错文件，点击IDEA右下角“FILE ENCODING”标识：如下图：
选择一个其他编码，如GBK。（我选的是GBK）。
第二步：重复步骤一，再将编码选择回来，即第二次选择UTF-8编码。
第三步：嗯，没有第三步，这时候问题应该已经解决了。
第二种方式：
使用编辑器软件/IDE（windows记事本程序除外）将文件内容复制一份重新保存，并删除旧文件。
起因
之前项目均使用eclipse进行开发，最近团队大多数人都在转IDEA，从短期的使用来看，IDEA相比eclipse，目前最优秀的一点是“搜索”，其他部分使用上还没有太大的感觉。
之前使用idea导入maven项目使用均正常，最近使用idea打开传统的非maven web项目总是报出来各种奇怪的错误，路径找不到是最广泛的一类，但大多也知道怎么解决了。
今天遇到了一个奇怪的小错误：
红色文字为：
Java: 非法字符： '\ufeff'
复制代码一个奇怪的错误。而且点击错误文件链接，打开文件，光标锁定在文件的开头位置。
BOM
出于好奇，我们查一下这个编码\\ufeff是个什么东东，查询得知，这是一个标识字节存储顺序的编码。
这个涉及到一个名词：BOM。
BOM：**Byte Order Mark，**中文名译作“字节顺序标记”。我们知道一个UNICODE编码中一个汉字大多数占用2个字节，那个这两个字节哪个存储在存储地址高位，哪个存储在低位呢？
Unicode编码中，FEFF表明字节流是Big-Endian（大端序，内存低地址存放高位数据），FFFE则表明字节流是Little- Endian（小端序，内存的低地址存放低位数据）。
(可以巧妙区分为：内存低地址存的是低位就是小端序，内存低地址存的是高位就是大端序)
如“0x11223344”，这个变量的高字节是”0x11“，最低字节是为”0x44“，大端存储时为：
| 内存地址 | 数据 | |
|---|---|---|
| 0x0010 | 0x11 | 低内存地址，高位数据 |
| 0x0011 | 0x22 | |
| 0x0012 | 0x33 | |
| 0x0013 | 0x44 | 高内存地址 |
而小端时数据的顺序则是相反的：
| 内存地址 | 数据 | |
|---|---|---|
| 0x0010 | 0x44 | 低内存地址，低位数据 |
| 0x0011 | 0x33 | |
| 0x0012 | 0x22 | |
| 0x0013 | 0x11 | 高内存地址 |
UTF-8-BOM与UTF-8
而UTF-8实际上不需要使用BOM来标识字节顺序。
在使用常用编辑器，如Notepad++时，在编码一栏下拉列表中，我们可以发现，除UTF-8编码外，还有一个UTF-8-BOM编码，而实际是，UTF-8-BOM文件就是比UTF-8文件多出文件头中的三个字节。
我们可以在自己电脑上实验一下，新建TXT文件，然后使用编辑器软件查看分别将其设置为UTF-8与UTF-8-BOM文件时的大小，如上图所示。
Windows基于其历史原因，在使用其记事本工具打开文件时，总是会将文件设置为UTF-8-BOM格式。
所以出现问题的文件大概率是曾经使用windows记事本打开过或者创建的。
借助一些工具，我们可以更直观的理解这一点。
HEX-Editor插件
Notepadd++中的插件HEX-Editor插件可以辅助我们查看文件的十六进制编码，进而帮助理解大端小端。UTF8与UTF-8-BOM等编码格式。
HEX-Editor插件安装
点击Notepadd++菜单栏“插件”->插件管理，查找或搜索"HEX-Editor"，勾选之后，点击右侧“安装”，安装完成之后重启Notepadd++，此时再点击“插件”，可以看到“HEX-Editor”选项，鼠标移动上去之后，可以看到“View in HEX”选项，点击即可查看文件的十六进制编码。
纯数字或字母的UTF-8与UTF-8-BOM
通过Notepadd++我们编辑一个文件，简单的输入“012”，通过操作栏“编码”分别设置为UCS-2大端，UCS-2小端，UTF-8，UTF-8-BOM，其十六进制编码分贝如下：
UCS-2大端：012
UCS-2小端：012
UTF-8：012
UTF-8-BOM：012
著者のマシンでは、数値をUnicodeでエンコードする場合、2バイトを占めるため、ステータスアドレスに上位データとステータスデータのどちらを格納するかについて合意する必要があります。この場合、UTFを使用する場合は合意が必要です。 -8、1バイトしか占有せず、合意された順序は無意味であることがわかります。
問題は、1バイトの8ビットデータではすべての漢字を表現できないということです。それでは、漢字はUTF-8でどのようにエンコードされるのでしょうか。この時点でBOMは必要ですか？
中国語のUTF-8エンコーディングはサイズの終わりに同意する必要がありますか？
「hello」のUTF-8バイト情報：
UTF-8-「hello」のBOMバイト情報：
「you」と「good」のUTF-8エンコーディングをクエリすると、それぞれ3バイトを占めることがわかりました。「0xE4BDA0」（あなた）、「0xE5A5BD」（良い）、エンコーディングは完全で一貫している必要があります。つまり、Say 、0xE4BDA0を逆バイト順で「0xA0BDE4」にすることはできません。これにより、デコードの計算が複雑になるだけです。したがって、マルチバイトの場合でも、UTF-8はバイト識別の順序について合意する必要はありません。