问题：使用Kettle的表输入——字段选择——表输出流程中，将数据表写入到GaussDB表时，发现部分表出现了中文乱码，在Kettle的preview data预览的数据也是中文乱码。
1、处理步骤一:
在spoon.bat 的 set PENTAHO_DI_JAVA_OPTIONS后面加上参数 -Dfile.encoding=UTF-8，
这个方式可以解决Kettle可视化图形页面抽数中文乱码的问题，但是会导致自己写的bat脚本重定向日志里的中文乱码，于是出现了 表字段编码、Kettle端的编码、bat脚本的重定向日志里的编码冲突的现状。
2、处理步骤二：
由于是部分表出现中文乱码的现象，查了中文乱码表和正常表的字段编码
select * from information_schema.columns where table_schema='SchemaName' and table_name ='TableName'发现中文乱码和正常表的 data_type 字段编码都是 character varying，且character_set_name都是null，这说明该字段未显式指定字符集，而是继承数据库的默认字符集。
查询数据库的默认编码是UTF8
show server_encoding;在Kettle的表输入控件查询客户端编码是UTF8
SHOW CLIENT_ENCODING;Kettle的表输入控件右键，有一个“显示输出字段”，可以看到乱码字段的存储是 binary-string。这说明在Kettle处理数据的链路中出现了隐形转换。
3、处理步骤三：
GaussDB的数据库URL加参数：&clientEncoding=UTF8&serverEncoding=UTF8&stringtype=unspecified&characterEncoding=UTF8（无效）
参数说明：
clientEncoding=UTF8&serverEncoding=UTF：显示指定客户端和数据库服务器端的字符编码
stringtype=unspecified：强制JDBC将字符串按原始UTF8编码
characterEncoding=UTF8：兜底驱动层编码解析
这个步骤中得到的结果是：表输入的preview data是乱码；字段选择的preview data是乱码；表输出的preview data和结果是乱码。
4、处理步骤四：
在处理步骤二时，知道了乱码的存储是binary-string，编辑字段选择控件，有Encoding列，对String类型的Encoding列选择 UTF8。
这个步骤中得到的结果是：表输入的preview data是乱码；字段选择的preview data是正常的；表输出的preview data和结果是正常的。这个处理不需要在数据库URL后加字符编码参数。
总结：使用Kettle对数据流进行处理时，字符编码会存在隐形转换，最好使用字段选择的Encoding显示字段字符集。