Is this ASCII type?

Question

Is this ASCII ?

And how can I print it in understanding language like in char ?

I get this answer from my PortCom. Here is how I read :

boolean ok = false;
int read = 0;
System.out.println("In Read :");
  while(ok == false) {
    int availableBytes = 0;
    try {
        availableBytes = inputStream.available();
        if (availableBytes > 0) {
            read = read + availableBytes;
            int raw = inputStream.read(readBuffer, read-availableBytes, availableBytes);
            System.out.println("Inpustream ="+raw);
            traduction = new String(readBuffer, read-availableBytes, availableBytes);
            System.out.println("2=>" + traduction);
            Response = new String(readBuffer, "UTF-8");             // bytes -> String
        } catch (IOException e) {
    }
    if (availableBytes == 0 && (read == 19 || read == 8)){
        ok = true;
    }
}

Answer 1

As I read your comments, I am under the impression that you're a little confused as to what a character and ASCII are.

Characters are numbers. Plain dumb numbers. It just so happens that people created standard mappings between numbers and letters. For instance, according to the ASCII character map, 97 is a. The implications of this are that when display software sees 97, it knows that it has to find the glyph for the character a in a given font, and draw it to the screen.

Integer values 0 through 31, when interpreted with the ASCII character map, are so-called control characters and as such have no visual glyph associated with them. They tell software how to behave rather than what to display. For instance, the character #0 is the NUL character and is used to signal the end of a string with the C string library and has little to no practical use in most other languages. Off my head, character #13 is NL, for "new line", and it tells the rendering software to move the drawing cursor to the next line, rather than to render a character.

Most ASCII control characters are outdated and are not meant to be sent to text rendering software. As such, implementations decide how they deal with them if they don't know what to do. Many of them do nothing, some print question marks, and some print completely unrelated characters.

ASCII only maps integers from 0 to 128 to glyphs or control characters, which leaves another 128 possible integers in a byte undefined. Integers above 127 have no associated glyph in the ASCII standard, and only these can be called "not ASCII". So, what you should be asking, really, is "is that text?" rather than "is that ASCII?", because any sequence of integers between 0 and 127 is necessarily ASCII, which however says nothing about whether or not it's human-readable.

And the obvious answer to that question is "no, it's not text". Asking what it is if it's not text is asking us to be psychics, since there's no "universal bug" that maims text. It could be almost anything.

However, since you state that you're reading from a serial link, I'd advise you to check the bauds rate and other link settings, because there's no built-in mechanism to detect mismatches from on end to the other, and it can mangle data the way it does here.

Answer 2

Use the raw value instead of availableBytes:

traduction = new String(readBuffer, read-availableBytes, raw);

The raw indicates how many were actually read as opposed to how many you requested. If you ask 10 bytes and it reads 5, the remaining 5 will be unknown garbage.

UPDATE

The response is obviously wrong too and for the same reason:

Response = new String(readBuffer, "UTF-8");

You are telling it to convert the entire buffer even though you may have only read 1 byte. If you're a bit unlucky you'll get exceptions because not all byte combinations can be converted using UTF-8