Closed jennitormala closed 4 years ago
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.
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.
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.
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.
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.
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.