过滤Java中用户字体中缺少的字符

Question

I want to build a somewhat simple table with Java (as an exercise) to check for the existence of legal printable Unicode code point in the end-user's font. Because some fonts cannot print valid code points, I have to know which printable code points the user's font is nevertheless missing and so cannot print.

For example, if a font supports only Latin characters, I cannot print Greek characters using it, let alone Japanese characters. Unicode says they're all printable, but the user's font may not be good enough.

After a little research I've been able to print most of the characters in Eclipse (by adjusing the Encoding). However I still have a bunch of unknown/unprintable characters in my output, in that when I look at the output I see all these empty rectangles for some of my printable characters.

I've tried filtering them but I can't find any way to do it. FYI I'm basically just setting a character's value to 50, 100 or 1000, then incremeningt it via a for loop from there to check what characters I can or cannot (or should not?) print.

Can anyone give me some hints on where to start here?

Answer 1

Your task is actually a little more complex than encoding because the font that you are trying to print from makes a big difference in the output. Ie not all fonts support the same set of characters. In fact, the support of character ranges differs wildly from font to font .

That said, your problem now becomes: How do I detect whether a certain font supports a given character? And that question has been asked and answered ... See here for the Java doc of the canDisplay function which is a member of the Font class .

Answer 2

It is unclear what you actually and precisely mean here. If you plan to play by the numbers, then Annex C of Unicode Technical Standard #18 on Unicode Regular Expressions gives the concrete suggestion that a “printable” code point be defined as any code point that has the print property, where that property is defined to be

