At the moment, flex only generates 8-bit scanners which basically limits you to use UTF-8. So if you have a pattern:

肖晗   { printf ("xiaohann"); }

it will work as expected, as the sequence of bytes in the pattern and in the input will be the same. What’s more difficult is character classes. If you want to match either the character 肖 or 晗, you can’t write:

[肖晗]   { printf ("xiaohan/2n"); }

because this will match each of the six bytes 0xe8, 0x82, 0x96, 0xe6, 0x99 and 0x97, which in practice means that if you supply 肖晗 as the input, the pattern will match six times. So in this simple case, you have to rewrite the pattern to (肖|晗).

For ranges, Hans Aberg has written a tool in Haskell that transforms these into 8-bit patterns:

Unicode> urToRegU8 0 0xFFFF
[-x7F]|[xC2-xDF][x80-xBF]|(xE0[xA0-xBF]|[xE1-xEF][x80-xBF])[x80-xBF]
Unicode> urToRegU32 0x00010000 0x001FFFFF
[x01-x1F][-xFF][-xFF]
Unicode> urToRegU32L 0x00010000 0x001FFFFF
[x01-x1F][-xFF][-xFF]

This isn’t pretty, but it should work.

Flex does not support Unicode. However, Flex supports “8 bit clean” binary input. Therefore you can write lexical patterns which match UTF-8. You can use these patterns in specific lexical areas of the input language, for instance identifiers, comments or string literals.

This will work for well for typical programming languages, where you may be able to assert to the users of your implementation that the source language is written in ASCII/UTF-8 (and no other encoding is supported, period).

This approach won’t work if your scanner must process text that can be in any encoding. It also won’t work (very well) if you need to express lexical rules specifically for Unicode elements. I.e. you need Unicode characters and Unicode regexes in the scanner itself.

The idea is that you can recognize a pattern which includes UTF-8 bytes using a lex rule, (and then perhaps take the yytext, and convert it out of UTF-8 or at least validate it.)

For a working example, see the source code of the TXR language, in particular this file: http://www.kylheku.com/cgit/txr/tree/parser.l

Scroll down to this section:

ASC     [x00-x7f]
ASCN    [x00-tv-x7f]
U       [x80-xbf]
U2      [xc2-xdf]
U3      [xe0-xef]
U4      [xf0-xf4]

UANY    {ASC}|{U2}{U}|{U3}{U}{U}|{U4}{U}{U}{U}
UANYN   {ASCN}|{U2}{U}|{U3}{U}{U}|{U4}{U}{U}{U} 
UONLY   {U2}{U}|{U3}{U}{U}|{U4}{U}{U}{U}

As you can see, we can define patterns to match ASCII characters as well as UTF-8 start and continuation bytes. UTF-8 is a lexical notation, and this is a lexical analyzer generator, so … no problem!

Some explanations: The UANY means match any character, single-byte ASCII or multi-byte UTF-8. UANYN means like UANY but no not match the newline. This is useful for tokens that do not break across lines, like say a comment from # to the end of the line, containing international text. UONLY means match only a UTF-8 extended character, not an ASCII one. This is useful for writing a lex rule which needs to exclude certain specific ASCII characters (not just newline) but all extended characters are okay.

DISCLAIMER: Note that the scanner’s rules use a function called utf8_dup_from to convert the yytext to wide character strings containing Unicode codepoints. That function is robust; it detects problems like overlong sequences and invalid bytes and properly handles them. I.e. this program is not relying on these lex rules to do the validation and conversion, just to do the basic lexical recognition. These rules will recognize an overlong form (like an ASCII code encoded using several bytes) as valid syntax, but the conversion function will treat them properly. In any case, I don’t expect UTF-8 related security issues in the program source code, since you have to trust source code to be running it anyway (but data handled by the program may not be trusted!) If you’re writing a scanner for untrusted UTF-8 data, take care!

I am wondering if the newest version of flex supports unicode?

If so, how can use patterns to match Chinese characters?

UTF-8 hacks with Flex won’t allow you to write Unicode regular expressions in general, such as [肖晗] for example.

There are modern alternatives to Flex that support Unicode. You might consider my project RE/flex that extends Flex to support additional features such as Unicode. RE/flex is free open source (BSD-3 licensed) and works exactly like Flex. But it supports the full Unicode standard and accepts UTF-8, UTF-16, and UTF-32 input files. Like Flex, RE/flex works seamlessly with Bison.

Unicode regular expressions are specified in Flex-compatible lexer .l specifications:

%option flex unicode
%%
[肖晗]   { printf ("xiaohan/2n"); }
%%

This generates a lexer that scans UTF-8, UTF-16, and UTF-32 files. As per UTF standardization, for UTF-16/32 input a UTF BOM is expected in the input, while an UTF-8 BOM is optional. UTF BOM are handled internally by RE/flex.

%option unicode enables Unicode and %option flex specifies Flex compatibility in the lexer specification. Also a local modifier (?u:) can be used to restrict Unicode to a single pattern (so everything else is still ASCII/8-bit as in Flex):

%option flex
%%
(?u:[肖晗])   { printf ("xiaohan/2n"); }
(?u:p{Han})  { printf ("Han character %sn", yytext); }
.             { printf ("8-bit character %dn", yytext[0]); }
%%

Option flex enables full Flex compatibility to use yytext, yyleng, ECHO, and so on. Without the flex option, RE/flex expects C++ Lexer method calls: text() (or str() and wstr() for std::string and std::wstring), size() (or wsize() for wide char length), and echo(). RE/flex method calls are cleaner in C++, and also includes methods for wide char and string operations that are useful with Unicode.

Link to my RE/flex project: https://github.com/Genivia/RE-flex