Home/ Questions/Q 6635841
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T23:06:27+00:00

Say I have a function that receives a byte array: void fcn(byte* data) {

  • 0

Say I have a function that receives a byte array:

void fcn(byte* data)
{
...
}

Does anyone know a reliable way for fcn() to determine if data is an ANSI string or a Unicode string?

Note that I’m intentionally NOT passing a length arg, all I receive is the pointer to the array. A length arg would be a great help, but I don’t receive it, so I must do without.

This article mentions an OLE API that apparently does it, but of course they don’t tell you WHICH api function: http://support.microsoft.com/kb/138142

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    First, a word on terminology. There is no such thing as an ANSI string; there are ASCII strings, which represents a character encoding. ASCII was developed by ANSI, but they’re not interchangable.

    Also, there is no such thing as a Unicode string. There are Unicode encodings, but those are only a part of Unicode itself.

    I will assume that by “Unicode string” you mean “UTF-8 encoded codepoint sequence.” And by ANSI string, I’ll assume you mean ASCII.

    If so, then every ASCII string is also a UTF-8 string, by the definition of UTF-8’s encoding. ASCII only defines characters up to 0x7F, and all UTF-8 code units (bytes) up to 0x7F mean the same thing as they do under ASCII.

    Therefore, your concern would be for the other 128 possible values. That is… complicated.

    The only reason you would ask this question is if you have no control over the encoding of the string input. And therefore, the problem is that ASCII and UTF-8 are not the only possible choices.

    There’s Latin-1, for example. There are many strings out there that are encoded in Latin-1, which takes the other 128 bytes that ASCII doesn’t use and defines characters for them. That’s bad, because those other 128 bytes will conflict with UTF-8’s encoding.

    There are also code pages. Many strings were encoded against a particular code page; this is particularly so on Windows. Decoding them requires knowing what codepage you’re working on.

    If you are in a situation where you are certain that a string is either ASCII (7-bit, with the high bit always 0) or UTF-8, then you can make the determination easily. Either the string is ASCII (and therefore also UTF-8), or one or more of the bytes will have the high bit set to 1. In which case, you must use UTF-8 decoding logic.

    Unless you are truly certain of that these are the only possibilities, you are going to need to do a bit more. You can validate the data by trying to run it through a UTF-8 decoder. If it runs into an invalid code unit sequence, then you know it isn’t UTF-8. The problem is that it is theoretically possible to create a Latin-1 string that is technically valid UTF-8. You’re kinda screwed at that point. The same goes for code page-based strings.

    Ultimately, if you don’t know what encoding the string is, there’s no guarantee you can display it properly. That’s why it’s important to know where your strings come from and what they mean.

    • 0