使用 Java 语言进行 Unicode 代理编程

最新推荐文章于 2021-04-21 17:40:47 发布
最新推荐文章于 2021-04-21 17:40:47 发布
阅读量222 收藏
点赞数
文章标签： java
原文链接：https://my.oschina.net/hejunbinlan/blog/674113
版权

编码选项和性能考虑

从 1.5 版开始，Java™ 语言就提供一些 API 来支持不能通过一个单一 16 位 char 数据类型表示的 Unicode 增补字符。本文讨论这些 API 的特性，展示它们的正确用法，并评估它们的处理性能。

0 评论

Masahiko Maedera, 软件工程师, IBM

2010 年 10 月 25 日

  • expand内容

在 IBM Bluemix 云平台上开发并部署您的下一个应用。

开始您的试用

早期 Java 版本使用 16 位 char 数据类型表示 Unicode 字符。这种设计方法有时比较合理，因为所有 Unicode 字符拥有的值都小于 65,535 (0xFFFF)，可以通过 16 位表示。但是，Unicode 后来将最大值增加到 1,114,111 (0x10FFFF)。由于 16 位太小，不能表示 Unicode version 3.1 中的所有 Unicode 字符，32 位值 — 称为码位（code point）— 被用于 UTF-32 编码模式。

但与 32 位值相比，16 位值的内存使用效率更高，因此 Unicode 引入了一个种新设计方法来允许继续使用 16 位值。UTF-16 中采用的这种设计方法分配 1,024 值给 16 位高代理（high surrogate），将另外的 1,024 值分配给 16 位低代理（low surrogate）。它使用一个高代理加上一个低代理 — 一个代理对（surrogate pair）— 来表示 65,536 (0x10000) 和 1,114,111 (0x10FFFF) 之间的 1,048,576 (0x100000) 值（1,024 和 1,024 的乘积）。

Java 1.5 保留了 char 类型的行为来表示 UTF-16 值（以便兼容现有程序），它实现了码位的概念来表示 UTF-32 值。这个扩展（根据 JSR 204：Unicode Supplementary Character Support 实现）不需要记住 Unicode 码位或转换算法的准确值 — 但理解代理 API 的正确用法很重要。

东亚国家和地区近年来增加了它们的字符集中的字符数量，以满足用户需求。这些标准包括来自中国的国家标准组织的 GB 18030 和来自日本的 JIS X 0213。因此，寻求遵守这些标准的程序更有必要支持 Unicode 代理对。本文解释相关 Java API 和编码选项，面向计划重新设计他们的软件，从只能使用 char 类型的字符转换为能够处理代理对的新版本的读者。

顺序访问

顺序访问是在 Java 语言中处理字符串的一个基本操作。在这种方法下，输入字符串中的每个字符从头至尾按顺序访问，或者有时从尾至头访问。本小节讨论使用顺序访问方法从一个字符串创建一个 32 位码位数组的 7 个技术示例，并估计它们的处理时间。

示例 1-1：基准测试（不支持代理对）

清单 1 将 16 位 char 类型值直接分配给 32 位码位值，完全没有考虑代理对：

清单 1. 不支持代理对
int[] toCodePointArray(String str) { // Example 1-1
    int len = str.length();          // the length of str
    int[] acp = new int[len];        // an array of code points

    for (int i = 0, j = 0; i < len; i++) {
        acp[j++] = str.charAt(i);
    }
    return acp;
}

尽管这个示例不支持代理对，但它提供了一个处理时间基准来比较后续顺序访问示例。

示例 1-2：使用 isSurrogatePair()

清单 2 使用 isSurrogatePair() 来计算代理对总数。计数之后，它分配足够的内存以便一个码位数组存储这个值。然后，它进入一个顺序访问循环，使用 isHighSurrogate() 和 isLowSurrogate() 确定每个代理对字符是高代理还是低代理。当它发现一个高代理后面带一个低代理时，它使用 toCodePoint() 将该代理对转换为一个码位值并将当前索引值增加 2。否则，它将这个 char 类型值直接分配给一个码位值并将当前索引值增加 1。这个示例的处理时间比 示例 1-1 长 1.38 倍。

