@akunohana Yes! Although I would say that ASCII is a pretty safe assumption and it’s really anything above the top of ASCII that you need to account for (document as a requirement for your program, or take steps to ensure the OS uses the right encoding if you are packaging something for distribution)

@akunohana OK that's a pretty good question then. In that case the encoding is determined by your terminal (or if not terminal then execution environment). Try invoking env (or locale) and looking at LANG and LC_ALL; those should tell you what your terminal accepts as input and passes along to your program.

@akunohana The compiler doesn't need to know that 0x18 is CAN; that knowledge is embedded in whatever decided that the data you're inspecting is UTF-8 or ASCII.

The content of your original post has been replaced with a link that I can't open so I can't go back and confirm where you said the data was coming from. But if the data was some other exotic encoding then 0x18 would mean something else in the context of that data.

@akunohana Apologies if I'm missing something, but 0x30, 0x39, and 0x18 are merely hex notation for integers. You could have written 48, 57, and 24 instead for the same effect. Or you (probably?) could have used char literals like '0', '9' (I guess there isn't one for U+0018).

UTF-8 determines how the characters are encoded, i.e. what sequence of numbers (ints) they are represented by. So there's no special understanding of Unicode or hex going on here; you're comparing numbers (as you should).