MC-2215Encoding errors in server.properties
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 Orthotope:
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
NormalCreated Issue:
Encoding errors in server.properties
The server.properties files 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 utf8.
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...
Environment
Debian, java 1.7.0_07
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.2.8 ? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
The server.properties files 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 utf8.
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 Orthotope:
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.
Is this still an issue in the current Minecraft Snapshot 15w49b or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
Debian, java 1.7.0_07 (oracle)
![[Mod] Pokechu22](../../../data/avatars/users/92931.png){kind=small}
The server.properties file
sdoesn'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 asutf8.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 Orthotope: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.
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 Orthotope:
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.
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 Orthotope:
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.
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 Orthotope:
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.
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] Jarl-Penguin](../../../data/avatars/users/92849.png){kind=small}
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
relates to
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mojang] Bartosz Bok](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Bartosz Bok![[Bot] Piston](../../../data/avatars/users/31202.png){kind=small}
Thank you for your report!
We're tracking this issue in MC-2215, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! The ticket was resolved by one of our moderators, and I left this message to give more information to you.
Still present in 1.4.4
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?
Still affects 1.5.
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 (÷)).
I can still reproduce this issue on 1.6.2 server/client.
And when I set Japanese characters on server.properties file like this:
the client don't show them properly.
This is still a problem with 1.7.2. How do you update the affected versions?
Is this still a concern in the latest Minecraft version 14w08a? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Still broken in 14w08a.
I did that for world with the random characters thing and file name was the sish thing then k and in server.propertys it was that weird coding and the server ran the file I wanted so no effect
the changeing of what you type, I can confirm, however that it changes to weird text I cannot because it has always worked for me propperly
Is this still a concern in the current Minecraft version 14w21b / Launcher version 1.4.4 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
you mean 27b
"Resolved - awaiting response"? Wat.
Still happening with minecraft_server.1.8.1-pre1.jar
Still broken in 1.8 despite what the status says. Also why is it "unconfirmed"?
OK so I don't know a lot about this weird coding stuff but I can say that even though its changing the text for me it still runs fine no weird text on my server more even though it does not use ¢ looking thing (on tablet sorry) and its in color and all so I don't get how this is a bug
§ is not the only non-ascii character in the world. You may not need characters outside of the ASCII set, but other people do.
That's supposed to read "ばか".
Confirmed for
Still present in the 1.14.4 jar.
(Feels weird to report it, though, because it's more of a feature request to support unicode.)
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.
Confirmed in 1.16.1 and 20w27a.
Confirmed (Still) in 1.18.2 on FreeBSD
Can confirm in 23w05a and 1.19.3
Can confirm in 23w06a