Fix bug so that non-ascii characters work

[jennitormala]

1 #2 Fixed bug that didn't allow non-ascii characters to work. Non-ascii characters, such as ä and ö take two bits instead of one which is why length() calculates the data length incorrectly. This caused incomplete JSON strings with EOF errors.

[mbuet2ner]

If someone wants to help with this issue (since it is a relatively big one compared to the average), that would be great! @anttijuu pointed out, that this might also be a good point to implement some unit tests (see #21) related to encoding and input. If someone wants to provide the tests, that would be a very welcomed enhancement.

[anttijuu]

Just a comment here, about what is the issue. From my test runs with the proposed PR:

I enter test characters "𝞐𝞑𝞒𝞓𝞔♛♚\⁉︎" (encrypt with matrix method).

Give text to encrypt > 𝞐𝞑𝞒𝞓𝞔♛♚\⁉︎
...
Response received.
Received raw data: {"result":0,"id":17,"data":"𝞔\\?♛\u2049?♚︎𝞒𝞑𝞐","operation":"encrypt-response"}
Parsing...
Result: 0
Data: 𝞔\?♛⁉?♚︎𝞒𝞑𝞐
java.net.DatagramPacket@2c73168b
Starting to receive responses...

** Error - not a valid number ** !

As you can see, not all characters (code points) are in the response and there is the Error printout too. This is because code is still handling chars, not Unicode chars (code points). This applies not only to Client and Server not using UTF-8, but also different crypto methods crypting by 8 bit chars.

If you try to put the encrypted response back to server again using the same matrix method, you would not get the original string back. That is the issue. All text you encrypt with some method, you should be able to get back the original string when using decrypt. This doesn't happen now:

Give decryption method > matrix
Give text to decrypt > 𝞔\?♛⁉?♚︎𝞒𝞑𝞐
...
Response received.
Received raw data: {"result":0,"id":18,"data":"𝞐𝞑𝞒????♛♚\\\u2049︎","operation":"decrypt-response"}
Parsing...
Parsed, handing JSON object to observer.
Got response from reader...
Request ID: 18
Operation: decrypt-response
Result: 0
Data: 𝞐𝞑𝞒????♛♚\⁉︎

So you do not get the original string back because the data is not handled correctly. Pretty useless encryption software -- I encrypt something and send it to someone, who tries to decrypt it but gets garbage back.

[jennitormala]

Oops, I accidentally closed this PR by merging my own fork. Not sure how to re-open. 😬 We will try to work on this issue.

[jennitormala]

Now the Matrix method is working and it handles the characters by code points. The characters seem to display correctly:

The methods are: reverse, matrix, cyr
Give encryption method > matrix
Give text to encrypt > asd123𝞐𝞑𝞒𝞓𝞔♛♚\⁉︎
...
Your choice > Response received.
Received raw data: {"result":0,"id":1,"data":"a2𝞒♚s3𝞓\\d𝞐𝞔\u20491𝞑♛︎","operation":"encrypt-response"}
Parsing...
Parsed, handing JSON object to observer.
Got response from reader...
Request ID: 1
Operation: encrypt-response
Result: 0
Data: a2𝞒♚s3𝞓\d𝞐𝞔⁉1𝞑♛︎

The same encrypted string of characters also was decrypted correctly:

Give decryption method > matrix
Give text to decrypt > a2𝞒♚s3𝞓\d𝞐𝞔⁉1𝞑♛︎
...
Your choice > Response received.
Received raw data: {"result":0,"id":2,"data":"asd123𝞐𝞑𝞒𝞓𝞔♛♚\\\u2049︎","operation":"decrypt-response"}
Parsing...
Parsed, handing JSON object to observer.
Got response from reader...
Request ID: 2
Operation: decrypt-response
Result: 0
Data: asd123𝞐𝞑𝞒𝞓𝞔♛♚\⁉︎

This doesn't solve the issue that the same encoding and char handling should be used everywhere, but maybe it is a start.

[mbuet2ner]

Since this PR does not solve the problem, I am closing it right now. However, it lead to an important and fruitful discussion with some good insights. I have linked it in the relevant issues.