On 11/8/05, Grant Smith <[EMAIL PROTECTED]> wrote: > In general this is true. However, there are legitimate reasons for using NCR > over Unicode. See > > http://www.w3.org/International/questions/qa-escapes.html > > for some of them. I'd like to see both options available.
As I see it, this refers to using NCRs over UTF-8/UTF-16, etc. encoded text. Not what I'm talking about. I'm talking about Java-unicode-escaped text. E.g. "\u82eb", such that the Java strings you pass to JSF are Unicode, This is, IMO, always preferable - when you're holding onto a Java java.lang.String object, it should be Unicode escaped. The issue of how you store those strings and escape them when they're stored externally to your Java code (resource bundle, database, etc.) is a separate question, and should be whatever is natural to that datastore. All I'm saying is that when you get it actually into Java,. NCRs are bogus, pure Unicode is the right way to go, and then you let JSF handle the escaping for you. At any rate, escape="false" assumes that you're writing the text out as a text node, which will never work for <h:inputText>, for example, since it's written as a "value" attribute. So, right there you've got a case where NCRs are dead in the water. And it's a bad move to encourage people to set escape="false" all over the place, 'cause then they're opening themselves up to cross-site scripting attacks. -- Adam Winer
