Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: major code surgery

...

The char data type (and consequently the value that a Character object encapsulates) are based on the original Unicode specification, which defined characters as fixed-width 16-bit entities. The Unicode standard has since been changed to allow for characters whose representation requires more than 16 bits. The range of legal code points is now U+0000 to U+10FFFF, known as Unicode scalar value.

The Java 2 platform uses the UTF-16 representation in char arrays and in the String and StringBuffer classes. In this representation, supplementary characters are represented as a pair of char values, the first from the high-surrogates range, (\uD800-\uDBFF), the second from the low-surrogates range (\uDC00-\uDFFF).

An int value represents all Unicode code points, including supplementary code points. The lower (least significant) 21 bits of int are used to represent Unicode code points and the upper (most significant) 11 bits must be zero. Unless otherwise specified, the behavior with respect to supplementary characters and surrogate char values is as follows:

  • The methods that only accept a char value cannot support supplementary characters. They treat char values from the surrogate ranges as undefined characters. For example, Character.isLetter('\uD840') returns false, even though this specific value if followed by any low-surrogate value in a string would represent a letter.
  • The methods that accept an int value support all Unicode characters, including supplementary characters. For example, Character.isLetter(0x2F81A) returns true because the code point value represents a letter (a CJK ideograph).

Noncompliant Code Example (

...

read)

This noncompliant code example reads tries to read up to 1024 bytes from a FileInputStream into a 1024 byte buffer before concatenating to a Stringa socket and build a String from them. It does this by reading the bytes in a while loop, as recommended by FIO10-J. Ensure the array is filled when using read() to fill an array. If it ever detects that the socket has more than 1024 available, it throws an exception. This prevents untrusted input from potentially exhausting the program's memory.

Code Block
bgColor#FFcccc
public final int MAX_SIZE = 1024;

public String readBytes(Socket socket) throws IOException {
  InputStream in = socket.getInputStream();
  byte[] data = new byte[MAX_SIZE+1];
   String strint offset = 0;
  int bytesRead = ""0;
  byte[]String datastr = new byte[1024]String();
  while ((bytesRead = in.read(data, offset, data.length - offset)) >!= -1) {
    offset += bytesRead;
    str += new String(data, offset, data.length - offset, "UTF-8");
    if (offset >= data.length) {
      throw new IOException("Too much input");
    }
  }
  in.close();
  return str;
}

This code fails to consider the interaction between characters represented with a multi-byte encoding and the boundaries between the loop iterations. If the 1024th last byte read from the data stream in one read() operation is the leading byte of a multibyte character, the trailing bytes are not encountered until the next iteration of the while loop. However, multi-byte encoding is resolved during construction of the new String within the loop. Consequently, the multibyte encoding is interpreted incorrectly.

Compliant Solution (

...

read)

This compliant solution does not actually create a the string until all the data is available.

Code Block
bgColor#ccccff

public final int MAX_SIZE = 1024;

public String readBytes(Socket socket) throws IOException {
  InputStream in = socket.getInputStream();
  intbyte[] offsetdata = 0 new byte[MAX_SIZE+1];
  int bytesReadoffset = 0;
  byte[]int databytesRead = new byte[4096]0;
  while (true) { 
    ((bytesRead = in.read(data, offset, data.length - offset);
    if (bytesRead ==) != -1) {
      break;
    }
    offset += bytesRead;
    if (offset >= data.length) {
       breakthrow new IOException("Too much input");
    }
  }
  in.close();
  String str = new String(data, "UTF-8");
  in.close();
  return str;
}

This code avoids splitting multibyte encoded characters across buffers by deferring construction of the result string until the data has been read in full. It does assume that the 4096th byte in the stream is not in the middle of a multibyte character.The size of the data byte buffer depends on the maximum number of bytes required to write an encoded character and the number of characters. For example, UTF-8 encoded data requires four bytes to represent any character above U+FFFF. Because Java uses the UTF-16 character encoding to represent char data, such sequences are split into two separate char values of two bytes each. Consequently, the buffer size should be four times the size of the maximum number of characters.

...

Compliant Solution (

...

Reader)

...

This compliant solution uses a Reader rather than an InputStream. The Reader class converts bytes into characters on the fly. This routine will abort if the socket provides more than 1024 characters, rather than 1024 bytes.The no-argument and one-argument readFully() methods of the DataInputStream class read all of the requested data or throw an exception. These methods throw EOFException if they detect the end of input before the required number of bytes have been read; they throw IOException if some other input/output error occurs. This compliant solution assumes a maximum string size of 4096 bytes.

Code Block
bgColor#ccccff
public final int MAX_SIZE = 1024;

public String readBytes(Socket socket) throws IOException {
  InputStream in = socket.getInputStream();
  Reader r  byte= new InputStreamReader(in, "UTF-8");
  char[] data = new byte[4096char[MAX_SIZE+1];
  DataInputStream dinint offset = 0;
  int charsRead = 0;
  String str = new DataInputStreamString(indata);
  din.readFully(data);
  in.close();
  String str  while ((charsRead = r.read(data, offset, data.length - offset)) != -1) {
    offset += charsRead;
    str += new String(data, offset, data.length - "UTF-8"offset);
    if (offset >= data.length) {
      throw new IOException("Too much input");
    }
  }
  in.close();
  return str;
}

Noncompliant Code Example (

...

substring)

Wiki Markup
This noncompliant code example attempts to trim leading letters from the {{string}}. It fails to accomplish this task because {{Character.isLetter()}} lacks support for supplementary and combining characters \[[Hornig 2007|AA. Bibliography#Hornig 07]\].

Code Block
bgColor#FFcccc
// Fails for supplementary or combining characters
public static String trim_bad1(String string) {
  char ch;
  int i;
  for (i = 0; i < string.length(); i += 1) {
    ch = string.charAt(i);
    if (!Character.isLetter(ch)) {
      break;
    }
  }
  return string.substring(i);
}

Noncompliant Code Example (

...

substring)

Wiki Markup
This noncompliant code example attempts to fix the problem by using the {{String.codePointAt()}} method, which accepts an {{int}} argument. This works for supplementary characters but fails for combining characters \[[Hornig 2007|AA. Bibliography#Hornig 07]\].

Code Block
bgColor#FFcccc
// Fails for combining characters
public static String trim_bad2(String string) {
  int ch;
  int i;
  for (i = 0; i < string.length(); i += Character.charCount(ch)) {
    ch = string.codePointAt(i);
    if (!Character.isLetter(ch)) {
      break;
    }
  }
  
  return string.substring(i);
}

Compliant Solution (

...

substring)

Wiki Markup
This compliant solution works both for supplementary and for combining characters \[[Hornig 2007|AA. Bibliography#Hornig 07]\]. According to the Java API \[[API 2006|AA. Bibliography#API 06]\], class {{java.text.BreakIterator}} documentation

...

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="bce49314998cad1a-311d7fcc-412942fe-a9ca8bed-4a5bf444efbef583a3cfffec"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

Classes Character and BreakIterator

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b80e6aa05a032bc2-2cde983f-4bba4323-8adaa12d-1e141a9a5dedfdb6fee36f7b"><ac:plain-text-body><![CDATA[

[[Hornig 2007

AA. Bibliography#Hornig 07]]

Problem areas: Characters

]]></ac:plain-text-body></ac:structured-macro>

...