清单 2. 有限支持
int[] toCodePointArray(String str) { // Example 1-2
    int len = str.length();          // the length of str
    int[] acp;                       // an array of code points
    int surrogatePairCount = 0;      // the count of surrogate pairs

    for (int i = 1; i < len; i++) {
        if (Character.isSurrogatePair(str.charAt(i - 1), str.charAt(i))) {
            surrogatePairCount++;
            i++;
        }
    }
    acp = new int[len - surrogatePairCount];
    for (int i = 0, j = 0; i < len; i++) {
        char ch0 = str.charAt(i);         // the current char
        if (Character.isHighSurrogate(ch0) && i + 1 < len) {
            char ch1 = str.charAt(i + 1); // the next char
            if (Character.isLowSurrogate(ch1)) {
                acp[j++] = Character.toCodePoint(ch0, ch1);
                i++;
                continue;
            }
        }
        acp[j++] = ch0;
    }
    return acp;
}

清单 2 中更新软件的方法很幼稚。它比较麻烦，需要大量修改，使得生成的软件很脆弱且今后难以更改。具体而言，这些问题是：

  • 需要计算码位的数量以分配足够的内存
  • 很难获得字符串中的指定索引的正确码位值
  • 很难为下一个处理步骤正确移动当前索引

一个改进后的算法出现在下一个示例中。

示例：基本支持

Java 1.5 提供了 codePointCount()、codePointAt() 和 offsetByCodePoints() 方法来分别处理 示例 1-2 的 3 个问题。清单 3 使用这些方法来改善这个算法的可读性：

清单 3. 基本支持
int[] toCodePointArray(String str) { // Example 1-3
    int len = str.length();          // the length of str
    int[] acp = new int[str.codePointCount(0, len)];

    for (int i = 0, j = 0; i < len; i = str.offsetByCodePoints(i, 1)) {
        acp[j++] = str.codePointAt(i);
    }
    return acp;
}

但是，清单 3 的处理时间比 清单 1 长 2.8 倍。

示例 1-4：使用 codePointBefore()

当 offsetByCodePoints() 接收一个负数作为第二个参数时，它就能计算一个距离字符串头的绝对偏移值。接下来，codePointBefore()能够返回一个指定索引前面的码位值。这些方法用于清单 4 中从尾至头遍历字符串：

清单 4. 使用 codePointBefore() 的基本支持
int[] toCodePointArray(String str) { // Example 1-4
    int len = str.length();          // the length of str
    int[] acp = new int[str.codePointCount(0, len)];
    int j = acp.length;              // an index for acp

    for (int i = len; i > 0; i = str.offsetByCodePoints(i, -1)) {
        acp[--j] = str.codePointBefore(i);
    }
    return acp;
}

这个示例的处理时间 — 比 示例 1-1 长 2.72 倍 — 比 示例 1-3 快一些。通常，当您比较零而不是非零值时，JVM 中的代码大小要小一些，这有时会提高性能。但是，微小的改进可能不值得牺牲可读性。

示例 1-5：使用 charCount()

示例 1-3 和 1-4 提供基本的代理对支持。他们不需要任何临时变量，是健壮的编码方法。要获取更短的处理时间，使用 charCount() 而不是offsetByCodePoints() 是有效的，但需要一个临时变量来存放码位值，如清单 5 所示：

清单 5. 使用 charCount() 的优化支持
int[] toCodePointArray(String str) { // Example 1-5
    int len = str.length();          // the length of str
    int[] acp = new int[str.codePointCount(0, len)];
    int j = 0;                       // an index for acp

    for (int i = 0, cp; i < len; i += Character.charCount(cp)) {
        cp = str.codePointAt(i);
        acp[j++] = cp;
    }
    return acp;
}

清单 5 的处理时间降低到比 示例 1-1 长 1.68 倍。

