Buffered Reader returns unexpected character from user input

Question

I have a multi-chat server client program and I am attempting to get input from a client in a telnet putty window. The prompt:

String login = "2-Enter Username and a password:";
        clientoutput.write((login).getBytes());

The user input:

This is read by a BufferedReader:

 BufferedReader br = new BufferedReader(new InputStreamReader(clientInput));
        String inputLine;
        String returnMessage;
        while ((inputLine = br.readLine()) != null) {

            // Split input line with space as delimiter using import jar
            String[] words = StringUtils.split(inputLine);

            // Ensure we don't get a null pointer
            if (words != null && words.length > 0) {
                String command = words[0];

            if ("logoff".equalsIgnoreCase(command) || "q".equalsIgnoreCase(command) || "quit".equalsIgnoreCase(command)) {
                logOff();
                break;
                }else 
                    // Log user in
                    try {
                        clientLogIn(clientoutput, words);
                    } catch (Exception e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                    }

            }

However the first word of user input is consistently read as

ÿû

: Eclipse console output:

User ÿû has logged in

So my question is where is this character ÿû coming from and is there a work around?

I am using WIndows 10 and Eclipse Version: 2019-03 (4.11.0) Build id: 20190314-1200

Additional info: I've tried to capture the user input and directly print to console :

if (login.contains("ÿû")) {
            login = login.substring(1);
            System.out.println("New login after removal of unxepected char: " + login);
        } else {
            System.out.println("User eneterd login : " + login);

        }

Output:

User entered login : -Enter Username and a password:

User ÿû has logged in // after the first word has been taken

`while ((inputLine = br.readLine()) != null) {...` I think the interesting part comes after this — Federico klez Culloca, Nov 15 '19 at 10:39
Anyway, since windows usually displays `0xFF` bytes as `'ÿ'` because of the default charset it uses, you're probably stumbling into [IAC commands](https://en.wikipedia.org/wiki/Telnet#Telnet_data). I bet that if you discard that line, the next will contain what you expect. — Federico klez Culloca, Nov 15 '19 at 10:52
Finally, you shouldn't consider telnet as a stream of lines, but as a stream of bytes, at least when you're writing a server. — Federico klez Culloca, Nov 15 '19 at 10:54
I mean if you don't care about accepting telnet commands, if a line starts with a `0xFF` byte, just ignore the line. — Federico klez Culloca, Nov 15 '19 at 11:12
OK how do I implement this programmatically? I've tried searching string for the unexpected char and if present create a subtring to exclude same, but didnt work — dancingbush, Nov 15 '19 at 12:33
I'm afraid I don't have time to give a complete solution, but as a hint, this `login.contains("ÿû")` can't work because you're dealing in strings, when you want to deal with bytes. So, for example use `read` instead of `readLine` and check that you're not encountering a `0xFF` byte. There's plenty of code around that shows you how to deal with byte streams. If I'll find one I'll link it later. — Federico klez Culloca, Nov 15 '19 at 12:50
See [this answer](https://stackoverflow.com/a/47510977/133203) for example. — Federico klez Culloca, Nov 15 '19 at 13:03
And [this one](https://stackoverflow.com/a/8512168/133203) about reconverting your byte array to string once you removed the unwanted ones. — Federico klez Culloca, Nov 15 '19 at 13:06
Now that I think of it, since you're actually writing your own protocol, the problem seems to be that you're using the wrong *client* to test it. That is, telnet is not meant as a general TCP client. You may avoid the problem completely if you used something like `netcat` to test your code instead. — Federico klez Culloca, Nov 15 '19 at 13:14
Thanks that works fine now, can you post this as the answer so I can accept, cheers — dancingbush, Nov 15 '19 at 13:34

score 1 · Answer 1 · edited Oct 07 '21 at 10:55

1

You got telnet protocol special bytes 0xff (IAC) and 0xfb (WILL).
If you need to avoid it in your application, use this specification (section you need is "TELNET COMMAND STRUCTURE") to skip protocol specific bytes.

edited Oct 07 '21 at 10:55

Community

1
1

answered Nov 15 '19 at 11:00

Aleksandr Semyannikov

1,344
9
21

Hi, I think I understand but how do I do this programmatically ? – dancingbush Nov 15 '19 at 12:30
@dancingbush technically, you need to work with bytes instead of lines. First of all you need to realize how telnet works to skip all protocol-specific bytes. BTW, you have written that you have a "multi-chat server client program", are you sure that you really need all that telnet specific things inside your code? – Aleksandr Semyannikov Nov 15 '19 at 13:11
@AleksandrSemyannikov there's nothing telnet-specific in their code. Those commands are coming from PuTTY because, of course, it's a telnet client, not a client for their specific chat protocol. – Federico klez Culloca Nov 15 '19 at 13:12
@FedericoklezCulloca, sure, it exactly what I meant, I think it's unnecesarry to deal with that bytes at all. dancingbush should just keep in mind that symbols are related with telnet protocol and won't appear in proper environment. – Aleksandr Semyannikov Nov 15 '19 at 13:17
@AleksandrSemyannikov ok, I was thrown off by "are you sure that you really need all that telnet specific things inside your code?". – Federico klez Culloca Nov 15 '19 at 13:19

score 1 · Accepted Answer · answered Nov 15 '19 at 13:43

Since you're actually writing your own protocol, the problem seems to be that you're using the wrong client to test your server.

That is, telnet is not meant as a general TCP client, as it sends commands alongside the actual data you're trying to send. Also, it works on bytes, not java strings (which you noticed when you tried to check for those weird chars at the beginning of the string).

You may avoid the problem completely if you used something like netcat to test your code instead.

Buffered Reader returns unexpected character from user input

2 Answers2