Created attachment 33212 [details]
UTF-8 Test Code Snapshot

Created attachment 33213 [details]
UTF-8 XML View in NetBeans

Created attachment 33214 [details]
UTF-8 XML View in Eclipse

Created attachment 33215 [details]
UTF-8 XML File with BOM created using Windows Notepad

Another strange thing is that there is an extra character visible in the editor
before <?xml - I guess it should not be there, as it is a part of the header.

That is exactly what I am talking about. The extra character at the beginning is
the BOM part. It is not being skipped during parsing, and therefore screws the
editor and the validation.

I played with this today and it's not so simple to fix this. What is your
default encoding in your system?

Where can I find the default encoding?

For example when you start the NetBeans you have got in the console line like this:

System Locale; Encoding = en_US (nb); UTF-8

The same is written in the messages.log file(${user.dir}/var/log/messages.log).
You can attach this file to this issue. 

Regards,
Petr

This is from my NetBeans console:
    System Locale; Encoding = en_US (nb); Cp1252

Another user is running into this BOM issue:

 
I am using the WS-A schema in a WSDL,

        <types>
            <xsd:schema targetNamespace="http://j2ee.netbeans.org/wsdl/dynamicPL">
                <xsd:import namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
                schemaLocation="http://schemas.xmlsoap.org/ws/2004/08/addressing/"/>
               
                <xsd:import namespace="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
                schemaLocation="http://docs.oasis-open.org/wsbpel/2.0/OS/process/executable/ws-bpel_executable.xsd"/>
                              
            </xsd:schema>
        </types>


 NB XSD parser is not able to parse the file. Whether NB downloads this WS-A schema file through populate catalog action
or accesses it remotely, it seems to be unable to parse the schema file. When I force it to open in the text mode within
NB, I see some additional character at the beginning, a dot. If i delete this "dot" in the file it works fine.

The problem is I am able to open the xsd in the browser, by opening http://schemas.xmlsoap.org/ws/2004/08/addressing/. I
also can open the file in notepad and textpad and don't see the additional character. Maybe those editors chose to
ignore the "dot"

To test if NB has an issue, I used another remote xsd,
http://docs.oasis-open.org/wsbpel/2.0/OS/process/executable/ws-bpel_executable.xsd. And that works fine.

I am using windows XP. Could the XSD model folks or the "catalog" feature folks look at this and confirm that there is
in fact no issue with NB?

thanks,
Kiran.

changed it to P2 because we need this feature to work with WS-A addressing. without this support, the users will not
know why their import doesn't work. For BPEL this is very important feature as part of the dynamic addressing.

            <xsd:import namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
            schemaLocation="http://schemas.xmlsoap.org/ws/2004/08/addressing/"/>

*** Issue 26943 has been marked as a duplicate of this issue. ***

I dont know if this applies to this issue, but since it was filed there have
been the new feq encoding handling related to encoding property of project
and about encoding handling for xml, jsp and html files

that is, project or file encoding can't be assumed to be encoding of locale user is in
or cannot be assumed to be utf-8 either, which is the default project encoding now
but user can change that.

ken.frank@sun.com

Windows does add optional BOM code and ideally it should be fixed by jdk. The jdk issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4508058 has been marked as "closed, will not be fixed" and the
work-around asks the applications to skip BOMs.

If at all it needs to be fixed by Netbeans, it should be fixed at a much higher level, perhaps in DataEditorSupport.

DataEditorSupport knows nothing about XML. It knows nothing about encoding. We can indeed search for general solution 
and find someone else than Samaresh to implement it, but as the problem manifests in 99% of cases with XML files, I am 
inclined to believe XML is the place that should fix it for 6.1.

jqian, kiran_bhumana, please try the new jar and let me know if it fixes this issue. Copy the jar to ide9/modules.

Created attachment 59153 [details]
xml support

Fix follows:
http://hg.netbeans.org/main?cmd=changeset;node=59e9a86b0f60.
http://hg.netbeans.org/main?cmd=changeset;node=f49438717a86.

Verified.

Product Version: NetBeans IDE Dev (Build 20080327180128)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Userdir: C:\Documents and Settings\jqian\.netbeans\ide_dev