示例 1-6：访问一个 char 数组

清单 6 在使用 示例 1-5 中展示的优化的同时直接访问一个 char 类型数组：

清单 6. 使用一个 char 数组的优化支持
int[] toCodePointArray(String str) { // Example 1-6
    char[] ach = str.toCharArray();  // a char array copied from str
    int len = ach.length;            // the length of ach
    int[] acp = new int[Character.codePointCount(ach, 0, len)];
    int j = 0;                       // an index for acp

    for (int i = 0, cp; i < len; i += Character.charCount(cp)) {
        cp = Character.codePointAt(ach, i);
        acp[j++] = cp;
    }
    return acp;
}

char 数组是使用 toCharArray() 从字符串复制而来的。性能得到改善，因为对数组的直接访问比通过一个方法的间接访问要快。处理时间比 示例 1-1 长 1.51 倍。但是，当调用时，toCharArray() 需要一些开销来创建一个新数组并将数据复制到数组中。String 类提供的那些方便的方法也不能被使用。但是，这个算法在处理大量数据时有用。

示例 1-7：一个面向对象的算法

这个示例的面向对象算法使用 CharBuffer 类，如清单 7 所示：

清单 7. 使用 CharSequence 的面向对象算法
int[] toCodePointArray(String str) {        // Example 1-7
    CharBuffer cBuf = CharBuffer.wrap(str); // Buffer to wrap str
    IntBuffer iBuf = IntBuffer.allocate(    // Buffer to store code points
            Character.codePointCount(cBuf, 0, cBuf.capacity()));

    while (cBuf.remaining() > 0) {
        int cp = Character.codePointAt(cBuf, 0); // the current code point
        iBuf.put(cp);
        cBuf.position(cBuf.position() + Character.charCount(cp));
    }
    return iBuf.array();
}

与前面的示例不同，清单 7 不需要一个索引来持有当前位置以便进行顺序访问。相反，CharBuffer 在内部跟踪当前位置。Character 类提供静态方法 codePointCount() 和 codePointAt()，它们能通过 CharSequence 接口处理 CharBuffer。CharBuffer 总是将当前位置设置为 CharSequence 的头。因此，当 codePointAt() 被调用时，第二个参数总是设置为 0。处理时间比 示例 1-1 长 2.15 倍。

处理时间比较

这些顺序访问示例的计时测试使用了一个包含 10,000 个代理对和 10,000 个非代理对的样例字符串。码位数组从这个字符串创建 10,000 次。测试环境包括：

  • OS：Microsoft Windows® XP Professional SP2
  • Java：IBM Java 1.5 SR7
  • CPU：Intel® Core 2 Duo CPU T8300 @ 2.40GHz
  • Memory：2.97GB RAM

表 1 展示了示例 1-1 到 1-7 的绝对和相对处理时间以及关联的 API：

表 1. 顺序访问示例的处理时间和 API
示例说明处理 时间 （毫秒）与 示例 1-1 的比率API
1-1不支持代理对20311.00 
1-2有限支持27971.38Character 类：
  • static boolean isHighSurrogate(char ch)
  • static boolean isLowSurrogate(char ch)
  • static boolean isSurrogatePair(char high, char low)
  • static int toCodePoint(char high, char low)
1-3基本支持56872.80String 类：
  • int codePointAt(int index)
  • int codePointCount(int begin, int end)
  • int offsetByCodePoints(int index, int cpOffset)
1-4使用 codePointBefore() 的基本支持55162.72String 类：
  • int codePointBefore(int index)
1-5使用 charCount() 的优化支持34061.68Character 类：
  • static int charCount(int cp)
1-6使用一个 char 数组的优化支持30621.51Character 类：
  • static int codePointAt(char[] ach, int index)
  • static int codePointCount(char[] ach, int offset, int count)
1-7使用 CharSequence 的面向对象方法43602.15Character 类：
  • static int codePointAt(CharSequence seq, int index)
  • static int codePointCount(CharSequence seq, int begin, int end)

