[ https://issues.jboss.org/browse/JBIDE-19393?page=com.atlassian.jira.plugi... ] Victor Rubezhny commented on JBIDE-19393: ----------------------------------------- [~burrsutter] Yes, I can reproduce it by copying the code from the page and pasting it into GEdit editor - these bytes could be saved into a file and all that circus appears when that file is opened by JSDT JS Editor. The bytes \[EF BB BF\] are translated by sun.nio.cs.UTF_8 decoder into a UTF-8 characher (with code '\uFEFF') when reading the file into the Text Buffer that is used by editors and parser scanners as well. It looks like UTF-8 decoder (when converting from bytes to a char) treats these bytes as a valid 3-bytes character, and the character generated does look like a well-formed UTF-8 character. This character is not displayed neither by JavaScript Editor, nor by Eclipse's Text Editor, nor by GEdit editor (i'm using it on my Fedora). It lools like Mozilla (in my example) has improperly translated these bytes into three Russian characters because there is no Code Page defined for the file. Character class gives me the name of the code point for that char as "ZERO WIDTH NO-BREAK SPACE" - so it look like a reason why the character is not displayed (and has zero-witdth). So, I'd suggest to skip such characters and not parse/validate them (they're not to be displayed and they haven't being displayed, their width is zero - no placeholder is needed an so on). If it's correct we shouldn't deal with this character (we should treat them as a whitespace). But I'm not sure that there are no other characters similar this one (the code point returned for the character equals the character value itself, so it's not a class (or a type, or a group) of such characters, but the code point for this certain character), so if I'll add the check for this certain character we could get the came issue with similar (but other) formatting characters. -- This message was sent by Atlassian JIRA (v6.3.11#6341)