2009-05-14 10 views
3

Ich habe ein HTML-Formular von JSF erzeugt, das ein Eingabeelement auf einen Bean-Setter abbildet und es sieht so aus, als würde JSF Unicode-Input auf dem Weg in Garbage. Insbesondere habe ich die folgende Ausnahme für Testzwecke im SetterUnicode-Problem mit JSF- und HTML-Formularen?

public void setTitle(String title){ 
    System.out.println("title set with: "+title+"\n"); 
    if (title.startsWith("xxx")) { 
     throw new RuntimeException("debug exception "+title); 
    } 
    this.title = title; 
} 

Dann habe ich den folgenden Text in das Formular Titeleingabeelement: "xxxx 海 陆". Dann, wenn ich das Formular absende, sehe ich den Log-Print

(auf einem Unicode-kompatiblen Mac-Terminal). Und ich erhalte eine Fehlermeldung auf die Antwort HTML-Seite:

Error setting property 'title' in bean of type 
uk.ac.lancs.e_science.sakaiproject.api.blogger.post.Post: 
java.lang.RuntimeException: debug exception xxxx ���?? 

Irgendwelche Hinweise auf das, was falsch ist? Bin ich nur voll davon und habe die falsche Diagnose? Ich denke, ich habe alle anderen Möglichkeiten eliminiert. Unicode scheint in anderen Komponenten der gleichen Anwendung gut zu funktionieren.

Antwort

3

Fragen würde ich fragen:

  • Wie wird die Form codiert, die Anfrage (application/x-www-form-urlencoded oder multipart/form-data)? Mehrteilige Daten werden mit einem MIME-Parser eines Drittanbieters entschlüsselt, so dass es dort zu Ärger kommen kann. Wenn die Daten URL-codiert sind, wird sie ordnungsgemäß maskiert?
  • Welcher Zeichensatz ist der Browser accepting?
  • Was encoding is the server detecting? Ist es ein Unicode-Zeichensatz?
  • Ist es nur die Protokollierung, die als lossy encoding (z. B. MacRoman) schreibt? Was verwendet der Server default charset?

Da das, was man auf einer Konsole zu sehen ist nicht unbedingt was in der Zeichenfolge ist, können Sie die Unicode code points mit diesem Code-Dump:

public static void printCodepoints(char[] s) { 
    for (int i = 0; i < s.length; i++) { 
     int codePoint = Character.isHighSurrogate(s[i]) ? Character 
      .toCodePoint(s[i], s[++i]) 
      : s[i]; 
     System.out.println(Integer.toHexString(codePoint)); 
    } 
    } 
+0

Es ist eine mehrteilige Form. Vielleicht werde ich versuchen, zur URL-Codierung zu wechseln. Danke. –

+0

HE! Dies scheint zu funktionieren! Wechseln Sie einfach zur Standard-Post-Codierung. Danke –

+1

Ich wäre nicht so schnell zu feiern. Ich habe mehrteilige/Formulardaten gesehen, die für _compare_ character Bugs verwendet werden und es ist erforderlich, wenn Sie das Hochladen von Formularen durchführen wollen. Dennoch haben Sie zumindest eine Vorstellung davon, wo das Problem liegt. – McDowell

0

Ein Browser kann keine Unicode über die Leitung senden; es muss den Unicode irgendwie kodieren. Von der Ausgabe der Ausnahme (zwei Kanji wurden fünf Zeichen), ich vermute, die Daten wurden als UTF-8 codiert und die Zeichenfolge title wurde nicht korrekt nach dem Empfang auf der Serverseite der Komponente decodiert.

Ich schlage vor, das accept-charset Attribut für das Formular festzulegen. Das sollte jedem sagen, dass er sich benehmen soll.

+0

Ihre Vermutung zu meiner Vermutung ist. Ich muss utf-8 benutzen (meine pädagogische Anwendung kann Chinesisch und Sanskrit im selben Eingabeelement enthalten). Ich bin mir nicht sicher, wie das Setzen von accept-charset auf der clientseitigen Form die serverseitige Komponente veranlassen wird, utf-8 korrekt zu dekodieren. Wie funktioniert das? Wie auch immer, was ist die Syntax genau? Ich werde es versuchen ... –

+0

Ein Formular Post/Get ist eigentlich eine HTML-Anfrage. Mit accept-charset teilen Sie dem Browser mit, welcher Zeichensatz der Server erwartet. Der Browser wird diese Informationen auch in ein Headerfeld der Anfrage einfügen, damit Ihr Framework es sehen kann. Auf diese Weise erhalten alle Beteiligten einen Hinweis, was zu tun ist. –