回页首

随机访问

随机访问是直接访问一个字符串中的任意位置。当字符串被访问时，索引值基于 16 位 char 类型的单位。但是，如果一个字符串使用 32 位码位，那么它不能使用一个基于 32 位码位的单位的索引访问。必须使用 offsetByCodePoints() 来将码位的索引转换为 char 类型的索引。如果算法设计很糟糕，这会导致很差的性能，因为 offsetByCodePoints() 总是通过使用第二个参数从第一个参数计算字符串的内部。在这个小节中，我将比较三个示例，它们通过使用一个短单位来分割一个长字符串。

示例 2-1：基准测试（不支持代理对）

清单 8 展示如何使用一个宽度单位来分割一个字符串。这个基准测试留作后用，不支持代理对。

清单 8. 不支持代理对
String[] sliceString(String str, int width) { // Example 2-1
    // It must be that "str != null && width > 0".
    List<String> slices = new ArrayList<String>();
    int len = str.length();       // (1) the length of str
    int sliceLimit = len - width; // (2) Do not slice beyond here.
    int pos = 0;                  // the current position per char type

    while (pos < sliceLimit) {
        int begin = pos;                       // (3)
        int end   = pos + width;               // (4)
        slices.add(str.substring(begin, end));
        pos += width;                          // (5)
    }
    slices.add(str.substring(pos));            // (6)
    return slices.toArray(new String[slices.size()]); }

sliceLimit 变量对分割位置有所限制，以避免在剩余的字符串不足以分割当前宽度单位时抛出一个 IndexOutOfBoundsException 实例。这种算法在当前位置超出 sliceLimit 时从 while 循环中跳出后再处理最后的分割。

示例 2-2：使用一个码位索引

清单 9 展示了如何使用一个码位索引来随机访问一个字符串：

清单 9. 糟糕的性能
String[] sliceString(String str, int width) { // Example 2-2
    // It must be that "str != null && width > 0".
    List<String> slices = new ArrayList<String>();
    int len = str.codePointCount(0, str.length()); // (1) code point count [Modified]
    int sliceLimit = len - width; // (2) Do not slice beyond here.
    int pos = 0;                  // the current position per code point

    while (pos < sliceLimit) {
        int begin = str.offsetByCodePoints(0, pos);            // (3) [Modified]
        int end   = str.offsetByCodePoints(0, pos + width);    // (4) [Modified]
        slices.add(str.substring(begin, end));
        pos += width;                                          // (5)
    }
    slices.add(str.substring(str.offsetByCodePoints(0, pos))); // (6) [Modified]
    return slices.toArray(new String[slices.size()]); }

清单 9 修改了 清单 8 中的几行。首先，在 Line (1) 中，length() 被 codePointCount() 替代。其次，在 Lines (3)、(4) 和 (6) 中，char 类型的索引通过 offsetByCodePoints() 用码位索引替代。

基本的算法流与 示例 2-1 中的看起来几乎一样。但处理时间根据字符串长度与示例 2-1 的比率同比增加，因为 offsetByCodePoints() 总是从字符串头到指定索引计算字符串内部。

示例 2-3：减少的处理时间

可以使用清单 10 中展示的方法来避免 示例 2-2 的性能问题：

清单 10. 改进的性能
String[] sliceString(String str, int width) { // Example 2-3
    // It must be that "str != null && width > 0".
    List<String> slices = new ArrayList<String>();
    int len = str.length(); // (1) the length of str
    int sliceLimit          // (2) Do not slice beyond here. [Modified]
            = (len >= width * 2 || str.codePointCount(0, len) > width)
            ? str.offsetByCodePoints(len, -width) : 0;
    int pos = 0;            // the current position per char type

    while (pos < sliceLimit) {
        int begin = pos;                                // (3)
        int end   = str.offsetByCodePoints(pos, width); // (4) [Modified]
        slices.add(str.substring(begin, end));
        pos = end;                                      // (5) [Modified]
    }
    slices.add(str.substring(pos));                     // (6)
    return slices.toArray(new String[slices.size()]); }

