#Console Logging Encoding Problems
1 messages · Page 1 of 1 (latest)
package me.lianecx.smpplugin;
import java.util.ArrayList;
import java.util.List;
import org.apache.logging.log4j.core.LogEvent;
import org.apache.logging.log4j.core.appender.AbstractAppender;
public class ConsoleLogger extends AbstractAppender {
private boolean isLogging;
private List<String> loggedData;
public ConsoleLogger() {
super("SMP-Plugin", null, null, true);
isLogging = false;
loggedData = new ArrayList<>();
}
public void startLogging() {
isLogging = true;
}
public void stopLogging() {
isLogging = false;
}
public void clearData() {
loggedData.clear();
}
public List<String> getData() {
return new ArrayList<>(loggedData);
}
public void log(String message) {
if (isLogging) {
loggedData.add(message);
}
}
@Override
public boolean isStarted() {
return true;
}
@Override
public void append(LogEvent event) {
log(event.getMessage().getFormattedMessage());
}
}
I also tried this as the constructor ```java
super("SMP-Plugin", null, PatternLayout.newBuilder().withCharset(StandardCharsets.UTF_8).build(), true);
Didnt really change anything
Test if its teh formatting that is breaking it. In append use event.getMessage().toString() to see what the base string is
ok, lets try and fix a few things. You shoudl move off a deprecated constructor java super("SMP-Plugin", null, PatternLayout.newBuilder().withCharset(StandardCharsets.UTF_8).build(), true, Property.EMPTY_ARRAY);
note that im using api version 1.13 and java 8
what is Property
there are a lot of imports avaIlable
no clue
where did you find that
and how do you know its deprecated
theres only these 2 overwrites
okay then thats the problem probably
does your 1.13 have the log4j exploit fix?
it was fixed in Spigot but probably not in paper
it was a remote code execution exploit in log4j
there is a startup switch to preven tit... one sec
-Dlog4j2.formatMsgNoLookups=true
yep
ok lets test, in your appender try java String msg = String.format(Locale.ENGLISH, event.getMessage().getFormattedMessage(), (Object) getPropertyArray()); log(msg);
That way we can see of the encoding is wrong going in
see what msg is after formatting
getPropertyArray()?
just fetches the array that the appended was setup with
does it not exist for yiou?
nope
then use Property.EMPTY_ARRAY
i dont have that either
i can just leave it out
k
if its empty
well it still shows the same thing
Btw, maybe we can change the whole fundamental idea
What im ultimately trying to do is just receive the response of a command which im executing through the plugin
This is unfortunately very hard to do and ive tried some things but the best working one was using the logger which starts logging before i execute the command and immediately stops after
Maybe theres an easier way of doing this
It would solve this problem and be overall probably cleaner
I can't see that log4j would be trying to alter teh encoding at all. There has to somethign funky with how the string is getting to the logger
hmm
but you dont have an idea for another method of doing this?
Not really. The command system isn;t designed to get anything more informative than a yes/no
I'll assume you are sending commands to other plugins
via dispatchCommand?
yea
is there a reason you can;t use the plugins api?
i read theres a way of overriding the sendMessage method of a command sender but that didnt really work for me
oh im not executing commands of other plugins
im executing vanilla commands
ik but theres not really another way of obtaining the response other than this
probably not
where are you displaying the messages that you see the wrong encoding? If as you say they are correct in console and log
in which case it seems the method you are using to send the string across is wrong
or that console is not UTF-8
oof
maybe
How could i find out
its a js app and i tried this
console.log(Buffer.from(respMessage, 'utf-8').toString())
which shouild just convert it to utf8
do you have any pseudo-code?
how are you sending to js?
http response
you can also before sending ensure it is UTF-8 by string.getBytes(StandardCharsets.UTF_8)
include the encoding in teh header and Node should handle it
okay i need a break 😅
Ill come back tomorrow
its not setting the header for some reason
ok
Btw i almost forgot. Another hint that the logger is outputting wrongly encoded strings is that the stripColor method couldnt remove the comor coded and we had to make our own one with the special regex
thats true
And the regex is checking for \x7f
instead of hooking into log4j perhaps you shoudl hook the console
This would give you what is actually being pushed to the console
Btw, i just wanted to thank you for your help. This really means a lot :D
At which logging levels are commands sent?
info
question. the string from yesterday with the 7F at the front. was that the string whilst IN the logger, or after you sent it across to your app?
in that case, there is nothing wrong with your logger
in the minecraft console
This
the issue is purely in how you are sending it to the app
I do.
Because of this
Then why does this regex work and the stripColor one doesnt?
\x7F([(\da-fA-F)])
is that regex done in your MC plugin code or on your app?
its done in my mc plugin
\u00A7
it uses the unicode char
ok
and we use a different char
and ours work
[0-9A-FK-OR]
btw this is correct
we didnt include the reset (r), underlined (l), bold etc
?
yes it needs /i
did you try with the console logger to see what you get there?
im trying rn
k
thats why i wanted to know the level
is it always INFO?
also for syntax exceptions
like when it says
An entity is required blabla
or
I'd not be suprised if it was a log4j issue. That thing is a bitch to work with
you could use .ALL
pretty sure there is an ALL level
well for now you can ignore the level. we just need the message
plugin#getLogger().setUseParentHandler(false);
Plugin#getLogger().addHandler(new LogHandler());```
why do we need this?
that attaches the LogHnadler to teh logger
so its not a global logger?
but that logger doesnt actually log
oh
well um
it threw a bunch of errors
stackoverflow
public class ConsoleLogger extends ConsoleHandler {
private boolean isLogging;
private final List<String> loggedData;
public ConsoleLogger() {
isLogging = false;
loggedData = new ArrayList<>();
}
public void startLogging() {
isLogging = true;
}
public void stopLogging() {
isLogging = false;
}
public void clearData() {
loggedData.clear();
}
public List<String> getData() {
return new ArrayList<>(loggedData);
}
public void log(String message) {
if (isLogging) {
loggedData.add(message);
}
}
@Override
public void publish(LogRecord record) {
System.out.println(record.getLevel().getName());
/* if (record.getLevel() == Level.INFO) {
log(record.getMessage());
}*/
log(record.getMessage());
}
}
i think i cant sysout in the publish method
you can
ah paper, it hates sysout
yea
thats what i said
ill download the new version real quickj
and i also removed the sysout
no errors now
It doesnt seem to work
gets nothing?
odd. I know it works at teh plugin level. I've not used it on the Bukkit logger
but it should. identical loggers
try leaving out the setParentHandlers
allow all handlers to parse the messages
it looks like its just the plugin logger
ah thats a bummer then
or use getLogger passing the Main class of Spigot/paper
From Spigot Main class Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
logger being java.util.logging.Logger;
yes, Spigots Main.class
i dont have Main
its called Main as its an executable
where does it come from
ah you'd need NMS
?
org.bukkit.craftbukkit.Main
nope
how about Logger.getLogger("Minecraft");
how do you know the name is Minecaft?
leave that line out
i did
thats for overriding current handlers to only use ours
should i enabel it?
default is enabled
i mean disable
nope
probably not 🙂
I'm at a loss then
So this is the end result...
ig i dont have any other idea too
ill just use the old logger
the log4j appender
I guess you have no other choice
other unicodes are unchanged so they have to be transmitting incorrectly
somethign between you storing the string and getting it to your app
what?
This wouldnt make sense
if the § is encoded weirdly then so are all the other non-english chars
its not a transmission problem
dont you think so too?
I've no idea how its messing up the color code, but I don;t think its unicode related
if its not related to the encoding then the other characters should be fine
if it is the encoding then ALL unicodes will be broken
and thats whats happening
Anyways, thank you for your amazing help and effort :D
Ive reached my main goal which is removing the color codes
