4

Is it possible to force JSF to escape special-characters in the unicode-way ä rather than the named-entity-way ä?

Background: Some old mobile devices (e.g. a HTC-Desire with Android 2.3.4) refuse to display a page containing named-entities:

This page contains the following errors ... Entity 'auml' not defined.

The page has a HTML5-Doctype and according to the specification auml is a valid predefined character-reference. So I think this is a browser bug but that does not help me here.

What I tried is to replace special-characters with their unicode-representation. But if I place an ä or even an ä in the view JSF will render me an ä. If I place the entity-mapping in the doctype (I know that this should not be done in a HTML5-doctype) the behaviour gets really strange:

<!DOCTYPE html [
    <!ENTITY auml "&#228;">
    <!ENTITY mdash "&#8212;">
    ...
]>

This will result in a correct HTML5 doctype without the mapping. But a &mdash; will be replaced by &#8212; while an &auml; won't be replaced.

Has anybody an explanation for that or is there the possibility to configure JSF to allways render unicode-escaped entitites?

lefloh
  • 10,653
  • 3
  • 28
  • 50
  • 1
    What JSF impl/version? Can't reproduce with Mojarra 2.1.25 in its default trim. I however recall encoding inconsitenties like this in ancient versions. This can also happen if you've explicitly set the `` to a non-Unicode-compatible encoding, but that would be a too obvious cause. – BalusC Sep 03 '13 at 16:20
  • 1
    Android 2.3.3 renders `ä` fine for me... you're not serving it as an XML MIME type are you? Despite HTML5's sad attempts to fudge the issue, `auml` and the other HTML entities are not predefined in XML and should be rejected by XML parsers. – bobince Sep 03 '13 at 17:53
  • You're right @BalusC. Setting `````` would be a too obvious cause. But obviously not for me. Thanks for the hint and shame on me. So the question is answered although my problem is unresolved. – lefloh Sep 03 '13 at 20:54
  • Thanks @bobince for retesting this. The content-type is text/html with charset ISO-8859-15 so the document should not be treated as XML. Or am I missing something here? – lefloh Sep 03 '13 at 20:54
  • @lefloh: weird, does it repro for you just on a normal `text/html` page with `ä` on? I can't believe they'd've broken such basic behaviour in a point release... – bobince Sep 04 '13 at 08:20
  • @bobince this is really weird. Can not reproduce it with a simple text/html page but can reproduce it with a simple JSF-page with ` `. Seems like adding `contentType="text/html"` there can fix it but I don't understand why. This is the default and the headers sent don't change. Will retest it in the production-near test-environment but will have to wait for next deployment next week. – lefloh Sep 04 '13 at 15:15
  • 1
    Ah... `contentType` doesn't necessarily default to `text/html` so you should set it manually anyway. See [this question](http://stackoverflow.com/questions/9375669/using-fview-to-override-default-contenttype-cons). Disastrous piece of bad design in JSF if you ask me—going to XML mode will easily break half your JavaScript if you're not expecting it, aside from the entity issue. – bobince Sep 05 '13 at 09:17
  • OMG! This explains everything! I really did not know this… Thanks @bobince! You really helped me. – lefloh Sep 05 '13 at 16:12

1 Answers1

1

This will happen if you've set <f:view encoding> to a non-Unicode compatible encoding.

Fix it accordingly:

<f:view encoding="UTF-8">

Since JSF2 on Facelets, this is the default value already, by the way, so you can safely omit it if you're indeed using JSF2 on Facelets.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555