3.3.3 比较一下ConvertToUTF8插件安装前后sublime的变化
- 安装前：
- 安装后：
3.3.4 一个小 bug 的解决
你可以发现，我们出现了两次(如果你没有出现，可能需要等一下就会出现，如果你没出现就直接跳过 3.4 节)，这是为什么呢?
其实不解决也没问题，但我又强迫症哈。我们再打开 Packages 目录看下：
因此要解决这个其实很简单了，我们直接删除 ConvertToUTF8-1.2.13 ，留下自动生成的 ConvertToUTF8 即可，删除后的效果：
我们再来看看sublime的文件选项，就没有显示两次啦：
3.4 🚩 创建文件，设置编码格式，编写完成后 另存为
3.4.1 创建新文件
3.4.2 如果代码中含有中文，设置文件编码为GBK
如果代码中不带中文，则不需要进行这一步，直接创建完新文件编写代码即可。
3.4.3 编写代码
//带了中文的代码 public class Tree { public static void main(String[] args){ Living tree=new Living (); tree.say(); } } class Living { public void say(){ System.out.println("我是一棵树"); } }
3.4.3 文件 -> 另存为
3.5 验证 javac 可行性
在我们刚才 保存Tree.java文件 的目录下打开cmd控制台，执行 javac Tree.java。生成了两个 .class 文件则说明执行成功。
3.6 一个小 bug 的补充
如果你下次打开 Tree.java 时发现里面的中文变成了乱码，只需要执行 文件选项 中的 Reload with Encoding 即可。
为什么会出现这种情况呢？因为你在打开文件的时候，计算机可能是以 UTF8 的格式给你解码文件的，而我们的Tree.java文件是以 GBK 方式编码。因此计算机在以 UTF8格式 解码时无法解析文件中的 GBK编码格式的中文，导致UTF8格式解析成了乱码。
所以解决这个也很简单，执行
Reload with Encoding 的 GBK选项 即以GBK方式重新解码。
4.补充：对于为什么cmd，或者说windows采用GBK而非UTF8的理解
- 一方面是由于历史原因，Windows支持GBK的时候UTF-8还没有普及，而微软是一家及其看重存量客户和兼容性的公司，形成了路径依赖不能轻易改变。
UTF-8只是在存储欧洲语言文字方面有优势。由于兼容ASCII，UTF-8存储拉丁字母、数字、半角标点等字符使用1个字节，存储其他非拉丁字母的欧洲文字通常使用2个字节，但存储东亚文字，如汉字、日本假名、韩国谚文等，则使用3个字节，少数不常见的字符则用4个字节。而UTF-16对大多数常见语言文字统一使用2个字节，少数字符使用4个字节。
因此，UTF-8在东亚地区并非最佳存储和传输方案，它的真正优势在于实现Unicode的同时兼容ASCII编码。 - 另一方面，
GBK编码的特点是 英文占1个字节，中文占两个字节。而UTF8编码的特点是 中英文统一占三个字节。而我们知道在计算机存储方面几乎绝大部分都是英文，因此存储上GBK的优势就很明显，相较于 UTF8 能够大大的节省空间。
