Hi Mickael,
Yes, the language engine chokes on the bad decoding. So if I decode the byte array as cp1252, I get a (Java) pound character and all is well; if I decode as UTF8 (which is my default, but it's the same if I'm explicit) then I get a "<?>" character - basically an unknown decoding. As cp1252, the character appears in the logs as expected and so on; as utf8, it's always nonsense. So I'm pretty sure it's cp1252 encoded, and of course I can see the single byte value of A3 (or -93 as a Java byte), whereas a UTF8 pound would be a pair: C2 A3. Technically I think it could be ISO-8859-1, but I'd need to try more experiments to tell.
I could easily believe that the JSON RPC layer is forcing cp1252, and that would be "ok" (if non-standard compliant). But there's the strange business about having the wrong Content-Length (it has the correct UTF8 length, actually). And it's the same with vscode and lsp4e. It occurred to me that this is probably lsp4j underneath, though I don't know whether vscode uses that?
