Client can work with different charsets #48
Conversation
| @@ -43,6 +47,8 @@ public abstract class AbstractConnectionClient implements TSPLConnectionClient { | |||
| protected boolean isConnected = Boolean.FALSE; | |||
| protected boolean alive = Boolean.FALSE; | |||
|
|
|||
| private Charset charset = US_ASCII; | |||
There was a problem hiding this comment.
Current charset, initialised to old fixed value.
| @@ -176,4 +182,15 @@ protected void notifyDisconnected() { | |||
| clientListener.connectionLost(AbstractConnectionClient.this) | |||
| )); | |||
| } | |||
|
|
|||
| public void send(String message){send(message.getBytes(charset));} | |||
There was a problem hiding this comment.
Uses current charset.
| Assertions.assertEquals(US_ASCII, client.getCharset()); | ||
| client.setCharset(UTF_8); | ||
| Assertions.assertEquals(UTF_8, client.getCharset()); | ||
| client.send("ë"); |
There was a problem hiding this comment.
This character does not work in US_ASCII, so the test uses UTF-8.
|
"Some checks haven’t completed yet": "Build & Test Expected — Waiting for status to be reported" --- I don't know what to do with that. In the meantime, I cloned it at https://github.com/bunkenburg/tspl2-driver so that I can move forward. |
It seems that the checks hasn't been triggered when the PR is opened. I pushed a ghost commit to your branch that did the trick. I will merge this. |
AbstractConnectionClient maintains current charset, initialised to US_ASCII.
There are getter and setter for charset.
Method void send(String) uses current charset to convert String to bytes.
The method does not add the corresponding CODEPAGE command. The user must still do that.