Android Studio3.6编辑器中文乱码

最近下载了最新的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 宋体

操作如下:

Mybatis中自动注册的TypeHandler

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());

package.json和package-lock.json的区别

介绍


把npm更新到v5.x.x以后, 会出现一种新的自动生成文件 – Package-lock.json. 如果打开这个文件, 会发现它看着像package.json里面的依赖.

背景知识


  • 在解package.jsonpackage-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-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"
  }
},

官方文档

package-lock.json

[GIT] git中fetch和pull的区别

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和F的代码合并后的结果,可能会出现冲突。而A,B,D,F依然属于dev分支。可以继续在dev的分支上进行开发:

A---C---E---G---H(master)
 \         /
  B---D---F---I(dev)

理解gitfetch,关键是理解FETCH_HEADFETCH_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

上面这个命令的执行过程如下

  1. 首先执行上面的fetch操作
  2. 使用远程dev分支在本地创建branch1分支(但不会切换到该分支)
  3. 如果本地不存在branch1分支,则会自动创建一个新的branch1分支,如果存在branch1分支,并且是fast forward,则会自动合并这2个分支,否则会阻止以上的操作。

Mysql 工具集

1. 查询所有的表名

select column_name from information_schema.columns where table_schema='your schema' and table_name='table name'

2. dump/restore

mysql -uroot -h -p -P3306   < tbike.sql;
mysqldump -h -P3306 -uroot -p  > tbike.sql;

3.修改blob的大小

mysql根据配置文件会限制server接受的数据包大小。
有时候大的插入和更新会被max_allowed_packet 参数限制掉,导致失败。
查看目前配置  
show VARIABLES like '%max_allowed_packet%';
显示的结果为:
 
+--------------------+---------+
| Variable_name      | Value   |
+--------------------+---------+
| max_allowed_packet | 1048576 |
+--------------------+---------+