我之前处理过不少多语言日志的编码适配问题，针对你遇到的土耳其字符乱码情况，给你梳理几个关键的排查和解决步骤：

1. 先确认WebSphere日志的原生编码 #

WebSphere的日志编码往往和系统环境或JVM配置挂钩，土耳其语常用的编码是ISO-8859-9或者UTF-8，先搞清楚日志本身的编码：

• 登录WebSphere控制台，路径是服务器 > 服务器类型 > WebSphere应用服务器 > [你的目标服务器] > 日志和跟踪 > JVM日志，查看「标准输出」「标准错误」的编码设置，确认是否是对应土耳其语的编码
• 也可以直接检测日志文件：Linux用file -i your_systemout.log命令，Windows用Notepad++的「编码」菜单查看实际编码

2. 配置Filebeat的编码读取规则 #

Filebeat默认会用系统编码读取日志，如果日志是特定编码，必须在filebeat.yml里明确指定，否则读取时就会乱码：

filebeat.inputs:
- type: log
  paths:
    - /path/to/your/websphere/logs/*.log
  encoding: "iso-8859-9"  # 这里根据你实际检测到的日志编码调整，比如是UTF-8就写"utf-8"

修改完配置后记得重启Filebeat服务：Linux用sudo systemctl restart filebeat，Windows直接重启对应的服务即可

3. 确保Elasticsearch索引支持土耳其语字符 #

Elasticsearch默认的分词器可能对土耳其语字符处理不够友好，建议给WebSphere日志的索引配置专属模板，指定土耳其语分词器：

PUT _template/websphere_logs
{
  "index_patterns": ["websphere-*"],
  "mappings": {
    "properties": {
      "message": {
        "type": "text",
        "analyzer": "turkish"
      }
    }
  }
}

如果已经创建了索引，需要更新字段映射后重新索引数据才能生效

4. 验证Kibana的显示配置 #

Kibana默认用UTF-8渲染内容，只要Elasticsearch里存储的字符编码正确，一般就能正常显示。可以去管理 > 索引模式里检查message字段的类型是否为text，确保没有被错误识别为其他类型。

针对你提供的日志片段验证 #

[09.12.2019 12:05:42:848 EET] 00000150 SystemOut O [ERROR] tr.com.cs.aurora.auroracore.utility.CSException: 通用系统错误：tr.com.cs.banking.corporatecredits.ccsutility.common.bean.exception.CCSRuntimeException 位于第487行
tr.com.cs.aurora.auroracore.utility.CSException：因未针对编号为xxxxxxxx的客户执行企业KKB查询，无法继续！PRO_SME_GET_PC_SCORING_RESULT
tr.com.cs.banking.corporatecredits.ccsproposal.sme.services.ProSmePowerCurveService getScoringResult
位于tr.com.cs.banking.corporatecredits.ccsproposal.proposal.services.ProFiaPointControlService.generateList(ProFiaPointControlService.java:407)
位于sun.reflect.GeneratedMethodAccessor9069.invoke(Unknown Source)
位于sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
位于java.lang.reflect.Method.invoke(Method.java:508)

按上面的步骤配置后，日志里的土耳其语相关内容（比如包名里的tr.com.cs前缀）应该就能正常显示，不会出现乱码。建议先从确认日志原生编码这一步开始排查，这是最常见的问题根源。

内容的提问来源于stack exchange，提问作者byczk