uint8_t vs unsigned char
问题的出现原因是为了编写与实现无关的代码，使用unsigned char不能保证是一个8位的类型，而uint8_t是一个8位的类型（如果可用）。
解决方法是如果uint8_t在系统上存在，可以使用find和sed来自动将所有uint8_t的出现更改为unsigned char或其他对你更有用的类型。另外可以加入断言assert(sizeof(unsigned char) == 8)来检查unsigned char是否为8位。还可以使用#if CHAR_BIT == 8或#ifdef UINT8_MAX来检查uint8_t是否可用。
总结起来，使用uint8_t可以保证代码的实现独立性，并且确保数据类型为8位。而使用unsigned char则不能保证数据类型为8位。因此，如果需要确保数据类型为8位，应使用uint8_t。
在讨论中，有人提出了一个关于(uint8_t vs unsigned char)的问题。根据维基百科的说明，标准库stdint.h要求在系统中定义8位、16位、32位或64位的精确宽度整数类型，但并不要求定义其他宽度的整数类型。因此，虽然在所有8位=1字节的平台上都会有uint8_t类型，但并不能保证它的存在。在一些嵌入式平台上可能会有不同的情况，但这种情况已经非常少见了。另外，一些系统可能将char类型定义为16位，这种情况下可能就不会有任何8位的类型。
除了这个（小）问题之外，根据Ransom的回答，我认为最好的解决方法是使用最能清楚地显示你正在使用数据的类型。此外，我假设你指的是uint8_t（C99标准中在stdint.h头文件中定义的typedef），而不是uint_8（不属于任何标准）。
在一些具有CHAR_BIT > 8的DSP中，这种情况变得越来越少见，而不是越来越多见。对于这些DSP，你能否提供一些相关描述的链接？我知道它们存在，因为在一个关于C/C++类型保证是否过于弱的comp.lang.c++.moderated讨论中，某些情况下了一个这样的DSP（并链接到了开发人员文档），但我现在找不到那个讨论了，所以在类似的讨论中参考它总是很方便的 🙂
“一些系统可能将char类型定义为16位，这种情况下可能就不会有任何8位的类型。”尽管我有一些错误的反对意见，但Pavel在他的回答中证明了，如果char是16位的，那么即使编译器确实提供了8位的类型，它也不能称它为uint8_t（或将其typedef为该类型）。这是因为8位类型的存储表示中会有未使用的位，而uint8_t不能有这种情况。
SHARC架构采用32位字长度，有关详细信息请参见en.wikipedia.org/wiki/…。
TI的C5000 DSP（在OMAP1和OMAP2中使用）是16位的。我认为在OMAP3中，他们转向了C6000系列，其中包括一个8位的char。
在C++的工作草案N3242中，在第18.4.1节typedef unsigned integer type uint8_t; // optional。因此，实际上，一个符合C++标准的库根本不需要定义uint8_t（参见注释//optional）。
在最小数据类型大于8位的情况下（例如Ti的C2000系列，它们是16位的），我认为可以使用uint_least8_t来正确表示意图，并且该类型实际上可能不是8位的。
在C语言中，有两种方式可以表示8位无符号整数：uint8_t和unsigned char。这两种方式在语义上有一些差异，因此在使用时需要根据具体情况选择合适的方式。
首先，uint8_t是一个typedef，它明确表明数据将被用作小型数字，而不是字符。如果同时使用其他的typedef，如uint16_t或int32_t，那么使用uint8_t会使代码看起来更加规范。
与之相比，使用unsigned char则明确表示数据将被用作字符。在没有任何修饰的情况下使用char时，会暗示数据将被用作字符。
另外，使用uint8_t表示字符串并没有错，但确实有些奇怪。uint8_t可以存储0-255的整数值，与以前使用unsigned char的语法相同，但更加符合语法规范。
有人可能会认为未修饰的unsigned是指unsigned int，这是定义中的规定吗？
很抱歉给出了错误的信息...我知道枚举和int是不同的类型，并且我认为对于可以自动转换为int的其他类型也是如此。或者这可能取决于编译器...
我认为在使用UTF8文本时，可以使用uint8_t。实际上，char似乎暗示了一个字符，而在UTF8字符串的上下文中，它可能只是一个多字节字符的一个字节。使用uint8_t可以清楚地表明每个位置上都不一定是一个字符，换句话说，字符串/数组的每个元素都是一个任意的整数，不应该对其做任何语义假设。当然，所有的C程序员都知道这一点，但对于初学者来说，这可能会促使他们提出正确的问题。
我必须说，unsigned char并不是用来存储字符的，因此关于“意图”的问题是无关紧要的。
这是出于历史原因。我认为我们可以假设它最初被用于存储字符（char的缩写相当明确），但实际上并没有，因为在C99中出现了inttypes.h之前，它是历史上唯一的标准8位数据类型。现在我们有了inttypes.h，我觉得比较原始数据类型和较新的(u)int_(least/fast)N_t数据类型时，重点实际上是意图，以及代码是否以精确的宽度编译或根本不编译的意图。