我很难相信我是第一个遇到这个问题的人,但我找了很长时间,没有找到解决这个问题的方法。
我想使用strncpy
,但它是UTF8感知的,所以它不会部分地将utf8代码点写入目标字符串。
否则,您永远无法确定结果字符串是有效的UTF8,即使您知道源是(当源字符串大于最大长度时)。
验证结果字符串可以工作,但如果这是要调用很多,最好有一个strncpy函数来检查它。
glib有g_utf8_strncpy
,但它复制了一定数量的unicode字符,而我正在寻找一个受字节长度限制的复制函数。
需要明确的是,“utf8 aware”,我的意思是它不应该超过目标缓冲区的限制,并且它必须永远只复制utf-8代码点的一部分。(给定有效的utf-8输入,永远不会导致无效的utf-8输出)。
注:
一些回复指出,strncpy
空所有字节,它不会确保零终止,回想起来,我应该要求一个utf8感知**strlcpy
**,但当时我不知道这个函数的存在。
6条答案
按热度按时间ezykj2lf1#
我已经在许多包含多字节字符的UTF8示例字符串上测试了这个方法。如果源代码太长,它会反向搜索它(从null终止符开始),并向后查找最后一个可以放入目标缓冲区的完整UTF8字符。它总是确保目标是null终止的。
mwecs4sa2#
我不知道你说的UTF-8感知是什么意思;
strncpy
复制字节,而不是字符,缓冲区的大小也是以字节为单位的。如果你的意思是它只复制完整的UTF-8字符,例如,如果没有下一个字符的空间,就停止,我不知道这样的函数,但它应该不会太难写:(The在utf8 Size中生成表的内容有点麻烦,但是如果你处理UTF-8,这是一个你会经常使用的函数,而且你只需要做一次。
2izufjch3#
为了回答自己的问题,这里的C函数我结束了(不使用C为这个项目):
注意:-要知道这不是utf8的
strncpy
的克隆,它更像是来自openbsd的strlcpy
。- utf8_skip_data从glib的gutf8.c复制-它不验证utf8 -这是我的意图。希望这对其他人有用,并对反馈感兴趣,但请不要对
NULL
终止行为学究气的狂热者,除非它是一个实际的错误,或误导/不正确的行为。感谢James Kanze,他提供了这方面的基础,但不完整和C(我需要一个C版本)。
0dxa2lsx4#
strncpy()
是一个很糟糕的函数:1.如果没有足够的空间,结果字符串将不以nul结尾。
1.如果有足够的空间,剩余部分将用NULL填充。如果目标字符串非常大,这可能会很痛苦。
即使字符保持在ASCII范围内(0x 7 f及以下),结果字符串也不会是你想要的。在UTF-8的情况下,它可能不是以null结尾的和以无效的UTF-8序列结尾的。
最好的建议是避免
strncpy()
。**编辑:**ad 1):
同意,缓冲区不会溢出。但结果仍然是不需要的。strncpy()只解决了问题的一部分。它是误导和不需要的。
更新(2012-10-31):由于这是一个令人讨厌的问题,我决定破解我自己的版本,模仿丑陋的strncpy()行为。
x7rlezfr5#
下面是一个C++解决方案:
u8string.h
:u8slbcpy.cpp
:函数
u8slbcpy()
有一个C接口,但它是用C++实现的。我的实现使用的是仅头部的UTF8-CPP library。我想这差不多就是您要找的东西,但是请注意,如果组合字符应用于第 n 个字符,则仍然存在一个或多个组合字符可能无法复制的问题(本身不是组合字符),并且目的地缓冲区刚好足够大以存储字符1到 n 的UTF-8编码,但不写入字符 n 的组合字符。在这种情况下,写入了表示字符1到 n 的字节,但没有写入 n 的组合字符。实际上,可以说第 n 个字符被部分写入。
yyyllmsg6#
评论上面的答案“strncpy()是一个可怕的函数:“.我讨厌甚至评论这样的毯子声明在创建另一个互联网编程圣战的代价,但无论如何,因为像这样的声明是误导那些可能来这里寻找答案.
好吧,也许C字符串函数是“老派”的。也许C/C中的所有字符串都应该在某种智能容器中,等等,也许应该使用C而不是C(当你有选择的时候),这些更多的是一种偏好和其他主题的争论。
我来这里寻找一个UTF-8 strncpy()我自己。不是说我不能做一个(编码是IMHO简单和优雅),但想看看别人是如何使他们的,也许找到一个优化的ASM之一。
对于编程世界的人们来说,把你的傲慢放在一边,看看一些事实。
“strncpy()"或任何其他类似的函数都没有问题,它们具有相同的副作用和问题,如“_snprintf()"等。
我说:“strncpy()并不可怕”,而是“可怕的程序员使用它非常糟糕”。
什么是“可怕的”是不知道的规则.此外,在整个主题,因为安全(如缓冲区溢出)和程序稳定性的影响,就不会有一个需要,例如微软添加到它的CRT库“安全字符串函数”,如果只是遵循规则.
主要的:
1.“sizeof()”返回带有终止符的静态字符串的长度。
1.“strlen()”返回字符串的长度,不带终止符。
1.大多数(如果没有的话)“n”函数只是箝位到“n”,而不添加终止符。
1.在需要和输入缓冲区大小的函数中,“缓冲区大小”是什么是隐含的模糊性。即“(char *pszBuffer,int iBufferSize)”类型。更安全的是假设最坏的情况,并传递比实际缓冲区大小小一的大小,并在末尾添加终止符以确保安全。
1.对于字符串输入,缓冲区等,根据预期的平均值和最大值设置和使用合理的大小限制。希望避免输入截断,并消除缓冲区溢出周期。
这是我个人处理这类事情的方式,还有其他规则,只是要知道和实践。
一个方便的静态字符串大小宏:
声明本地/堆栈字符串缓冲区时:
A)例如,将终止符的大小限制为1023+1,以允许字符串的长度达到1023个字符。
B)我将字符串的尺子初始化为零,并在最后终止以覆盖可能的'n'截断。
或者,可以只执行以下操作:
char szBuffer[1024] = {0};
,但是对于编译器生成的memset()来说有一些性能暗示,比如调用整个缓冲区为零。这使得调试更干净,我更喜欢静态(相对于本地/堆栈)字符串缓冲区的这种风格。现在一个“strncpy()”遵循以下规则:
当然还有其他的“规则”和问题,但这些是最主要的,你只需要知道lib函数是如何工作的,并使用这样的安全实践。
最后,在我的项目中,无论如何我都使用ICU,所以我决定使用它并使用“utf8.h”中的宏来创建我自己的“strncpy()”。