OSX 12.0.1下ncurses 6.3仅部分Unicode字符显示异常问题

• 运行环境：OSX 12.0.1，ncurses 6.3
  测试代码如下：

#define NCURSES_WIDECHAR 1

#include <locale.h>
#include <ncurses.h>

int main() {
  setlocale(LC_ALL, "");

  initscr();
  // prints fine. Even the red heart, which is multiple code-points.
  addwstr(L"🙂❤️\n");
  // doesn't print the check mark. Interesting...
  addwstr(L"️✅");
  refresh();
  getch();
  endwin();

  // Prints fine.
  printf("%ls\n", L"✅");

  return 0;
}

• 运行测试观测到的现象：
  • 调用addwstr输出🙂❤️可正常显示，即便是多码点的红色爱心表情也能正常打印
  • 调用addwstr无法正常输出对勾✅表情
  • 退出ncurses模式后，使用printf输出✅则完全正常
  • 无法确认该现象是ncurses本身的bug，还是ncurses接口使用方式错误导致

这个问题不是接口使用方式错误，是兼容层和字符计算逻辑共同导致的：

1. 测试代码中第二个传入addwstr的宽字符串开头，隐含了一个孤立的U+FE0F变体选择符（即表情常用的VS16彩色变体标记，属于零宽组合字符，单独出现时不渲染内容）。ncurses处理零宽字符时的光标位置计算逻辑存在缺陷，遇到孤立的零宽组合字符不会自动跳过位置校验，会导致后续字符的输出坐标计算偏差，最终把✅写到屏幕可见区域外，看起来就像没有输出。
2. macOS系统自带的ncurses是经过苹果修改的兼容版本，并非官方原版ncurses 6.3，其依赖的系统wcwidth接口对部分emoji的列宽计算错误：比如✅这类emoji在终端实际渲染占2个列宽，但系统wcwidth会错误返回宽度1，ncurses按照返回值计算光标偏移时会出现错位，后续输出的内容会覆盖前半部分字符，也会导致字符显示异常。
3. printf输出时不做光标位置、列宽的预计算，直接把字符序列输出到终端，由终端自行解析渲染，所以不会出现ncurses下的错位问题。

• 排查传入addwstr的宽字符串内容，逐字符打印编码值，删除字符串中孤立存在的零宽控制字符、孤立的变体选择符，避免异常字符干扰ncurses的坐标计算。
• 不要使用macOS系统自带的ncurses库，自行编译官方原版ncurses 6.3+版本，编译时开启--enable-widec参数，编译完成后链接时优先链接自行编译的宽字符版本库，规避系统自带版本的兼容问题。
• 对于部分新发布的emoji，如果系统wcwidth仍然返回错误的宽度值，可以在输出这类字符后手动调用wmove接口调整光标位置，补上宽度计算的差值，避免后续输出错位。

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