4

我在我的 C 应用程序中使用 ISO 8859-1（拉丁扩展 ASCII 字符集）。当我strcpy/strcat字符串的部分在一起时，它工作正常。但是，当我sprintf("%s %s")在某些运行时（尤其是某些 Android 版本）上使用 , 时，当扩展的 ASCII 字符（特别是é，虽然我没有尝试过其他字符）被击中时，字符串将被截断。

我以为%s只是应该复制字节直到'\0'被击中。我怀疑strcpy/strcat有效，因为它确实做到了这一点，没有任何格式。这里可能发生了什么？

我应该注意，我不是在查看文本printf()，而是使用我自己的文本渲染引擎来处理 ISO-8859-1 就好了。

更新：为了澄清，我有一个 NDK 应用程序，它将字符串保存在 C 中，并将其传递给我的基于 OpenGL 的文本渲染引擎。如果我将完整的字符串作为 char* 文字传递，它会显示得很好。如果我 sprintf() 将这些部分放在一起，它会在 é 字符处被截断。例如：

char buffer[1024];
strcpy(buffer, "This is ");
strcat(buffer, "the string I want to diésplay.");

这显示得很好。但是这个：

sprintf(buffer, "%s%s", "This is ", "the string I want to diésplay.");

打印为：

This is the string I want to di
4

1 回答 1

1

的行为与和s[n]printf()等字符串操作函数的行为不同。当呈现相同的格式和打印项目时，-family 函数都需要生成相同的字节序列。唯一的区别在于这些字节的发送位置。因此，如果您的 C 库的构建使得它在通过 打印到标准流时对字符串数据执行转换（可能是转码），那么在通过 打印到字符串时它将执行相同的转换。strcpy()strcat()printfprintf()sprintf()

“printf”中的“f”代表“格式化”。该标准既没有说也没有暗示格式化字符串必须意味着将其字节逐字转储到输出中，因此我上面假设的转码或其他转换并不是不可能的。事实上，这些函数的某些版本的文档表明依赖于语言环境（“请注意，生成的字符串的长度取决于语言环境并且难以预测”），因此特别是转码是一种真正的可能性。

您描述的第三方观察的任何具体解释都必然是推测性的，因为您没有提供几乎足够的代码或数据来做出自信的诊断。我倾向于怀疑围绕在使用与程序内部使用的字符编码不同的字符编码的语言环境中运行程序的问题。如果是这样，那么您可以通过改变您运行的语言环境在本地重现问题，并且您可以通过确保您的程序始终在合适的语言环境中运行的一种或另一种方式来解决它。除其他外，您可以使用getlocale()和setlocale()函数在这里提供帮助，特别是如果您想限制您行使区域设置控制的范围。

但是，由于最终您仅将 printf-family 函数用于字符串操作，因此我认为最好使用问题中提出的解决方法：尽可能使用 C 的专用字符串操作函数，例如strcpy()and strncat()，执行您的字符串构建。由于您的实际输出不依赖于 stdio 函数，因此应该没问题。

于 2016-01-28T16:53:01.913 回答