However, with UTF-8 files umlauts, diacritics, cyrillic characters, etc. result in this CSE message:
At least one character (code point) between 128 and 159 (inclusive) was found on line 6. These code points are commonly found in Windows character sets like Windows-1252 but may not work for everyone, especially those not using Windows. Consider using "& #376;" instead of this character.
Opening the very same file in e.g. CSE Editor or SciTE it opens as UTF-8 (as saved in PhpED) and validates fine.
Opening it intentionally as ANSI in SciTE the expanded double byte characters easily demonstrate why in PhpED CSE issues seemingly silly suggestions as to replace certain characters by the & euro; entity: obviously PhpED passes the file to CSE as ANSI, not UTF-8.
AFAICT from setup PhpED uses csevalidatorV110.dll and passes the full filename. It also uses the regular CSE configuration (confirmed by config changes done in CSE and reflected by messages shown in PhpED).
Maybe PhpED is backwards and uses a dated interface to CSE? (Probably CSE 6.5 was not supporting UTF-8 at all?)
A workaround would be to turn off the charcters 128-159 check in CSE, but I rather would not do that as we also have ISO-8859 encoded projects.
Posting the problem on the NuSphere forum I got this reply from a site admin:
If your "UTF-8" file contains characters in that range - it is not a UTF-8 file because this encoding does not allow characters in this range.
If CSE while running under PhpED does complaint about them - it is correct
If CSE while running out of PhpED does not complaint about them - it is either incorrect or corresponding setting or check is OFF.
... which definitely suggests some further implications.
This is the typical pillar-to-post situation of course, but maybe you have some suggestions for the pillar to fix this ...