有大量关于 Unicode 代码单元、代码点等的信息，但我对使用字节流（libiconv需要）转换组合字符、字素等仍然有点模糊。
目前我只对使用 libconv 的 UTF-8/UTF-16/UTF-32 之间的转换感兴趣iconv()，它期望源缓冲区和目标缓冲区的字节长度作为参数。
问题：是否有一种安全的方法可以根据源缓冲区的已知字节长度快速计算目标缓冲区的最大可能字节长度？
比方说，例如，使用已知（如果有的话，不包括 0x0000 终止）从u16buf到转换。在最坏的情况下，UTF-16 源缓冲区中的每个代码点将有 1 个两字节单元，对应于 UTF-8 目标缓冲区中每个代码点的 4 个单字节单元。这足以安全地假设 UTF-8 目标缓冲区永远不会超过？u8bufu16byteslen2 * u16lenbytes
我实际上已经尝试过并且似乎有效，但我不确定我是否遗漏了涉及组合字符和字素簇的极端情况。我的怀疑来自于我对这些东西如何在这 3 种不同编码之间转换的无知。我的意思是，字素是否可能需要说 3 个 UTF-16 代码点，但在转换时需要 10 个 UTF-8 代码点？
在这种情况下，翻倍u16lenbytes是不够的，对吧？如果是这样，有没有其他直接的方法来预先计算目标缓冲区的最大长度？
gprof在我的系统上运行不正常(MinGW)所以我想知道以下哪个片段平均效率更高.
我知道内部C编译器会将所有内容转换为指针算术,但我仍然想知道以下任何一个代码段是否比其他代码段具有任何显着优势.
该数组已作为1d数组动态分配在连续内存中,并且可以在运行时重新分配(它用于简单的棋盘游戏,允许玩家按照自己的意愿重新定义棋盘的大小) .
请注意,i&j必须计算并在每次循环迭代中传递给函数set_cell()(gridType是一个带有几个int的简单结构和一个指向另一个单元结构的指针).
提前致谢!
分配内存
grid = calloc( (nrows * ncols), sizeof(gridType) );
片段#1(按顺序解析为1D)
gridType *gp = grid;
register int i=0 ,j=0; // we need to pass those in set_cell()
if ( !grid )
return;
for (gp=grid; gp < grid+(nrows*ncols); gp++)
{
set_cell( gp, i, j, !G_OPENED, !G_FOUND, value, NULL );
if (j == ncols-1) { // last col of current row has been reached
j=0;
i++;
}
else // last col of current row has NOT been …