APIs to read and write code points. #145
Conversation
|
|
||
| } else if (codePoint < 0x10000) { | ||
| if (codePoint >= 0xd800 && codePoint <= 0xdfff) { | ||
| throw new IllegalArgumentException( |
There was a problem hiding this comment.
Interesting design decision here. What to do when the input's not quite right:
- we could throw
- we could encode it (it's still recoverable on the other end, though encoders might return the replacement char)
- we could encode the replacement character ourselves
Thoughts?
There was a problem hiding this comment.
Tough. Option 2 doesn't seem reasonable to me. I'm inclined to lean towards 1 (as implemented), but I see the value in 3. I think it's hard to be too forgiving at this level. A higher-level API could handle the replacement character writing, but when you're at this level I think throwing is correct.
|
|
| * Removes and returns a single UTF-8 code point, reading between 1 and 4 bytes as necessary. | ||
| * | ||
| * <p>If this source is exhausted before a complete code point can be read, this throws an {@link | ||
| * java.io.EOFException} and consumes no input. |
There was a problem hiding this comment.
Nice doc. I don't think we're very good about documenting the behavior when methods throw (related to the contents of the underlying buffer).
|
LGTM |
The String APIs transcode UTF-16 to UTF-8 and back. These APIs avoid the UTF-16 intermediate form altogether, and go right from UTF-8 to a codepoint and back.
swankjesse
force-pushed
the
jwilson_0425_utf8_code_points
branch
from
6529430
to
85e9f94
Compare
APIs to read and write code points.
The String APIs transcode UTF-16 to UTF-8 and back.
These APIs avoid the UTF-16 intermediate form altogether, and
go right from UTF-8 to a codepoint and back.