如何在c ++字符串中搜索非ASCII字符？

Question

string s="x1→(y1⊕y2)∧z3";

for(auto i=s.begin(); i!=s.end();i++){
    if(*i=='→'){
       ...
    }
} 

The char comparing is definitely wrong, what's the correct way to do it? I am using vs2013.

Answer 1

First you need some basic understanding of how programs handle Unicode. Otherwise, you should read up, I quite like this post on Joel on Software .

You actually have 2 problems here:

Problem #1: getting the string into your program

Your first problem is getting that actual string in your string s . Depending on the encoding of your source code file, MSVC may corrupt any non-ASCII characters in that string.

• either save your C++ file as UTF-16 (which Windows confusingly calls Unicode ), and use whcar_t and wstring (effectively encoding the expression as UTF-16). Saving as UTF-8 with BOM will also work. Any other encoding and your L"..." character literals will contain the wrong characters.

  Note that other platforms may define wchar_t as 4 bytes instead of 2. So the handling of characters above U+FFFF will be non-portable.

• In all other cases, you can't just write those characters in your source file. The most portable way is encoding your string literals as UTF-8, using \\x escape codes for all non-ASCII characters. Like this: "x1\\xe2\\x86\\x92a\\xe2\\x8a\\x95" "b)" rather than "x1→(a⊕b)" .

  And yes, that's as unreadable and cumbersome as it gets. The root problem is MSVC doesn't really support using UTF-8. You can go through this question here for an overview: How to create a UTF-8 string literal in Visual C++ 2008 .

  But, also consider how often those strings will actually show up in your source code.

Problem #2: finding the character

(If you're using UTF-16, you can just find the L'→' character, since that character is representable as one whcar_t . For characters above U+FFFF you'll have to use the wide version of the workaround below.)

It's impossible to define a char representing the arrow character. You can however with a string: "\\xe2\\x86\\x92" . (that's a string with 3 chars for the arrow, and the \\0 terminator.

You can now search for this string in your expression:

s.find("\xe2\x86\x92");

The UTF-8 encoding scheme guarantees this always finds the correct character, but keep in mind this is an offset in bytes .

Answer 2

My comment is too large, so i am submitting it as an answer.

The problem is that everybody is concentrating on the issue of different encodings that Unicode may use (UTF-8, UTF-16, UCS2, etc). But your problems here will just begin.

There is also an issue of composite characters, which will really mess up any search that you are trying to make.

Let's say you are looking for a character 'é', you find it in Unicode as U+00E9 and do your search, but it is not guaranteed that this is the only way to represent this character. The document may also contain U+0065 U+0301 combination. Which is actually exactly the same character.

Yes, not just "character that looks the same", but it is exactly the same, so any software and even some programming libraries will freely convert from one to another without even telling you.

So if you wish to make a search, that is robust, you will need something that represents not just different encodings of Unicode, but Unicode characters themselves with equality between Composite and Ready-Made chars.