CXF
  1. CXF
  2. CXF-2781

Charset encoding other than UTF-8 (as ISO-8859-1) not working

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.7
    • Fix Version/s: 2.2.8, 2.3
    • Component/s: JAX-RS
    • Labels:
      None
    • Environment:

      Windows XP SP3 - Eclipse 3.5 - Spring - CXFServlet - Tomcat 5.5.12

      Description

      Simple REST service like this :

      HelloService.java

      package demo.jaxrs.server;

      import javax.ws.rs.GET;
      import javax.ws.rs.Path;
      import javax.ws.rs.Produces;

      @Path("/helloservice/")
      public class HelloService {

      @GET
      @Path("/hello")
      @Produces("text/html;charset=ISO-8859-1")
      public String sayHello()

      { return "Hello, my name is Félix Agnès"; }

      }

      When called (in my environnement : http://localhost:58010/geoservices/ws/TEST/helloservice/hello) produce :

      HTTP/1.1 200 OK
      Server: Apache-Coyote/1.1
      Date: Thu, 22 Apr 2010 13:44:18 GMT
      Content-Type: text/html;charset=ISO-8859-1
      Content-Length: 31

      Hello, my name is Félix Agnès

      Latin characters like "éèà" are encoded in UTF-8 !!!

        Activity

        Hide
        Sergey Beryozkin added a comment -

        I'm assuming you do not register any custom provider ? In which case it is probably a default provider for writing Strings is used...Yeah, this could be fixed. Note that for JAXB/XML the custom charset will be taken into account

        cheers, Sergey

        Show
        Sergey Beryozkin added a comment - I'm assuming you do not register any custom provider ? In which case it is probably a default provider for writing Strings is used...Yeah, this could be fixed. Note that for JAXB/XML the custom charset will be taken into account cheers, Sergey
        Hide
        Daniel Kulp added a comment -

        Well, this would be OK if the charset on the response was set to UTF-8 instead of ISO-8859-1. I personally would go that rought. If a charset is set programatically somehow, then default to UTF-8 and set the charset. It's the safest way to make sure data isn't lost using default settings.

        Show
        Daniel Kulp added a comment - Well, this would be OK if the charset on the response was set to UTF-8 instead of ISO-8859-1. I personally would go that rought. If a charset is set programatically somehow, then default to UTF-8 and set the charset. It's the safest way to make sure data isn't lost using default settings.
        Hide
        Olivier Rousseil added a comment - - edited

        Ok thanks Sergey. With a StringProvider like this :

        package provider;

        import java.io.IOException;
        import java.io.OutputStream;
        import java.lang.annotation.Annotation;
        import java.lang.reflect.Type;

        import javax.ws.rs.core.MediaType;
        import javax.ws.rs.core.MultivaluedMap;
        import javax.ws.rs.ext.MessageBodyWriter;
        import javax.ws.rs.ext.Provider;

        @Provider
        public class StringProvider implements MessageBodyWriter<String> {

        public long getSize(String s, Class<?> type, Type genericType, Annotation[] annotations, MediaType mt)

        { return -1; }

        public boolean isWriteable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mt)

        { return String.class.isAssignableFrom(type); }

        public void writeTo(String l, Class<?> clazz, Type type, Annotation[] a,
        MediaType mt, MultivaluedMap<String, Object> headers, OutputStream os)
        throws IOException

        { os.write(l.getBytes("ISO-8859-1")); }

        }

        and

        <jaxrs:server id="helloService" address="/TEST">
        <jaxrs:serviceBeans>
        <bean class="demo.jaxrs.server.HelloService" />
        </jaxrs:serviceBeans>
        <jaxrs:providers>
        <ref bean="stringProvider" />
        </jaxrs:providers>
        </jaxrs:server>

        <bean id="stringProvider" class="provider.StringProvider"/>

        in "applicationContext.xml", it 's working fine.

        With RESTEasy, no needs of custom provider... That's why I was confused !

        Show
        Olivier Rousseil added a comment - - edited Ok thanks Sergey. With a StringProvider like this : package provider; import java.io.IOException; import java.io.OutputStream; import java.lang.annotation.Annotation; import java.lang.reflect.Type; import javax.ws.rs.core.MediaType; import javax.ws.rs.core.MultivaluedMap; import javax.ws.rs.ext.MessageBodyWriter; import javax.ws.rs.ext.Provider; @Provider public class StringProvider implements MessageBodyWriter<String> { public long getSize(String s, Class<?> type, Type genericType, Annotation[] annotations, MediaType mt) { return -1; } public boolean isWriteable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mt) { return String.class.isAssignableFrom(type); } public void writeTo(String l, Class<?> clazz, Type type, Annotation[] a, MediaType mt, MultivaluedMap<String, Object> headers, OutputStream os) throws IOException { os.write(l.getBytes("ISO-8859-1")); } } and <jaxrs:server id="helloService" address="/TEST"> <jaxrs:serviceBeans> <bean class="demo.jaxrs.server.HelloService" /> </jaxrs:serviceBeans> <jaxrs:providers> <ref bean="stringProvider" /> </jaxrs:providers> </jaxrs:server> <bean id="stringProvider" class="provider.StringProvider"/> in "applicationContext.xml", it 's working fine. With RESTEasy, no needs of custom provider... That's why I was confused !
        Hide
        Sergey Beryozkin added a comment -

        Yes, as I indicated (indirectly) the default CXF String provider does not take into account custom charsets, only JAXB/JSON providers do

        cheers, Sergey

        Show
        Sergey Beryozkin added a comment - Yes, as I indicated (indirectly) the default CXF String provider does not take into account custom charsets, only JAXB/JSON providers do cheers, Sergey

          People

          • Assignee:
            Unassigned
            Reporter:
            Olivier Rousseil
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development