All the UTF-8 codepoints can be held inside an 8bit char, which is what this library seems to use under the covers.
You might need to add a couple UTF-specific methods if you want number of graphemes rather than number of bytes, but there's nothing to stop you placing UTF8 data inside a char buffer.
I mentioned UTF-8 specifically, because the UTF-8 encoding actually does specify this particular feature:
> UTF-8 is capable of encoding all 1,112,064 valid character code points in Unicode using one to four one-byte (8-bit) code units. Code points with lower numerical values, which tend to occur more frequently, are encoded using fewer bytes. [0]
UTF-8 is a variable length encoding, some characters need 8 bits, other characters need 32 bits per your own quote.
And it is designed so that it fits in one-byte units. That was a central goal of the encoding.
So... If you have a char buffer, like we have been talking about, you can toss any valid UTF-8 sequence inside it.
Up to you to make sense of the data in singles, pairs, fours, and before that to declare the buffer as the appropriate multiplier plus 1.
If you naively put the bytes of UTF-16 or UTF-32 encodings into a buffer, they might contain NUL (zero) byte values. Which, for C strings, means "end of string". UTF-8 makes sure this doesn't happen, which makes it compatible with existing C string functions.