|
|
mal wieder UTF-8
 jann, 26.02.2009 22:33:48
Hallo zusammen,
ich versuche eine Web-Anwendung gerade auf UTF-8 umzustellen, aber es will nicht so recht klappen. Folgende Maßnahmen habe ich ergriffen
1. Die JSPs:
<%@page pageEncoding="UTF-8"%>
.
.
.
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
.
.
.
2. Die Datenbankverbindung (Pooled Connection)
ctx.addToEnvironment("useUnicode", "true");
ctx.addToEnvironment("characterEncoding", "UTF-8");
ctx.addToEnvironment("characterSetResults", "utf8"); // oder UTF-8 gleiche (nicht)-Wirkung
3. Datenbank:
CREATE TABLE `tabelle` (
.
.
.
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
4. Ich benutze NetBeans als IDE und habe dort für das Projekt UTF-8 als Encoding eingestellt.
Wenn ich nun Umlaute aus einem Browser-Eingabefeld einlese in der DB speichere, auslese und wieder anzeige bekomme ich für die Umlaute nur "Schrott" zurück.
Wo muss ich jetzt noch angeben, dass ich UTF-8 nutzen will damit das problemlos klappt?
Jann
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
 hansi, 27.02.2009 00:12:28
Hi jann,
Im absendendem Formular sollte accept-charset="utf-8" stehen. Zu dem sollte
die methode post (nicht zwingend aber besser) im Formular verwendet werden.
<form action="utf-8Test.jsp"
method="post"
accept-charset="utf-8" />
Hast du probiert von einer Seite auf die andere Chnisische Zeichen zu übergeben?
(ganz ohne DB nur zum test.)
Wenn das nicht klappt kann der java.net.URLDecoder und java.net.URLEncoder helfen ;-)
Hast Du in die db geschaut wie es dort abgelegt ist.
Mit HeidiSQL oder so.
hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
jann, 27.02.2009 12:31:45
Hallo hansi,
es ist zum Piepen! Ich habe accept-charset="utf-8" meinen form-Tags hinzugefügt, method="post" habe ich generell drin. Ändert aber nichts. Dann habe ich es mit java.net.URLDecoder und java.net.URLEncoder versucht - auch nichts.
Ich habe mir jetzt mal an verschiedenen Stellen die Eingaben in eine Logdatei schreiben lassen. Statt einem ä kommt ä an, wenn das dann durch den Encoder geht bleibt %C3%83%C2%A4 über und das geht in die DB. Beim decodieren wird daraus natürlich wieder ä.
Ich weiß echt nicht wo ich ansetzen soll. Am liebsten würde ich wieder auf ISO-8859-1 umstelen und alles mit einer eigenen Methode kodieren - aber das kann es ja eigentlich nicht sein!
jann
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
hansi, 27.02.2009 13:57:52
Hmm,
kann es sein das bereits encodiertes, nochmals encodiert bzw das Decodierte nochmals decodierst wird?
Das kann ja geprüft werden in dem ein Ä zwei mal encodiert wird. Wenn sowas ä
raus kommt ist das der Fall.
HTH hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
jann, 27.02.2009 14:14:38
Hi hansi,
in meiner ganzen Anwendung wird kein zweites mal En- bzw. Decodiert, ganz sicher. Wenn ich es
weglasse ist das Ergebnis das gleiche.
Jetzt habe ich mir gerade mal folgendes ausgeben lassen, direkt in doPost bzw. doGet:
doPost request.getCharacterEncoding() null
doPost response.getCharacterEncoding() ISO-8859-1
doGet request.getCharacterEncoding() null
doGet response.getCharacterEncoding() ISO-8859-1
Der von der JSP erstellte HTML-Text sieht im Browser so aus:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
.
.
.
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
.
.
.
<form class="formular" name="guestFormular" action="/feNEW/be/AdminGForm?
cmd=update" method="post" accept-charset="UTF-8">
.
.
.
<td>
Nachname:
</td>
<td>
<input class="notAdmin" type="text" size="50" maxlength="50"
name="nachname" value="">
</td>
wie kann bei diesem HTML mit den expliziten UTF-8 Angaben nach Abschicken ISO-8859-1 werden
bzw. null?
Jann
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
hansi, 27.02.2009 16:31:19
Formular.jsp
_____________________________________
Formular.jsp:
<%@ page language="java"
contentType="text/html;
charset=UTF-8"
pageEncoding="UTF-8"%>
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd" />
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Formular liebt Sonderzeichen</title>
</head>
<body>
<form action="encode2utf-8.jsf" method="post" accept-charset="utf-8" />
<textarea cols="80" rows="6"
name="subject" />
äüöAÖÜß Nach dem lezten Punkt kommt eine Zeile in Arabisch:
Wird Zeile nicht 'schön' dargetellt wird fehlt dem Browser der
Arabische Zeichensatzt oder er hat sich nicht auf UTF-8 Umgschaltet.
العربية
</textarea>
<input type="submit" value=" senden" />
</form>
</body>
</html>
_____________________________________
encode2utf-8.jsf :
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd" />
<%@page import="com.sun.xml.internal.fastinfoset.Decoder"%><html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>My UFT-8 Mysterium</title>
</head>
<body>
<%@ page import="java.net.URLEncoder" %>
<%
request.setCharacterEncoding("UTF-8");
response.setCharacterEncoding("UTF-8");
String encode="";
if((String)request.getParameter("subject")!=null){
encode=(String)request.getParameter("subject");
encode=URLEncoder.encode(encode, "UTF-8" );
}
%>
Die Variable encode ist in utf-8 und kommt in die DB und sollte aus der DB genau so zurückgegeben werden.
<br>
<form>
<textarea cols="120" rows="4"
name="subject" /><%=encode%></textarea>
</form>
<br>Weil es so schön ist das ganze Klartext:
<%
String klartext = java.net.URLDecoder.decode(encode, "UTF-8" );
%>
<form>
<textarea cols="120" rows="4"
name="subject" /><%=klartext%></textarea>
</form>
</body>
<br>
</html>
_____________________________________
> wie kann bei diesem HTML mit den expliziten UTF-8 Angaben nach Abschicken
> ISO-8859-1 werden
> bzw. null?
Keine Ahnung was schief läuft.
Oben ist das Beispiel für ein Formular.
Ich würde einfach das ganze UTF-8 Gedöns abschalten und schauen was passiert.
-> ctx.addToEnvironment("useUnicode", "true");
-> ctx.addToEnvironment("characterEncoding", "UTF-8");
-> ctx.addToEnvironment("characterSetResults", "utf8");
Das auch
DB: -> CHARSET=utf8 COLLATE=utf8_unicode_ci;
Der request ist in utf-8 wenn im formular das accept-charset="utf-8" steht.
Java komuniziert intern in utf-8,
der Datenbank ist egal was kommt sie speichert es (ausserdem ist es bereits utf-8 )und gibt es so zurück wie sie es bekommen hat.
Der knack punkt ist die JDBC Schnittstelle, der muss eventuell
gesagt werden was kommt. Ich würde es einfach mal ohne probieren und wenn es nicht fuktioniert dazu schalten.
Dann würde ich den weg der Daten, (wie du es schon machst) mit einem logfile
verfolgen. Die Konsole ist unter windows nicht geeignet weil sie nicht utf-8
versteht.
Wenn es im Browser nicht 'schön' ist würde ich zu erst der jdbc Schnittstelle das encoding bekannt geben, wenn das nicht reicht, sofort nach dem auslesen
den decoder anwerfen.
Und das Möglichst nah am result set, dann ist der Fehler des doppel decoding am geringsten.)
In meiner DB hatte ich die Einstellung ENGINE=InnoDB DEFAULT CHARSET=latin1;
Chiniesisch hat dem oben beschrieben Weg funktioniert.
hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
hansi, 27.02.2009 16:47:27
> Keine Ahnung was schief läuft.
Vieleicht doch, machst Du das?
response.setCharacterEncoding("UTF-8");
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
jann, 27.02.2009 18:09:18
Hallo hansi,
erst einmal vielen Dank für Deine Unterstützung. Ich habe jetzt eine Lösung gefunden (weiter unten).
Zuerst habe ich die ganzen händischen UTF-8-Setter wieder entfernt
jdbc-Verbindung:
// ctx.addToEnvironment...
Request und Response:
// response.setCharacterEncoding("UTF-8");
sowie die URLEncode und Decode-Geschichten. Das Ergebnis war immer das gleiche... -> Absolut kein Unterschied.
Prüfung des Browsers:
Zeichencodierung richtig erkannt: UTF-8
Es schien so, als ob die Zeichen schon verändert mit dem POST beim Servlet ankamen. Da bin jetzt fündig geworden und habe es mit einem Filter lösen können, den ich 1 zu 1 von hier genommen habe:
http://wiki.apache.org/tomcat/Tomcat/UTF-8
(da ist es die "Alternative solution")
Damit er richtig funktioniert muss er als erster Filter in der web.xml stehen, falls man, wie ich, mehrere Filter benutzt. Der Filter greift schon bevor irgendein Servlet der Anwendung den request zu sehen bekommt. Perfekt!
Jann
@hansi: ich programmiere mit NetBeans auf ubuntu-Linux und Mac
Hier mal die Filterklasse, falls der obige Link mal nicht mehr funktionieren sollte:
/* --------------------------------------------- */
package otherFilter;
import java.io.*;
import javax.servlet.*;
public class CharsetFilter implements Filter {
private String encoding;
public void init(FilterConfig config) throws ServletException {
encoding = config.getInitParameter("requestEncoding");
if (encoding == null) {
encoding = "UTF-8";
}
}
public void doFilter(ServletRequest request, ServletResponse response, FilterChain next)
throws IOException, ServletException {
// Respect the client-specified character encoding
// (see HTTP specification section 3.4.1)
if (null == request.getCharacterEncoding()) {
request.setCharacterEncoding(encoding);
}
next.doFilter(request, response);
}
public void destroy() {
}
}
/* --------------------------------------------- */
Und hier der web.xml-Teil (muss als erster Filter in der web.xml stehen):
<!--CharsetFilter start-->
<filter>
<filter-name>Charset Filter</filter-name>
<filter-class>otherFilter.CharsetFilter</filter-class>
<init-param>
<param-name>requestEncoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Charset Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<!--CharsetFilter end-->
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
hansi, 27.02.2009 19:34:45
Filter?! - gut zu wissen - man lernt nie aus.
> ... Am liebsten würde ich wieder auf ISO-8859-1 umstellen ...
hehe, nix da,
UTF-8 geknackt, Fisch geputzt :)
Schönes Wochende
hansi
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Re: mal wieder UTF-8
jann, 27.02.2009 19:55:24
Ja Filter!
hier ist noch ein guter Filter: http://www.jsp-develop.de/forum/view/47934/
(nicht für UTF-8 sondern zur Kompression von auszuliefernden Seiten)
Zum Antworten auf einen Beitrag müssen Sie registriert und angemeldet sein.
|
Legende:  Anonymer User registrierter User sehr aktiver User
|
|
Hinweis: Auf dieser Seite liegen Links zu anderen Seiten im Internet. Für alle diese Links gilt: Wir
betonen ausdrücklich, daß wir keinerlei Einfluß auf die Gestaltung und die Inhalte der gelinkten Seiten
haben. Deshalb distanzieren wir uns hiermit ausdrücklich von allen Inhalten aller gelinkten Seiten auf
dieser Homepage und machen uns ihre Inhalte nicht zueigen. Diese Erklärung gilt für alle auf unserer
Homepage angebrachten Links
Redaktion/Betreiber von JSP-Develop übernehmen keinerlei Gewährleistung und Verantwortung für die Richtig-
und/oder Vollständigkeit von den auf den Webseiten JSP-Develop veröffentlichten Source Codes.
Die Verantwortung der Verwendung/Anwendung sowie etwaige Modifikation der hier veröffentlichten Sourcen
obliegt einzig dem Benutzer der Webseite, welche die veröffentlichten Sourcen in einer Applikation/Anwendung
einsetzt. Durch das Kopieren und/oder Benutzen der Sourcen in einer Applikation/Anwendung
bzw. etwaigen Abschriften wird dieser Rechtshinweis anerkannt.
Java, JSP, JavaServer Pages, J2EE, EJB, JDBC, JNDI, JTA, Sun, Sun Microsystems are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries.
IBM, WebSphere are trademarks or registered trademarks of International Business Machines Corporation.
Other trademarks and registered trademarks are the property of their respective owners.
|
|
|
|