首先，在 Line (2) 中，（清单 9 中的）表达式 len-width 被 offsetByCodePoints(len,-width) 替代。但是，当 width 的值大于码位的数量时，这会抛出一个 IndexOutOfBoundsException 实例。必须考虑边界条件以避免异常，使用一个带有 try/catch 异常处理程序的子句将是另一个解决方案。如果表达式 len>width*2 为 true，则可以安全地调用 offsetByCodePoints()，因为即使所有码位都被转换为代理对，码位的数量仍会超过 width 的值。或者，如果 codePointCount(0,len)>width 为 true，也可以安全地调用offsetByCodePoints()。如果是其他情况，sliceLimit 必须设置为 0。

在 Line (4) 中，清单 9 中的表达式 pos + width 必须在 while 循环中使用 offsetByCodePoints(pos,width) 替换。需要计算的量位于width 的值中，因为第一个参数指定当 width 的值。接下来，在 Line (5) 中，表达式 pos+=width 必须使用表达式 pos=end 替换。这避免两次调用 offsetByCodePoints() 来计算相同的索引。源代码可以被进一步修改以最小化处理时间。

处理时间比较

图 1 和图 2 展示了示例 2-1、2-2 和 2-3 的处理时间。样例字符串包含相同数量的代理对和非代理对。当字符串的长度和 width 的值被更改时，样例字符串被切割 10,000 次。

图 1. 一个分段的常量宽度

constantWidth.jpg

图 2. 分段的常量计数

constantCount.jpg

示例 2-1 和 2-3 按照长度比例增加了它们的处理时间，但 示例 2-2 按照长度的平方比例增加了处理时间。当字符串长度和 width 的值增加而分段的数量固定时，示例 2-1 拥有一个常量处理时间，而示例 2-2 和 2-3 以 width 的值为比例增加了它们的处理时间。

回页首

信息 API

大多数处理代理的信息 API 拥有两种名称相同的方法。一种接收 16 位 char 类型参数，另一种接收 32 为码位参数。表 2 展示了每个 API 的返回值。第三列针对 U+53F1，第 4 列针对 U+20B9F，最后一列针对 U+D842（即高代理），而 U+20B9F 被转换为 U+D842 加上 U+DF9F 的代理对。如果程序不能处理代理对，则值 U+D842 而不是 U+20B9F 将导致意想不到的结果（在表 2 中以粗斜体表示）。

表 2. 用于代理的信息 API
类方法/构造函数针对 U+53F1 的值针对 U+20B9F 的值针对 U+D842 的值
  U53F1.jpgU20B9F.jpg 
Characterstatic byte getDirectionality(int cp)000
 static int getNumericValue(int cp)-1-1-1
 static int getType(int cp)5519
 static boolean isDefined(int cp)truetruetrue
 static boolean isDigit(int cp)falsefalsefalse
 static boolean isISOControl(int cp)falsefalsefalse
 static boolean isIdentifierIgnorable(int cp)falsefalsefalse
 static boolean isJavaIdentifierPart(int cp)truetruefalse
 static boolean isJavaIdentifierStart(int cp)truetruefalse
 static boolean isLetter(int cp)truetruefalse
 static boolean isLetterOrDigit(int cp)truetruefalse
 static boolean isLowerCase(int cp)falsefalsefalse
 static boolean isMirrored(int cp)falsefalsefalse
 static boolean isSpaceChar(int cp)falsefalsefalse
 static boolean isSupplementaryCodePoint(int cp)falsetruefalse
 static boolean isTitleCase(int cp)falsefalsefalse
 static boolean isUnicodeIdentifierPart(int cp)truetruefalse
 static boolean isUnicodeIdentifierStart(int cp)truetruefalse
 static boolean isUpperCase(int cp)falsefalsefalse
 static boolean isValidCodePoint(int cp)truetruetrue
 static boolean isWhitespace(int cp)falsefalsefalse
 static int toLowerCase(int cp)（不可更改）
 static int toTitleCase(int cp)（不可更改）
 static int toUpperCase(int cp)（不可更改）
