request encoding - hvem bestemmer

1)  Jeg troede at browseren kun brugte sin encoding hvis ikke den blev
    sat af serveren.

    (men jeg kan tage fejl)

2)  Jeg tror at det eneste du kan få fra browseren er Accept-Charset headeren
    som fortæller hvilke encoding browseren selv mner den kan klare.

Altså:
  request.getHeader("Accept-Charset")

Efter at have "læst" den sædvanlige "dokumentation" med den underforståede titel "Det må udviklerne selv prøve sig frem til" er jeg nået frem til følgende.

1) Hvis IExplorer 6.0 er sat til automatisk encoding vil den vælge at vise siden som sat i headerinfomationen "Content-type", eller hvis denne mangler, som det bedste gæt på en passende encoding. Hvis det drejer sig om en JSP-side, har "Content-type" altså effekt efter siden er genereret (response).

Ændres encoding til en fast værdi efter en side hentet ind i IExplorer 6.0,  vil browseren huske denne encoding næste gang den samme side vises.

2) Form-parametre sendes til serveren med den encoding siden vises med i browseren (request). Det ser ud til at JSP kompileren antager pr. default at request er encoded i et 1 byte tegnsæt f.eks. ISO-8859-1. Uanset om JSP-siden der behandler request'en har en response header med UTF-8 eller med ISO-ISO-8859-1, sendes f.eks. æøå som TEST=%E6%F8%E5 og bliver vist korrekt som æøå med <%=request.getParameterValues("TEST")%>. Sendes æøå derfor fra en side med UTF-8 encoding (TEST=%C3%A6%C3%B8%C3%A5) vil JSP-siden forsøge at oversætte dette som 1 bytes tegnsæt og vise <%=request.getParameterValues("TEST")%> som æøå

Problemet gælder selvfølgelig også forespørgsel til databaser. Her har man brug for request encoding for at oversætte til UTF-16 med f.eks.  wordUnicode = new String(wordRequest.getBytes(),requestCharset);

Så det ville derfor være ret interessant at kende request encoding i når JSP-servlet'en eksekveres.

Hvad returnerer request.getCharacterEncoding ?

Den returnerer null. Det undrer mig, for hvad er så formålet med denne metode. Måske skal jeg aktivere et eller andet i Tomcat.

Det var dog en giftig sag.

Jeg tror jeg har et løsning sforslag.

Hvis form siden indeholder:

<%@ page contentType="text/html; charset=UTF-8" %>
<meta http-equiv="content-type" content="text/html; charset=utf-8">

og den derfor sender i UTF-8, så kan du bruge følgende i submit siden:

request.setCharacterEncoding("UTF-8");
...
request.getParameter("feltnavn")

så kommer det korrekt ud.

Det giver en kobling mellem form side og submit side, men det må du leve med,
fordi submit ikke sender information og charset med requesten.

Og tilsvarende for ISO-8859-1. Selvom det virker default så kunne
default jo skifte. Og så var det rart også at håndtere den eksplicit.

Jeg har fundet følgende info på
http://livedocs.macromedia.com/jrun/4/Programmers_Guide/i10n6.htm

1) Getting request encoding type:

When a browser uses a character set that is not ISO-8859-1, it is supposed to send the encoding character set in the Content-Type header of the request. You use the request object's getCharacterEncoding method to get the character set from the Content-Type header. You can use that value to decode the form data and work with the response using the correct character set.

For example, if the client submits a form using EUC-JP and sets the request's Content-Type header to Shift-JIS, the processing servlet can determine how the request was encoded and properly decode it.

Det tyder jo på, at man skal kunne fange encoding'en på en request via header informationen. Længere nede på samme side mener jeg imidlertid der står det modsatte!

2) Using setCharacterEncoding
While there is no declarative solution to determining the client's character encoding, the servlet API includes the following convenience method that sets the request object's encoding so that the remaining request data can be processed correctly:

request.setCharacterEncoding

This method lets you assign an encoding type to the request, so that all future calls to the request object decode the request's data correctly. Using setCharacterEncoding lets you avoid converting the request data from the default encoding to another encoding.

You must set the request's encoding before any calls to getParameter or getReader.

The following example sets the encoding type servlet so that Japanese parameters from a Shift_JIS-encoded form can be read with standard getParameter methods:

request.setCharacterEncoding("Shift_JIS");

String username = request.getParameter("username");

Her fremgår det, at request.setCharacterEncoding benyttes når JSP-siden skal svare på en request, og ikke når request'en sendes. Det er, som du også skriver, en hjælp til at konvertere encoding, men man skal stadig 'hardkode' den forventede request encoding! I langt de fleste tilfælde vil det også være godt nok. En måde man med større sikkerhed kan gætte request encoding'en er måske, at medsende en kendt tekststreng. Man kan så forsøge at konvertere tekststrengen med forskellige charset indtil teksten kan genkendes.

Jeg er bange for at det hænger sammen som:
  - browserne *burde* sendet charset med i HTTP headerne
  - browserne sendet *faktisk* ikke charset med i HTTP headerne

Og hvis ikke charset sendes browser-server så kan Tomcat jo ikke gøre andet
end at gætte.