The bug
The server.properties file doesn't seems to handle unicode UTF-8 correctly, while still trying to recode it as such. This is most apparent on motd where you can't type non-ascii characters and save it as UTF-8.
For example if trying to change motd to "motd=§lA Minecraft Server", when the server starts, the properties file change it into "motd=\u00C2\u00A7lA Minecraft Server" and the multiplayer screen shows gibberish.
You can though somehow overcome this by encode the file as latin1 (iso-8859-1). While the server.properties still gets changed into "motd=\u00A7lA Minecraft Server", at least it shows up correctly in the multiplayer list.
This happens off course for all non-ascii characters, like ß, Å, etc.
Cause and suggested fix from @unknown:
Looking at the code, the problem here is the use of the java.util.Properties.load(InputStream) and Properties.store(OutputStream, String) methods. Both of these assume the use of ISO 8859-1 encoding, and this cannot be changed. The solution is to use the Properties.load(Reader) and Properties.store(Writer, String) methods instead; InputStreamReader and OutputStreamWriter can be used to wrap the FileInputStream and FileOutputStream respectively and specify the UTF-8 charset.
Linked issues
is duplicated by 1
relates to 1
Attachments
Comments 24
Stumbled upon this one while trying to set fabulous unicode to my motd. This was very frustrating.
I workarounded this bug quickly, since after the first restart i saw it was converting my utf-8 into hex escapes but decoding as latin1. So I simply used a python shell to convert text to unicode escapes.
But on my first test I found out the charset of the multiplayer server list is VERY limited, similar to the charset we had before multilanguage support was added. "áéíóú" work fine, color codes with § work fine (if anyone reading this needs a quick way to insert color codes, use "\u00A7"), but ß or any non-latin1 unicode chars appear as "?".
Setting the client language to pirate or something that uses the alternate font has no effect (Although I noticed §k doesn't work anymore, but that's a different bug I don't care about)
Anyway, if you fix this bug, PLEASE expand the charset of motds on the server list to match the chat. It'd be useless otherwise.
This bug still exists in 1.4.7 server. I'm a bit surprised by this one. Aren't you guys Swedish? Don't you use non-ascii characters?
Looking at the code, the problem here is the use of the java.util.Properties.load(InputStream) and Properties.store(OutputStream, String) methods. Both of these assume the use of ISO 8859-1 encoding, and this cannot be changed. The solution is to use the Properties.load(Reader) and Properties.store(Writer, String) methods instead; InputStreamReader and OutputStreamWriter can be used to wrap the FileInputStream and FileOutputStream respectively and specify the UTF-8 charset.
As for the current behavior, non-ascii characters are encoded as (slightly modified) UTF-8, then written to file as escaped Unicode characters; when read, the escape sequences are handled properly, but it is not converted back into UTF-8. The section sign (§, \u00a7) happens to be encoded as \u00c2\u007a (§), so formatting codes work, aside from adding an extra character. Many other characters do not contain themselves when encoded (such as ÷ (\u00f7), encoded as \u00c3\u00b7 (÷)).
just switch the call from Files.newInputStream/newOutputStream to Files.newBufferedReader/newBufferedWriter and things will be fine. it isn't that hard, just a one line fix in abstract property handler.
boq
Still present in 1.4.4