c - 多字节语言环境中 glibc 的 printf 截断错误的解决方法？

Question

某些基于 GNU 的操作系统发行版 (Debian) 仍然受到 GNU libc 中的一个错误的影响，该错误会导致 printf 函数系列在以下情况下返回虚假的 -1指定的精度级别将截断多字节字符。此错误已在 2.17 中修复并反向移植到 2.16。 Derby 安 has an archived bug为此，维护人员似乎无意将修复程序反向移植到 Wheezy 使用的 2.13。

以下文字引自https://sourceware.org/bugzilla/show_bug.cgi?id=6530 . (请不要再次编辑内联 block 引用。)

Here's a simpler testcase for this bug courtesy of Jonathan Nieder:

#include <stdio.h>
#include <locale.h>

int main(void)
{
    int n;

    setlocale(LC_CTYPE, "");
    n = printf("%.11s\n", "Author: \277");
    perror("printf");
    fprintf(stderr, "return value: %d\n", n);
    return 0;
}

Under a C locale that'll do the right thing:

$ LANG=C ./test
Author: �
printf: Success
return value: 10

But not under a UTF-8 locale, since \277 isn't a valid UTF-8 sequence:

$ LANG=en_US.utf8 ./test
printf: Invalid or incomplete multibyte or wide character

值得注意的是，在此上下文中，printf 还将用 \0 覆盖输出数组的第一个字符。

我目前正在尝试改进 MUD 代码库以支持 UTF-8，但不幸的是，代码中充斥着使用任意 sprintf 精度来限制发送到输出缓冲区的文本量的情况。由于大多数程序员不期望在此上下文中返回-1，这个问题变得更糟，这可能导致未初始化的内存读取和级联的错误从那个。 (已经在 valgrind 中捕获了一些案例)

有没有人想出一个简洁的解决方法来解决他们代码中的这个错误，而不涉及重写具有任意长度精度的格式化字符串的每一次调用？我可以接受将截断的 UTF-8 字符写入我的输出缓冲区，因为在套接字写入之前在我的输出处理中清理它是相当微不足道的，而且在一个最终会解决的问题上投入这么多精力似乎有点过头了再过几年。

Answer 1

我猜，问题的评论似乎证实了，您并没有使用那么多 C 库的特定于区域设置的功能。在这种情况下，您最好不要将语言环境更改为基于 UTF-8 的语言环境，而将其保留在您的代码采用的单字节语言环境中。

当您确实需要将 UTF-8 字符串作为 UTF-8 字符串处理时，您可以使用专用代码。编写您自己的 UTF-8 处理例程并不难。您甚至可以下载 Unicode Character Database并做一些相当复杂的字符分类。如果您更喜欢使用第三方库来处理 UTF-8 字符串，可以使用 ICU正如您在评论中提到的。这是一个相当重量级的库，之前的一个问题推荐了一些 lighter weight alternatives .

也可以根据需要来回切换 C 语言环境，以便您可以使用 C 库的功能。但是，您需要检查这对性能的影响，因为切换区域设置可能是一项昂贵的操作。