Character.
UnicodeBlock		Character.UnicodeBlock of(int cp)CJK_UNIFIED_IDEOGRAPHSCJK_UNIFIED_IDEOGRAPHS_EXTENSION_BHIGH_SURROGATES
Fontboolean canDisplay(int cp)（取决于 Font 实例）
FontMetricsint charWidth(int cp)（取决于 FontMetrics 实例）
Stringint indexOf(int cp)（取决于 String 实例）
 int lastIndexOf(int cp)（取决于 String 实例）

回页首

其他 API

本小节介绍前面的小节中没有讨论的代理对相关 API。表 3 展示所有这些剩余的 API。所有代理对 API 都包含在表 1、2 和 3 中。

表 3. 其他代理 API
类方法/构造函数
Characterstatic int codePointAt(char[] ach, int index, int limit)
 static int codePointBefore(char[] ach, int index)
 static int codePointBefore(char[] ach, int index, int start)
 static int codePointBefore(CharSequence seq, int index)
 static int digit(int cp, int radix)
 static int offsetByCodePoints(char[] ach, int start, int count, int index, int cpOffset)
 static int offsetByCodePoints(CharSequence seq, int index, int cpOffset)
 static char[] toChars(int cp)
 static int toChars(int cp, char[] dst, int dstIndex)
StringString(int[] acp, int offset, int count)
 int indexOf(int cp, int fromIndex)
 int lastIndexOf(int cp, int fromIndex)
StringBufferStringBuffer appendCodePoint(int cp)
 int codePointAt(int index)
 int codePointBefore(int index)
 int codePointCount(int beginIndex, int endIndex)
 int offsetByCodePoints(int index, int cpOffset)
StringBuilderStringBuilder appendCodePoint(int cp)
 int codePointAt(int index)
 int codePointBefore(int index)
 int codePointCount(int beginIndex, int endIndex)
 int offsetByCodePoints(int index, int cpOffset)
IllegalFormat
CodePointException		IllegalFormatCodePointException(int cp)
 int getCodePoint()

清单 11 展示了从一个码位创建一个字符串的 5 种方法。用于测试的码位是 U+53F1 和 U+20B9F，它们在一个字符串中重复了 100 亿次。清单 11 中的注释部分显示了处理时间：

清单 11. 从一个码位创建一个字符串的 5 种方法
int cp = 0x20b9f; // CJK Ideograph Extension B
String str1 = new String(new int[]{cp}, 0, 1);    // processing time: 206ms
String str2 = new String(Character.toChars(cp));                  //  187ms
String str3 = String.valueOf(Character.toChars(cp));              //  195ms
String str4 = new StringBuilder().appendCodePoint(cp).toString(); //  269ms
String str5 = String.format("%c", cp);                            // 3781ms

str1、str2、str3 和 str4 的处理时间没有明显不同。相反，创建 str5 花费的时间要长得多，因为它使用 String.format()，该方法支持基于本地和格式化信息的灵活输出。str5 方法应该只用于程序的末尾来输出文本。

回页首

结束语

Unicode 的每个新版本都包含了通过代理对表示的新定义的字符。东亚字符集标准并不是这样的字符的惟一来源。例如，移动电话中还需要支持 Emoji 字符（表情图释），还有各种古字符需要支持。您从本文收获的技术和性能分析将有助于您在您的 Java 应用程序中支持所有这些字符。

参考资料

学习

获得产品和技术

  • 以最适合您的方式 评估 IBM 产品：下载产品试用版，在线试用产品，在云环境下试用产品，或者在 IBM SOA Sandbox for People 中花费几个小时来学习如何高效实现面向服务架构。

讨论

转载于:https://my.oschina.net/hejunbinlan/blog/674113

