WAS 5.1.1 og Microsoft Windows Code Page 1252

De tegn er specielle ved at de ikke er i ISO-8859-1 men kun i CP-1252.

Så du må skulle konfigurere WAS til at fortælle browseren at det er CP-1252 ikke
ISO-8859-1.

Du skal nok kigge lidt i WAS manualen.

Jeg kunne finde dette her på nettet:
  http://www-306.ibm.com/software/globalization/j2ee/encoding.jsp

Men jeg har ingen mulighed for at checke.

Jeg har fundet ud af man på serveren kan angive en parameter -Dclient.encoding.override=CP1252, men det har ikke hjulpet mig en meter.
Jeg startede i øvrigt med at angive den med bindestreg CP-1252. Men så døde min server ( og min adminconsol ) fordi det gav en nullpointer når serveren skulle starte op. Så måtte jeg ind og rette manuelt i server.xml - bare en lille info til andre der måtte have lyst til at kæmpe med på problemet.

Jeg har fundet ud af at jeg skal angive en parameter i mit response
Min servlet får denne linie i sin doPost metode
  response.setContentType("text/html; charset=CP1252");
Så kommer tegnene rigtigt frem i browseren. HURRA

her kommer den endelige løsning

Vi har på vores applikation haft problemer med at få fremvist visse tegn korrekt i browseren.

I forbindelse med konvertering fra was 3.5 til 5.1.1 og jdk 1.3 til 1.4, samt en ny
maskine, oplevede vi at – og ” blev vist som ?.
Det drejede sig om tegn skrevet i frontpage, som ikke benytter standart ISO-8859-1 tegnsæt, men anvender CP1252 tegnsættet.

Efter et par dages knoklen kom vi frem til en løsning der virker – om end den ikke virker helt optimal.

I Websphere administrations konsollen konfigurerede vi applications serveren for CP1252 encoding
Configuring application servers for CP1252 encoding
To use multiple language encoding support in the administrative console, you must configure an application server with UTF-8 encoding enabled.
Steps for this task
1.    Create an application server or use an existing application server.
2.    On the Application Server page, click on the name of the server you want enabled for CP1252.
3.    On the settings page for the selected application server, click Process Definition.
4.    On the Process Definition page, click Java Virtual Machine.
5.    On the Java Virtual Machine page, specify -Dclient.encoding.override= CP1252 for Generic JVM Arguments and click OK.
6.    Click Save on the console taskbar.
7.    Restart the application server.

Ændringen her vil kunne findes i server.xml under ../config/cells/.../nodes/.../servers/server1/server.xml



autoRequestEncoding and autoResponseEncoding
Two new WebSphere Application Server extensions are available in Version 5, autoRequestEncoding and autoResponseEncoding.
In WebSphere Application Server Version 5, the Web container no longer automatically sets request and response encodings, and response content types. Programmers are expected to set these values using available methods in the Servlet 2.3 Specification. If programmers choose not to use the character encoding methods, they can specify the autoRequestEncoding and autoResponseEncoding extensions, which enable the application server to set the encoding values and content type.
The values of the autoRequestEncoding and autoResponseEncoding extensions are either true or false. The default value for both extensions is false. If the value is false for both autoRequestEncoding and autoResponseEncoding, then the request and response character encoding is set to the Servlet 2.3 Specification default, which is ISO-8859-1. Also, If the value is set to false for a response, the Web container cannot set a response content type.

Disse parameter er defineret I  ibm-web-ext.xmi filen i WEB-INF  ( søg på filen, der skal muligvis rettes 2 steder )
  autoRequestEncoding="true"
  autoResponseEncoding="true"
I Servletten skal der også rettes 
I doPost ( eller/og  doGet ) metoden tilføjes linien

        response.setContentType("text/html; charset=CP1252");

og endelig for at det også skal virke når det drejer sig om popup vinduer tilføjes følgende I html headeren på de jsp sider der includer html siderne:

<meta http-equiv="content-type" content="text/html; charset=CP1252">

Vi har efterfølgende forsøgt med at fjerne nogle af de 4 ændringer, men uden held. Så muligvis skal det hele til, hvis der ikke findes en anden og bedere løsning.
Vi har ikke kunnet finde andet end ovenstående