附飞书provider地址：https://github.com/tedgxt/keycloak-service-social-lark
场景介绍
在keycloak 8.0.1版本中添加飞书的identity provider，实现基于飞书的第三方免登陆授权。
问题现象
在调用飞书接口获取用户信息时，http response打印出来的名字信息（中文）是乱码。
确定问题边界
步骤一
由于keycloak的框架中，封装了一个SimpleHttp对象，用于http调用。因此得先判断下http client是否该存在问题。
首先通过Postman去调用相同接口，得到response的数据如下。可以看到在postman里显示的中文名字是正常显示的，且response的header中，Content-Type的值为application/json; charset=utf-8。
{
"code": 0,
"data": {
"email": "xiatao.guan@longbridge.sg",
"en_name": "希夏(管峡涛)",
"expires_in": 6900,
"mobile": "+8615968878843",
"name": "希夏(管峡涛)",
"open_id": "ou_a2eba3085ce4b126891bcca48fe23eb3",
"refresh_expires_in": 2591700,
"refresh_token": "ur-D99OWLBARc3ZlD1Js0yqSg",
"tenant_key": "2c81b678d5cf975e",
"token_type": "Bearer",
"union_id": "on_b2455e0574333e08a0ecea8b932deac9",
"user_id": "fg7fe7f5"
},
"msg": "success"
}
步骤二
更进一步，在idea中新开一个java测试工程，导入keycloak相关的maven依赖包，通过keycloak的SimpleHttp client进行接口调用，发现也可以打印出正常的中文。
String profileStr = SimpleHttp.doGet(PROFILE_URL, httpClient).auth(accessToken).asString();
logger.info(profileStr);
步骤三
在keycloak代码中，添加测试代码logger.info("中文")以及System.Out.Println("中文")，查看日志中打印出来的中文也是乱码。
定位结果
综合以上定位过程可以发现，在keycloak的中文字符都不能正常显示。基本可以判断乱码问题与飞书的http调用无关，造成异常的原因应该在运行环境上。
通过对比keycloak和测试工程的环境发现，keycloak本身是运行在jboss中的，而测试工程里代码是跑在idea启动的JVM上。下一步就是要解决jboss的编码问题。
通过Google发现，要解决JVM中的中文编码问题，可以通过配置参数-Dfile.encoding=XXX在启动JVM的时候来指定编码格式，从而不受操作系统和语言环境的影响。file.encoding 会影响未指定编码的字符串、读写文件、URL编码、打印等内容。
在jdk源码中搜索file.encoding，发现被defaultCharset()方法使用了，打开对应文件Charset.java：
/**
* Returns the default charset of this Java virtual machine.
*
* <p> The default charset is determined during virtual-machine startup and
* typically depends upon the locale and charset of the underlying
* operating system.
*
* @return A charset object for the default charset
*
* @since 1.5
*/
public static Charset defaultCharset() {
if (defaultCharset == null) {
synchronized (Charset.class) {
String csn = AccessController.doPrivileged(
new GetPropertyAction("file.encoding"));
Charset cs = lookup(csn);
if (cs != null)
defaultCharset = cs;
else
defaultCharset = forName("UTF-8");
}
}
return defaultCharset;
}
这段注释说明了defaultCharset返回的是JVM的默认编码格式。且该编码格式是在jvm启动时便确定了，且依赖于jvm所在的操作系统的区域以及字符集。从代码中可以看出，defaultCharset()的值就是从 file.encoding这个属性中获取的。
于是在keycloak代码中加入如下代码段，打印出当前的编码配置：
// fix 中文字符问题
Properties initProp = new Properties(System.getProperties());
logger.info("current file.encoding:" + initProp.getProperty("file.encoding"));
logger.info("current Charset.defaultCharset :" + Charset.defaultCharset());
根据打印结果显示，file.encoding和Charset.defaultCharset打印的值都是ASCII，并非期望的UTF-8，这就解释了为何打印中文在日志中显示的都是乱码。
解决过程
知道了要改的内容，接下来解决的过程就比较简单了。通过Google搜索到，jboss是使用standalone.xml作为其启动配置文件。在路径/opt/jboss/keycloak/standalone/configuration中找到了该文件。按照网上的方法，在standalone.xml添加了相关编码配置，然而打开日志一看并没有作用。
于是逐步分析keycloak的启动过程，通过对keycloak的dockerfile层层抽丝剥茧，发现entrypoint调用了standalone.sh，在standalone.sh中又调用了standalone.conf。
bash-4.4$ cat standalone.sh|grep standalone
# Usage : standalone.sh --debug
# standalone.sh --debug 9797
RUN_CONF="$DIRNAME/standalone.conf"
...
...
...
# Read an optional running configuration file
if [ "x$RUN_CONF" = "x" ]; then
RUN_CONF="$DIRNAME/standalone.conf"
fi
再一次Google一下jboss的相关资料，发现jboss是使用standalone.xml作为默认配置，而把standalone.conf作为配置首选项（Linux环境中是standalone.conf，Windows环境是standalone.bat）。这也就说明了为什么修改了standalone.xml后，并没有起作用，还需要检查standalone.conf的配置。
The standalone startup script i.e. *standalone.sh* for OSX/Linux and *standalone.bat* for Windows, utilizes:
- *standalone.conf/standalone.conf.bat*: defines the JVM preferences for the standalone server instance
- *standalone.xml*: defines the default configurations for the server; we can find it under *$JBOSS_HOME/standalone/configuration*.
因此在standalone.conf中添加上配置JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF-8"，重新构建keycloak镜像并启动容器。
在未添加JVM的编码格式时，keycloak的启动日志中JAVA_OPTS如下：
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /opt/jboss/keycloak
JAVA: java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED
=========================================================================
指定了file.encoding=UTF-8后，keycloak的启动日志中可以看到JAVA_OPTS中编码格式为UTF-8。
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /opt/jboss/keycloak
JAVA: java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dfile.encoding=UTF-8 --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED
=========================================================================
打开日志，发现已经可以打印出中文，大功告成。
总结思考
对keycloak、jboss以及jvm基本上算是小白，看到编码问题更是慌了手脚，最终花了一整天的时间才彻底解决这个问题。回想起来，解决该问题的根本因素就是jvm的编码配置。
总结一下几点事后经验：
碰到未知问题，首先确定问题边界，缩小问题定位范围。如用postman调用飞书接口排除飞书server端问题；用logger打印中文字符排除http调用的问题。
要敢于了解系统原理，最好直接去阅读相关源码（时间充足的情况）。本项目最初预期只是写点java代码去开发一个keycloak的provider用于对接飞书，开发、解决问题的过程中却额外涉及了编码、jboss、jvm等新知识，人总是喜欢蹲在熟悉的环境中，为了解决问题只好硬着头皮上了。
构建知识领域地图，不断补全相关知识漏洞。如果对jvm、jboss一开始就很熟悉，想必解决问题的时间可以减半；知识掌握的越多，后续遇到新问题的解决过程就会越顺利。
Google大法好！
