dx

It's still an issue but I wouldn't expect mojang to care at all (can't blame them, the fact that this feature existed was unusually generous to begin with), and personally I don't care either. Most people who would care have other tools to replace this functionality.

You can keep it closed (or change the resolution to something else)

§ 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 "ばか".

1.8.1pre3 server is affected. Launcher is irrelevant.

Can the title be changed to "RCON output has newlines removed" or similar? Please? Anyone? This title seriously is terrible.

"Resolved - awaiting response"? Wat.

Still happening with minecraft_server.1.8.1-pre1.jar

I can reproduce this issue too. I think it's not exactly the "extra" tag, but more like word wrapping is only done when there are spaces in the text attribute of a part of the JSON. So if a single word near the end of the line is colored, it will wrap incorrectly.

It's a vanilla issue, but it does tend to be easier to reproduce with craftbukkit servers because of its CraftChatMessage implementation which transforms all the legacy § color codes to proper JSON, and also makes URLs clickable, so for example typing http://example.com generates this in bukkit:

{"text":"http://example.com","clickEvent":{"action":"open_url","value":"http://example.com"}}

So writing any url near the end of a line with a bukkit server with no plugins will result in this issue. Sending the generated json through /tellraw with a pure vanilla setup confirms that it's a bug in the vanilla client implementation.

If someone can come up with a test case that doesn't require /tellraw, that would be cool. I imagine that would be a translatable command reply that has a single word colored near the end of the line.

I suggest changing the subject to mention that unsplit means "newlines removed". It wasn't obvious enough at first sight.

1.7.4 server is affected. Launcher is irrelevant. 14w06b server is affected too.

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.