最近下载了最新的Android Studio3.6,发现不管java文件编辑还是xml文件编辑，里边的中文都会显示乱码，但是用NotePad++打开时正常的。在网上找了好久，来回改utf-8,gbk,gb2312,都不正确，根本原因是因为Editor缺失了fallback 字体，导致中文字体在默认的字体下显示错乱。
在Android Studio3.6中如下：
同样的xml文件用NotePad++ 打开就是正常的，如下：
网上很多说法是改Idiea的文件编码，如下图所示：
其实这个只是更改文件默认的编码方式，并不能解决根本问题。
尝试了很多，终于发现原因是没有fallback字体：
共需要修改两处：
1、设置->Editor->Font 修改 Fallback font 为 simsun 宋体
2、设置->Editor->Color Scheme->Color Scheme Font 修改 Fallback font 为 simsun 宋体
操作如下：
register(Boolean.class, new BooleanTypeHandler());
register(boolean.class, new BooleanTypeHandler());
register(JdbcType.BOOLEAN, new BooleanTypeHandler());
register(JdbcType.BIT, new BooleanTypeHandler());
register(Byte.class, new ByteTypeHandler());
register(byte.class, new ByteTypeHandler());
register(JdbcType.TINYINT, new ByteTypeHandler());
register(Short.class, new ShortTypeHandler());
register(short.class, new ShortTypeHandler());
register(JdbcType.SMALLINT, new ShortTypeHandler());
register(Integer.class, new IntegerTypeHandler());
register(int.class, new IntegerTypeHandler());
register(JdbcType.INTEGER, new IntegerTypeHandler());
register(Long.class, new LongTypeHandler());
register(long.class, new LongTypeHandler());
register(Float.class, new FloatTypeHandler());
register(float.class, new FloatTypeHandler());
register(JdbcType.FLOAT, new FloatTypeHandler());
register(Double.class, new DoubleTypeHandler());
register(double.class, new DoubleTypeHandler());
register(JdbcType.DOUBLE, new DoubleTypeHandler());
register(Reader.class, new ClobReaderTypeHandler());
register(String.class, new StringTypeHandler());
register(String.class, JdbcType.CHAR, new StringTypeHandler());
register(String.class, JdbcType.CLOB, new ClobTypeHandler());
register(String.class, JdbcType.VARCHAR, new StringTypeHandler());
register(String.class, JdbcType.LONGVARCHAR, new ClobTypeHandler());
register(String.class, JdbcType.NVARCHAR, new NStringTypeHandler());
register(String.class, JdbcType.NCHAR, new NStringTypeHandler());
register(String.class, JdbcType.NCLOB, new NClobTypeHandler());
register(JdbcType.CHAR, new StringTypeHandler());
register(JdbcType.VARCHAR, new StringTypeHandler());
register(JdbcType.CLOB, new ClobTypeHandler());
register(JdbcType.LONGVARCHAR, new ClobTypeHandler());
register(JdbcType.NVARCHAR, new NStringTypeHandler());
register(JdbcType.NCHAR, new NStringTypeHandler());
register(JdbcType.NCLOB, new NClobTypeHandler());
register(Object.class, JdbcType.ARRAY, new ArrayTypeHandler());
register(JdbcType.ARRAY, new ArrayTypeHandler());
register(BigInteger.class, new BigIntegerTypeHandler());
register(JdbcType.BIGINT, new LongTypeHandler());
register(BigDecimal.class, new BigDecimalTypeHandler());
register(JdbcType.REAL, new BigDecimalTypeHandler());
register(JdbcType.DECIMAL, new BigDecimalTypeHandler());
register(JdbcType.NUMERIC, new BigDecimalTypeHandler());
register(InputStream.class, new BlobInputStreamTypeHandler());
register(Byte[].class, new ByteObjectArrayTypeHandler());
register(Byte[].class, JdbcType.BLOB, new BlobByteObjectArrayTypeHandler());
register(Byte[].class, JdbcType.LONGVARBINARY, new BlobByteObjectArrayTypeHandler());
register(byte[].class, new ByteArrayTypeHandler());
register(byte[].class, JdbcType.BLOB, new BlobTypeHandler());
register(byte[].class, JdbcType.LONGVARBINARY, new BlobTypeHandler());
register(JdbcType.LONGVARBINARY, new BlobTypeHandler());
register(JdbcType.BLOB, new BlobTypeHandler());
register(Object.class, UNKNOWN_TYPE_HANDLER);
register(Object.class, JdbcType.OTHER, UNKNOWN_TYPE_HANDLER);
register(JdbcType.OTHER, UNKNOWN_TYPE_HANDLER);
register(Date.class, new DateTypeHandler());
register(Date.class, JdbcType.DATE, new DateOnlyTypeHandler());
register(Date.class, JdbcType.TIME, new TimeOnlyTypeHandler());
register(JdbcType.TIMESTAMP, new DateTypeHandler());
register(JdbcType.DATE, new DateOnlyTypeHandler());
register(JdbcType.TIME, new TimeOnlyTypeHandler());
register(java.sql.Date.class, new SqlDateTypeHandler());
register(java.sql.Time.class, new SqlTimeTypeHandler());
register(java.sql.Timestamp.class, new SqlTimestampTypeHandler());
把npm更新到v5.x.x以后, 会出现一种新的自动生成文件 – Package-lock.json. 如果打开这个文件, 会发现它看着像package.json里面的依赖.
package.json和package-lock.json前, 需要先了解semver 语义化版本号变更. 它是npm依赖管理背后的精髓. 点这里了解npm是如何使用它的. 总的来说, 所谓的语义化版本号变更, 就是当你修改了你所维护的第三方库时, 告诉那些使用了你的库的项目, 你做的是哪种修改. 一个版本号分为三个部分: X,Y,Z. X表示主版本号, Y表示次版本号, Z表示补丁更新. 当你只是简单的修复了BUG, 没有做任何新功能的添加, 或者旧功能的修改, 就需要更新补丁号(数值加一等等). 当你添加了新的功能, 但没有破坏原有的功能, 就需要更新次版本号. 当你做了重大修改导致新版本不兼容旧的代码时, 就需要更新主版本号.^ 是npm默认的版本符号, 当你使用npm install --save时, npm会自动在package中添加^加上版本号. 例如: npm install --save angular会在package.json中添加"angular": "^1.3.15".这个符号会告诉npm可以安装1.3.15或者一个大于它的版本, 但是要是主版本1下的版本.~同样被用来做npm得版本控制, 例如~1.3.15, 代表了npm可以安装1.3.15或者更高的版本, 与^的区别在于, ~的版本只能开始于次版本号1.3. 它们的作用域不同. 你可以通过npm config set save-prefix='~'将~设置为默认符号.>符号主要是用来指定可以安装beta版本.当你添加了一个依赖时, package.json里面会加一项条目, 包含包的名称, 并且使用semver来处理版本号. npm支持版本号中包含通配符. 一般来说, npm会安装最新的版本的依赖, 并且在版本号前面加上^符号, 比如^1.2.12. 这表示, 至少要安装1.2.12的版本, 但更高的版本也可以, 只要主版本号也为1就行. 因为补丁号和次版本号的变动不会变更已有的API. 你应该可以安全地使用任何主版本一致的更高版本依赖. 你可以点击这里的版本计算器, 了解通配符的含义.
把依赖记录在package.json里面的优点是, 只要别人可以访问package.json, 他就可以安装里面所记录的依赖, 然后就可以直接运行你的项目了. 不过有些时候, 这样子会出现一个问题.
比如我们的项目用了express这个框架. 我们使用npm init初始化项目后, 使用命令npm install express –save安装了依赖. express的版本号是4.15.4, 所以package.json里面express的版本号会是^4.15.4, 然后电脑上面就安装了版本为4.15.4的express. 然后可能第二天, express的维护者修复了一个BUG, 现在最新版本变成了4.15.5. 接着, 有个人觉得我们的项目很不错, 他想贡献一些代码, 于是它clone下来, 运行了npm install. 由于最新express版本是4.15.5, 并且主版本号也是一致的, 因此他的电脑上安装的版本就是4.15.5. 我们都安装了express, 但是版本却不一样.
理论上来说, 这两个版本应该是兼容的, 但是可能那个修复的BUG影响到了我们所使用的功能, 使得在这两个不同的版本上出现不同运行结果.
package-lock.json诞生的目的是为了防止出现我们上述的情况. 同一个package.json却产生了不同的运行结果. package-lock.json在npm 5时添加进来, 所以如果你使用5以上的版本, 你就会看到这个文件, 除非你手动禁用掉它. 所以从此以后npm会根据package-lock.json里的内容来处理和安装依赖而不是根据package.json. 因为pacakge-lock.json给每个依赖标明了版本, 获取地址和哈希值, 使得每次安装都会出现相同的结果. 不管你在什么机器上面或什么时候安装。
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json. It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates. This file is intended to be committed into source repositories, and serves various purposes.
大概意思是, 当我们对node_modules或者package.json进行了更改后, package-lock.json文件会自动生成. 里面会描述上一次更改后的确切的依赖管理树. 里面包含了唯一的版本号和相关的包信息. 之后的npm install会根据package-lock.json文件进行安装, 保证不同环境, 不同时间下的依赖是一样的.
还有一个好处是, 由于package-lock.json文件中记录了下载源地址, 可以加快我们的npm install速度
package-lock.json是一个包含你所有依赖的巨大列表, 它包含明确的版本号(没有通配符), 依赖的获取地址, 一个用于验证完整性和正确性的哈希值, 以及这个依赖本身所需要的依赖.
"express": {
"version": "4.15.4",
"resolved": "https://registry.npmjs.org/express/-/express-4.15.4.tgz",
"integrity": "sha1-Ay4iU0ic+PzgJma+yj0R7XotrtE=",
"requires": {
"accepts": "1.3.3",
"array-flatten": "1.1.1",
"content-disposition": "0.5.2",
"content-type": "1.0.2",
"cookie": "0.3.1",
"cookie-signature": "1.0.6",
"debug": "2.6.8",
"depd": "1.1.1",
"encodeurl": "1.0.1",
"escape-html": "1.0.3",
"etag": "1.8.0",
"finalhandler": "1.0.4",
"fresh": "0.5.0",
"merge-descriptors": "1.0.1",
"methods": "1.1.2",
"on-finished": "2.3.0",
"parseurl": "1.3.1",
"path-to-regexp": "0.1.7",
"proxy-addr": "1.1.5",
"qs": "6.5.0",
"range-parser": "1.2.0",
"send": "0.15.4",
"serve-static": "1.12.4",
"setprototypeof": "1.0.3",
"statuses": "1.3.1",
"type-is": "1.6.15",
"utils-merge": "1.0.0",
"vary": "1.1.1"
}
},
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
而通常我们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”。
第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项。
举例说明：
在上面的表中，“家庭信息”和“学校信息”列均不满足原子性的要求，故不满足第一范式，调整如下：
可见，调整后的每一列都是不可再分的，因此满足第一范式（1NF）；
第二范式（2NF）：在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。
举例说明：
在上图所示的情况中，同一个订单中可能包含不同的产品，因此主键必须是“订单号”和“产品号”联合组成，
但可以发现，产品数量、产品折扣、产品价格与“订单号”和“产品号”都相关，但是订单金额和订单时间仅与“订单号”相关，与“产品号”无关，
这样就不满足第二范式的要求，调整如下，需分成两个表：
第三范式（3NF）：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
举例说明：
上表中，所有属性都完全依赖于学号，所以满足第二范式，但是“班主任性别”和“班主任年龄”直接依赖的是“班主任姓名”，
而不是主键“学号”，所以需做如下调整：
这样以来，就满足了第三范式的要求。
ps:如果把上表中的班主任姓名改成班主任教工号可能更确切，更符合实际情况，不过只要能理解就行。
git中都fetch命令是将远程分支的最新内容拉到了本地，但是fetch后是看不到变化的，在tortoiseGit中使用switch/checkout查看当前分支，发现此时后本地多了一个FETCH_HEAD的指针，checkout到该指针后可以查看远程分支的最新内容。然后checkout到master分支，执行metch,选中FETCH_HEAD指针,合并后如果出现冲突则解决冲突，最后commit。
pull的作用就相当于fetch和merge，自动合并：
git fetch origin master
git merge FETCH_HEAD
然后需要手动解决冲突，并commit。
分支的概念：
分支是用来标记特定代码的提交，每一个分支通过SHA1sum值来标识，所以对分支的操作是轻量级的，你改变的仅仅是SHA1sum值。
如下图所示，当前有2个分支，A,C,E属于master分支，而A,B，D,F属于dev分支。
A----C----E（master）
\
B---D---F(dev)
它们的head指针分别指向E和F，对上述做如下操作：
git checkout master
git merge dev
之后的情形是这样的：
A---C---E---G(master)
\ /
B---D---F（dev）
现在A，B,C,D,E,F,G属于master，G是一次合并后的结果，是将E和Ｆ的代码合并后的结果，可能会出现冲突。而A,B，D,F依然属于dev分支。可以继续在dev的分支上进行开发:
A---C---E---G---H(master)
\ /
B---D---F---I（dev）
理解gitfetch,关键是理解FETCH_HEAD，FETCH_HEAD指的是：某个branch在服务器上的最新状态。
一般来说，存在2种情况：
如果没有显示地指定远程分支，则远程分支的master将作为默认的FETCH_HEAD。
如：git fetch origin或者git fetch origin master
如果指定了远程分支，则将这个远程分支作为FETCG_HEAD。
如：git fetch origin dev设定当前分支的FETCG_HEAD为远程服务器的dev分支。它就相当于git pull origin dev的第一步，并不会在本地创建新的分支。另外git fetch origin dev这个命令可以用来测试远程分支dev是否存在。
git fetch origin dev :branch1
上面这个命令的执行过程如下
fast forward，则会自动合并这2个分支，否则会阻止以上的操作。