chunqingtai2922
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Unicode代理对（utf-16）
黄腾霄的博客
02-29 2274
我们都知道Unicode的大部分字符都是都是使用16位编码，即2个字节表示。 这也是为什么正则匹配中，Unicode使用“\uxxxx”进行匹配的原因 为什么说是大部分呢？因为还有一个神奇的区域，叫做Unicode代理对。它们需要使用4个字节来表示一个字符。 这里就给大家做介绍。 问题来源 Unicode的产生是为了处理不同语言之间的编码不兼容问题。 比如如果中文和日文的不同文字使用了同一个编码...
Unicode代理对食用指南
c++的boost的博客
11-13 664
代理对，是由一个高位代理字符与一个低位代理字符组成的。所以，D800~DFFF之间的任何一个字符都不能单独出现。 代理对是干什么的？ 如果你有一个Unicode字符????（U+1F600），而在你的控制台里只能打印16位的Unicode（即0~FFFF） 你就可以使用代理对将其转化为两个16位字符了。 高位代理与低位代理各有0x400个字符。合起来可以表示0x100000个字符，也就是说1号平面至16号平面的字符都可以用代理对表示了。 如何计算代理对？ def nonBMPtoBMP(up):
Java Surrogate, isHighSurrogate, isLowSurrogate 是什么? 按字节截取emoji
张小凡
04-21 1547
字符编码相关的可以参考：【原创】经验分享：一个小小emoji尽然牵扯出来这么多东西？ 简单的说就是Java 语言内部的字符信息是使用 UTF-16 编码。因为char 这个类型是 16-bit 的。它可以有65536种取值，即65536个编号，每个编号可以代表1种字符。 65536 不够用。因此就从这65536个编号里，拿出2048个，规定它们是「Surrogates」，让它们两个为一组，来代表编号大于65536的那些字符。 更具体地，编号为 U+D800 至 U+DBFF 的规定为「High Sur.
Java编程的逻辑 (28) - 剖析包装类 (下)
07-20 107
​本系列文章经补充和完善，已修订整理成书《Java编程的逻辑》，由机械工业出版社华章分社出版，于2018年1月上市热销，读者好评如潮！各大网店和书店有售，欢迎购买，京东自营链接：http://item.jd.com/12299018.html 本节探讨Character类，它的基本用法我们在包装类第一节已经介绍了，本节不再赘述。Character类除了封装了一个char外，还有...
解析Unicode编码和Java char(转自Oilamp的163博客)
fantasy0126的专栏
12-02 3557
<br />http://chenbochiuan.vip.blog.163.com/blog/static/172332969201072784730795/<br /> Java的字符类型采用的是UTF-16编码方式对Unicode编码表进行表示。其中一个char类型固定2Bytes（16bits）。首先先介绍一下Unicode编码表和UTF-16编码算法：<br />       Unicode编码表的专业术语：<br />       代码点 (code point): 指在Unicode编码表中一
iPhone emoji问题牵出的Unicode代理区的思考
热门推荐
郭晓东的专栏
08-31 1万+
emoji 没什么特别的，也是正常的Unicode编码，只是通过代理区实现 这里说的utf-8和utf-16，其实本质上是一样的。只是utf-8是一个直接的映射。而utf-16需要根据代理区的（前导代理，后尾代理）来映射。utf-16比utf-8多了一步而已！ 话又说回来：如果不是代理区域的出现，就emoji 微笑的unicode： 0X1-F603来说。计算机甚至不知道这是一个字符，还是两个字符！ 所以，搞了一个Unicode：D83D-DE03来表示unicode： 0X1-F603，防止计算机解码混
java 中文Unicode转换
11-19
在Java编程语言中，Unicode编码是一种广泛使用的字符集，它包含了世界上几乎所有的文字，包括中文。Unicode使得在程序中处理不同语言的文本变得更加方便。本文将深入探讨如何在Java中进行中文字符到Unicode编码的...
JAVA_API1.6文档（中文）
04-12
java.lang.instrument 提供允许 Java 编程语言代理检测运行在 JVM 上的程序的服务。 java.lang.management 提供管理接口，用于监视和管理 Java 虚拟机以及 Java 虚拟机在其上运行的操作系统。 java.lang.ref 提供...
十进制与unicode互转
11-27
本资源主要关注的是“十进制与Unicode”之间的转换，这在Java编程中尤其常见，因为Java使用Unicode作为其内部字符集。Unicode是一个包含世界上几乎全部字符的编码标准，而十进制则是我们日常计算中最常用的数制系统...
java_charactor.zip_java charactor
最新发布
09-22
1. **Unicode编码**：Java中的字符使用Unicode编码，这使得程序能够处理多语言文本，包括但不限于英语、中文、日文、希腊文等。每个Unicode字符都有一个唯一的数字表示，称为码点，范围从0x0000到0xFFFF，甚至扩展到...
java解析emoji表情存入oracle，并正常使用
03-16
Java作为一种广泛使用的编程语言，可以作为解决这一问题的桥梁。本文将深入探讨如何通过Java解析emoji表情并将其安全地存入Oracle数据库，以及在移动端恢复显示这些表情。 首先，我们需要了解emoji表情的本质。它们...
Unicode | 代理项（Surrogate）
Blume 的博客
06-10 937
代理项（Surrogate），是一种仅在 UTF-16 中用来表示补充字符的方法。在 UTF-16 中，为补充字符分配两个 16 位的 Unicode 代码单元：第一个代码单元，被称为高代理项代码单元或前导代码单元；第二个代码单元，被称为低代理项代码单元或尾随代码单元。这两个代码单元组合在一起，就被称为代理项对。
Unicode代理对机制
记录与分享
04-13 318
静下心来，好好思考 unicode只能表示65536个文字或符号 而超过65536的部分使用的是代理对解决的 这边分享一篇好文， 讲得十分清楚。 原文作者：xinyue_htx 原文地址：https://blog.csdn.net/htxhtx123/article/details/104569063 这里发现一片 版权声明：本文为CSDN博主「xinyue_htx」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接： ...
StringBuffer.reverse()中surrogate pair的问题
aa1382525的专栏
10-25 1076
众所周知java采用UTF-16编码unicode字符集。 UTF-16使用使用一个6位单元或者两个16为单元表示一个unicode字符。使用两个单元的，前面那个单元叫highsurrogate 后面那个叫lowsurrogate。  public AbstractStringBuilder reverse() {         boolean hasSurrogates = false;
Java中的字符集编码入门
low_coder
03-07 1326
Java中的字符集编码入门（一）Unicode与UCS的历史恩怨按：这是早前发表在我个人其他博客上的文章，现在根据文本分类和网页设计的需要进行重新的汇编和整理，也加入了一 些新东西，希望对感兴趣的人有所帮助。 ASCII及相关标准 地球人都知道ASCII就是美国标准信息交换码的缩写，也知道ASCII规定用7位二进制数字来表示英文字符，ASCII被定为国际标准之后的代号为ISO-646。由于A
详解Character中的相关code-point方法
Beyond的个人博客
07-20 2161
详解Character中的相关code-point方法缘由Unicode和Code-point的关系APICharacter.codePointCountCharacter.codePointAt 缘由 在java中有许多针对code-point的相关方法，由于工作需要，对部分常用的code-point方法进行记录下。 Unicode和Code-point的关系 “一个普通字符是一位，一个emoji表情是两位。Mysql应该用utf8mb4存储emoji，而不应该用utf8”这是大多数人真正意义上去了解到u
StringUtils.toCodePoint(str)方法分析
lovepeacee的博客
08-16 4472
StringUtils.toCodePoint(str)方法分析 根据我自己的实际操作分析该方法是将str中各个字符的十进制unicode码 并放在int[]数组中.下面是实际代码操作: public static void main(String[] args) { int[] asds = StringUtils.toCodePoints("a汉字"); ...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值