Hi all,

as others have also noted, there seems to be bugs in unicode code of Quercus.

Haven't tested thoroughly with quercus servlet as it is not in our use
as we use Quercus as Spring View mechanism.

Quercus viewresolver and view basicly use quercus more or less in the
same way as quercus servlet does, so there shouldn't be much of a

If anyone is interested, I can share the code for the view and view resolver.

WIth configuration like this:

<bean class="com.onedidit.web.QuercusViewResolver" p:prefix="/WEB-INF/phpviews/"
                p:suffix=".html" p:viewClass="com.onedidit.web.QuercusView">
                <property name="contentType" value="text/html;charset=utf-8" />
                <property name="scriptEncoding" value="utf-8" />
                <property name="runtimeEncoding" value="utf-8" />
                <property name="initData">
                        <util:map map-class="java.util.HashMap">
                                <entry key="unicode.semantics" value="on" />
                                <entry key="unicode.runtime_encoding" 
value="utf-8" />
                                <entry key="unicode.output_encoding" 
value="utf-8" />

I get a situation where on a php page utf-8 content coming from java
works ok ( for example i18n messages from spring ), but content that
is in the php page OR is fetched with file_open from an url gets
manhandled. For example: Ä becomes Ä

Manhandled code however can be converted again into usable format with:

<? echo iconv("utf-8", "utf-8", $manhandledString); ?>

.. converting from utf-8 to utf-8!

Sounds like some kind of bug in how string values and encodings are
stored/used internally in quercus.

I tried different combinations of configuration, but did not manage to
get any situation or combination where content from java code, strings
in php template and content fetched with php code would all be
represented with right encoding at the same time.

I have checked and confirmed with for example working jsp views that:
  - properties files are encoded in UTF-8 and messages are served in utf-8
  - php files are in utf-8
  - content served via url to php file_open is in utf-8

For now we will just circumvent the bug and hope it will eventually be fixed.

Any thoughts?


resin-interest mailing list

Reply via email to