• \\p{print} means [[\\p{graph}\\p{blank}]&&[^\\p{gc=Control}]]
• \\p{graph} means [^\\p{Whitespace}\\p{gc=Control}\\p{gc=Surrogate}\\p{gc=Unassigned}]
• \\p{blank} means [\\p{Whitespace}&&[^\\N{LF}\\N{VT}\\N{FF}\\N{CR}\\N{NEL}\\p{gc=Line_Separator}\\{gc=Paragraph_Separator}]

Or, as the Java 1.7 Pattern class documents these , provided you compile the pattern with the new-to-Java7 Pattern.UNICODE_CHARACTER_CLASS flag enabled:

• \\p{Graph} A visible character: [^\\p{IsWhite_Space}\\p{gc=Cc}\\p{gc=Cs}\\p{gc=Cn}]
• \\p{Print} A printable character: [\\p{Graph}\\p{Blank}&&[^\\p{Cntrl}]]
• \\p{Blank} A space or a tab: [\\p{IsWhite_Space}&&[^\\p{gc=Zl}\\p{gc=Zp}\\x0a\\x0b\\x0c\\x0d * \\x85]]
• \\p{Cntrl} A control character: \\p{gc=Cc}
• \\p{XDigit} A hexadecimal digit: [\\p{gc=Nd}\\p{IsHex_Digit}]
• \\p{Space} A whitespace character: \\p{IsWhite_Space}

On 'Printable' Characters

If you just use something reasonable like Java's (?U)\\p{print} pattern property (or the equivalent from the Character class), then you still have some “interesting” decisions to make.

Consider each of these code points:

U+000007 gc=Cc columns=0 print=0 graph=0  ALERT
U+000008 gc=Cc columns=0 print=0 graph=0  BACKSPACE
U+000009 gc=Cc columns=0 print=0 graph=0  CHARACTER TABULATION
U+00000C gc=Cc columns=0 print=0 graph=0  FORM FEED (FF)
U+00000D gc=Cc columns=0 print=0 graph=0  CARRIAGE RETURN (CR)
U+000020 gc=Zs columns=1 print=1 graph=0  SPACE
U+000021 gc=Po columns=1 print=1 graph=1  EXCLAMATION MARK
U+000041 gc=Lu columns=1 print=1 graph=1  LATIN CAPITAL LETTER A
U+000061 gc=Ll columns=1 print=1 graph=1  LATIN SMALL LETTER A
U+000080 gc=Cc columns=0 print=0 graph=0  PADDING CHARACTER
U+000085 gc=Cc columns=0 print=0 graph=0  NEXT LINE (NEL)
U+00008D gc=Cc columns=0 print=0 graph=0  REVERSE LINE FEED
U+0000AB gc=Pi columns=1 print=1 graph=1  LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
U+0000AD gc=Cf columns=0 print=1 graph=1  SOFT HYPHEN
U+0002B0 gc=Lm columns=1 print=1 graph=1  MODIFIER LETTER SMALL H
U+0002C6 gc=Lm columns=1 print=1 graph=1  MODIFIER LETTER CIRCUMFLEX ACCENT
U+000302 gc=Mn columns=0 print=1 graph=1  COMBINING CIRCUMFLEX ACCENT
U+00036A gc=Mn columns=0 print=1 graph=1  COMBINING LATIN SMALL LETTER H
U+001100 gc=Lo columns=2 print=1 graph=1  HANGUL CHOSEONG KIYEOK
U+002028 gc=Zl columns=0 print=0 graph=0  LINE SEPARATOR
U+002029 gc=Zp columns=0 print=0 graph=0  PARAGRAPH SEPARATOR
U+00202B gc=Cf columns=0 print=1 graph=1  RIGHT-TO-LEFT EMBEDDING
U+00202F gc=Zs columns=1 print=1 graph=0  NARROW NO-BREAK SPACE
U+002060 gc=Cf columns=0 print=1 graph=1  WORD JOINER
U+002061 gc=Cf columns=0 print=1 graph=1  FUNCTION APPLICATION
U+002062 gc=Cf columns=0 print=1 graph=1  INVISIBLE TIMES
U+002064 gc=Cf columns=0 print=1 graph=1  INVISIBLE PLUS
U+002EC1 gc=So columns=2 print=1 graph=1  CJK RADICAL TIGER
U+002F0B gc=So columns=2 print=1 graph=1  KANGXI RADICAL EIGHT
U+003000 gc=Zs columns=2 print=1 graph=0  IDEOGRAPHIC SPACE
U+003008 gc=Ps columns=2 print=1 graph=1  LEFT ANGLE BRACKET
U+00300A gc=Ps columns=2 print=1 graph=1  LEFT DOUBLE ANGLE BRACKET
U+00300C gc=Ps columns=2 print=1 graph=1  LEFT CORNER BRACKET
U+00302B gc=Mn columns=0 print=1 graph=1  IDEOGRAPHIC RISING TONE MARK
U+003030 gc=Pd columns=2 print=1 graph=1  WAVY DASH
U+003037 gc=So columns=2 print=1 graph=1  IDEOGRAPHIC TELEGRAPH LINE FEED SEPARATOR SYMBOL
U+003041 gc=Lo columns=2 print=1 graph=1  HIRAGANA LETTER SMALL A
U+00E000 gc=Co columns=1 print=1 graph=1 <unnamed codepoint in blk=Private_Use_Area>
U+00F8FF gc=Co columns=1 print=1 graph=1 <unnamed codepoint in blk=Private_Use_Area>
U+00FB1E gc=Mn columns=0 print=1 graph=1  HEBREW POINT JUDEO-SPANISH VARIKA
U+00FE00 gc=Mn columns=0 print=1 graph=1  VARIATION SELECTOR-1
U+00FE23 gc=Mn columns=0 print=1 graph=1  COMBINING DOUBLE TILDE RIGHT HALF
U+00FE58 gc=Pd columns=2 print=1 graph=1  SMALL EM DASH
U+00FE77 gc=Lo columns=1 print=1 graph=1  ARABIC FATHA MEDIAL FORM
U+00FEFF gc=Cf columns=0 print=1 graph=1  ZERO WIDTH NO-BREAK SPACE
U+00FF06 gc=Po columns=2 print=1 graph=1  FULLWIDTH AMPERSAND
U+00FFFA gc=Cf columns=0 print=1 graph=1  INTERLINEAR ANNOTATION SEPARATOR
U+00FFFD gc=So columns=1 print=1 graph=1  REPLACEMENT CHARACTER
U+01B000 gc=Lo columns=2 print=1 graph=1  KATAKANA LETTER ARCHAIC E
U+01D165 gc=Mc columns=1 print=1 graph=1  MUSICAL SYMBOL COMBINING STEM
U+01D167 gc=Mn columns=0 print=1 graph=1  MUSICAL SYMBOL COMBINING TREMOLO-1
U+100002 gc=Co columns=1 print=1 graph=1 <unnamed codepoint in blk=Supplementary_Private_Use_Area-B>

Some of them are quite conditional as to what, and perhaps even whether, they print. For example, what does U+F8FF's ‹› look like to you?

Then you have to decide how to handle tabs and backspace.

Plus you will have to consider the various \\p{Grapheme_Extend} code points used to build up a Unicode extended grapheme cluster ; that is, a user-visible character . Not all of these are nonspacing marks. In fact, some aren't marks at all, but letters! Some are not printable characters at all, and yet they change the printable \\p{Grapheme_Base} character to which they are ineluctably attached; consider just as one example the variation selectors.

Warning

Which brings us to a critically important point that is far too often forgotten by would-be Java programmers, and even when not wholly forgotten, is usually underappreciated.

Always, always, always remember that Java characters are not Unicode characters! There are two reasonable definitions of a Unicode character, and Java gives you neither. Here are the two reasonable definitions:

• If a character is a character in the programmer-visible sense, then a character is a Unicode code point. This is what . matches in the regex engine, for example, no matter whether you use Sun's or ICU's.
• If a character is a character in the user-visible sense, then a character is a Unicode extended grapheme cluster. This is what \\X matches in the (ICU not Sun) regex engine.

A Java so-called “character” is a low-level, breaks-the-abstract 2-byte element of a variable-width UTF-16 representation of an actual Unicode code point. It is neither an abstract code point nor an abstract grapheme. It is not an abstract anything. A Java char is a violation of the envelope of abstraction.

Yes, some Java classes give you a codePointAt interface, and you should absolutely use those wherever those are available. But in many ways that it takes too long to explain here, Java is fundamentally broken in its character abstraction — because it doesn't have one.

This makes working with Unicode characters and strings at best error-prone in Java, and often next to impossible.

Good luck.