Reputation: 251
I just added
implementation 'org.zalando:logbook-parent:2.14.0'
to my project based on 'org.springframework.boot' version '2.4.3' and Java 11.
In application.yml next properties:
logbook:
format:
style: http
logging:
level:
org:
hibernate:
SQL: DEBUG
springframework:
web: DEBUG
security: INFO
zalando:
logbook: TRACE
log from spring is OK, looks like "bankName": "ПОЧТА банк"
but zalando.logbook: "bankName":"ПОЧТРбанк"
I add next to build.gradle, but nothing changes.
tasks.withType(JavaCompile) {
options.encoding = 'UTF-8'
}
What I need to do to fix this encoding problem?
Thanks in advance.
Edit: to read logs I use Kibana + Elastic
Upvotes: 0
Views: 1464
Reputation: 103263
When strings get longer that generally means that some translation step receives bytes that are intended to be treated as UTF-8, but is being read with ISO-8859 or Cp1252 or some similar aged encoding instead.
Here's the full process. Every time we flip from bytes to chars or vice versa, a charset encoding is involved. If the wrong encoding is involved in even a single step, the end result is completely mangled. They all have to align (they all have to be UTF-8). Be aware that all files are bytes and not characters in nature.
You wrote explicit non-ascii characters in your source code. A java source file is bytes, so when you type a cyrillic character, it shows up on your screen as a cyrillic character in your java source file, but when happens when you hit file/save? You'll need to check your editor. Open up the editor, open a file with cyrillic characters, and check the encoding. On eclipse, you'd click the File menu and hit the Properties option while the file is open. The encoding is listed on the bottom of the 'Resource' panel, in the section 'Text file encoding'.
Javac needs to read that file. The option you pasted (options.encoding = 'UTF-8'
) in your gradle file takes care of this.
As I said, all files are bytes, so when you open any text file, you must choose an encoding! Many smart text editors will take a wild guess but some just assume a certain encoding. Check your editor - there's generally an option to pick which encoding the file is in. Text files do not contain within themselves the encoding that was used, except in very rare circumstances (generally a BOM which can be encoded in all UTF flavours, but that's unique to UTF specifically, and isn't commonly added). It is entirely possible there's nothing wrong at all with your code, you're just looking at it with a text editor that isn't told to read it as UTF-8.
If it's none of the above, ouch, then this becomes much more difficult: Logs are sent as strings (which means, encoding isn't a thing, fortunately, and no mangling can occur) inside the JVM until they arrive at a so-called 'client' or 'log backend' which then does whatever it wants with them: Log systems are abstract concepts. Handlers are intentionally just 'here you go, a log message at this level, do what you will with it'. If you want to display them with flashing lights on your television, then feel free to write a log client for that that does this.
Your logclient ends up writing the log message into a file, and therefore, it is turning a string into bytes and therefore, it is applying an encoding.
That other answer you found indicates that zalando's logbook library uses the encoding as returned by the servlet runner, and that answer explains how to ensure that's UTF-8. I assume you did that.
Go through all 4 of the above steps:
If you've done all those things, the problem should go away.
Upvotes: 1