为何ICU的ucnv_getNextUChar不设置错误码？替代字符相关疑问

问题重现 #

测试代码 #

#include <unicode/ucnv.h>
#include <stdio.h>

UConverter * converter;
void test_char(char inchar){
    const char * inbuf=&inchar;
    UErrorCode err=U_ZERO_ERROR;
    UChar32 c = ucnv_getNextUChar(
        converter,
        &inbuf,
        inbuf+1,
        &err
    );

    printf("%x %s\n", c, u_errorName(err));
}
int main(){
    UErrorCode err=U_ZERO_ERROR;
    converter = ucnv_open("cp932", &err);
    test_char(0x41); /*A*/
    test_char(0xB1); /*ｱ*/
    test_char(0xE1); /*预期返回U_TRUNCATED_CHAR_FOUND*/
    test_char(0xF1); /*预期返回U_INVALID_CHAR_FOUND*/
    return 0;
}

实际输出 #

41 U_ZERO_ERROR
ff71 U_ZERO_ERROR
1a U_ZERO_ERROR
1a U_ZERO_ERROR

核心问题解答 #

1. 为何无效字符始终返回U_ZERO_ERROR？ #

ICU默认启用容错转换策略：遇到无效字节、截断字节序列时，转换器会自动用替代字符替换错误内容，继续执行转换流程，不会主动设置错误码。要触发错误码，必须手动修改转换器的错误处理回调为停止模式，示例代码如下：

// 在ucnv_open成功后添加以下代码
ucnv_setToUCallBack(converter, UCNV_TO_U_CALLBACK_STOP, NULL, NULL, NULL, &err);

设置后，遇到无效/截断字符时会立即终止转换，并设置对应的错误码（U_TRUNCATED_CHAR_FOUND或U_INVALID_CHAR_FOUND）。

2. 为何返回0x1A替代控制码？ #

0x1A是ICU默认的替代字符（U+001A SUBSTITUTE），属于ASCII控制字符。当转换器无法解析输入字节时，会自动用这个字符替换错误序列，这是ICU预设的容错机制，避免转换流程中断。

3. 替代字符是否为有效的SHIFT-JIS（CP932）字符？ #

0x1A在CP932编码中是合法的单字节控制字符，对应ASCII的SUB控制码。但它并非用于表示正常文本的字符，仅作为错误场景下的占位符使用。

4. 如何区分有效替代字符与无效SHIFT-JIS字符串？ #

• 推荐方案：切换到严格转换模式：通过设置UCNV_TO_U_CALLBACK_STOP回调，让转换器遇到错误时直接返回错误码，而非替换。这种方式可以通过UErrorCode的取值直接判断输入是否有效，是最可靠的方案。
• 若必须使用容错模式：可以检查转换后的字符是否为U+001A，但需注意——如果原始输入本身包含0x1A字节，转换后也会得到U+001A，这种情况无法通过字符值区分原始有效输入和错误替换，因此严格模式仍是首选。

内容的提问来源于stack exchange，提问作者oshaboy