这是我工作中一个长期存在的问题，我意识到我still没有好的解决办法...
C 天真地为 int 定义了它的所有字符测试函数：
int isspace(int ch);
但是字符通常是带符号的，并且完整的字符通常不适合 int 或用于字符串的任何单个存储单元*****。
这些函数已成为当前 C++ 函数和方法的逻辑模板，并为当前标准库奠定了基础。事实上，他们仍然受到支持。
因此，如果您传递 isspace(*pchar) ，您最终可能会遇到符号扩展问题。它们很难被发现，因此根据我的经验，它们很难防范。
类似地，因为 isspace() 及其同类都采用整数，并且因为字符的实际宽度通常在没有字符串分析的情况下是未知的 - 这意味着任何现代字符库本质上都不应该围绕 char 或 wchar_t 而只围绕指针/迭代器，因为只有通过分析字符流才能知道它有多少组成单个逻辑字符，所以我对如何最好地解决这些问题感到有点茫然？
我一直期待一个真正强大的库，基于抽象出任何字符的大小因素，并且仅使用字符串（提供 isspace 等），但要么我错过了它，要么有另一个更简单的解决方案在等着我面对你们所有人（知道自己在做什么的人）都使用...
** 对于可以完全包含完整字符的固定大小的字符编码，这些问题不会出现 - UTF-32 显然是具有这些特征的唯一选项（或将自身限制为 ASCII 或某些此类的特殊环境） 。
所以，我的问题是：
“如何以一种不会遇到两个问题的方式测试空白、可打印等：
1) 符号扩展，以及
2）变宽字符问题
毕竟，大多数字符编码是可变宽度的：UTF-7、UTF-8、UTF-16 以及旧标准（例如 Shift-JIS）。如果编译器将 char 视为带符号的 8 位单元，那么即使是扩展的 ASCII 也可能存在简单的符号扩展问题。
请注意：
无论你的 char_type 大小是多少，对于大多数字符编码方案来说都是错误的。
这个问题在标准C库中，以及在C++标准库中；它仍然尝试在各种 isspace、isprint 等实现中传递 char 和 wchar_t，而不是字符串迭代器。
实际上，正是这些类型的函数破坏了 std::string 的通用性。如果它只在存储单元中工作，并且不试图假装将存储单元的含义理解为逻辑字符（例如 isspace），那么抽象就会更加诚实，并且会迫使我们程序员去寻找其他地方寻找有效的解决方案...
谢谢
所有参与的人。在这次讨论和WChars、编码、标准和可移植性 https://stackoverflow.com/questions/6300804/wchars-encodings-standards-and-portability我对这些问题有了更好的处理。尽管没有简单的答案，但一点点理解都会有所帮助。
