Re: Gobo Regexp and Unicode support.
"Ted" <kkkkg999-/[email protected]> Fri, 13 Jun 2008 16:11:42 -0000
| Newsgroups | gmane.comp.lang.eiffel.gobo.general |
|---|---|
| Message-ID | <[email protected]> |
--- In [email protected], Colin Paul Adams <colin@...> wrote: > > >>>>> "Ted" == Ted <kkkkg999@...> writes: > > Ted> The patch basically does three things: 1. Makes that piece of > Ted> code treats a Unicode point code as a character, rather than > Ted> a code less than 255 (CHARACTER_8), which could be a byte of > Ted> UTF8, not representing a Unicode character. > > I don't understand you. > Do you mean you are translating both the regular expression and the > data to the UTF-8 byte representations? In UC_STRING, `item_code' correctly returns Unicode points which in the patch now are correctly appended to the string to replace. It wasn't correct because of `item' (CHARACTER_8) returned a single byte of UTF8 stream (known in UC_STRING object) rather than the whole Unicode point. > This is a trick Franck Arnaud suggested, but it doesn't always > work. For instance, . in the regular expression will now match one > byte, not one character. > > For example, try matching the regular expression "a.a" against > "aHa". It will match - correctly. Now substitute any single Chinese > ideogram for H. It will not match - but it should. I tried "a.a" to match either `aHa' or `a不a' (a Chinese char in between), they both perfectly matched. > Conversely, try the regular expression "a..+a" against the same two > data strings. In thge first case it will not match (correctly). In the > second case it will match (incorrectly). I also tried "a..+a" to match either `aHa' or `a不a', neither of them matched. > There are many more problems. For instance, case insensitive matching. Now I understand the case insensitive matching is a tough task. It is language specific, for example, 0069(i) <-> 0049(I), but in Turkish 0069 <-> 0130. With the patch, case insensitive matching only remains what it is. Ted