Das Lesen von Unicode von messageSource verursacht Probleme mit Java 5

Ich habe mir den Quellcode von DefaultPropertiesPersister angeschaut (intern von ReloadableResourceBundleMessageSource benutzt).

Wenn ein defaultEncoding angegeben wird, werden die Eigenschaften manuell Zeile für Zeile von Reader geladen, anstatt die konventionelle Methode Properties.load() zu verwenden.

Vor dem Hinzufügen des Schlüssel / Wert-Paares zum Properties -Objekt wird die unescape() -Methode für String s

Hier wird das \ -Zeichen entfernt.

Wenn Sie wie folgt eine Unterklasse von DefaultPropertiesPersister erstellen

Stellen Sie es in Ihrer Frühlingskonfiguration wie folgt ein:

Es wird funktionieren .. es kann weitere Jiggery-pokery erforderlich sein, um genau das zu bekommen, was Sie in Bezug auf andere Kodierungen usw. wollen:)

Sie müssen sicherstellen, dass Sie das Gebietsschema als Benutzer des Servers überprüfen. Genauer gesagt müssen Sie das Gebietsschema der Umgebung überprüfen, in der der Server gestartet wird. Zu Debugzwecken können Sie möglicherweise das Skripte starten, um die Ausgabe von "locale" in eine Datei zu schreiben.

%Vor%

Wenn vor jeder getParameter() -Aufruf aufgerufen wird, weist dies nur die Servlet-API an, welche Codierung verwendet werden soll, um die Parameter des POST (nicht GET!) request -Körpers zu analysieren .

Sie müssen die Codierung response noch so ändern, dass UTF-8 verwendet wird, damit die Servlet-API weiß, mit welcher Codierung sie die Zeichen als Byte an das andere Ende der HTTP-Verbindung ausgeben soll. Sie müssen auch den HTTP-Antwortheader den Webbrowser anweisen, welche Kodierung die übertragenen Bytes haben, damit der Webbrowser sie richtig in Zeichen entschlüsseln kann.

In JSPs können beide Aufgaben über diese einfache Zeile oben in der Datei ausgeführt werden. Sie müssen dies auf alle JSPs anwenden, auch die Include-Dateien / Fragmente.

Andernfalls wird die Standardcodierung der Serverplattform für das Senden und die Standardcodierung der Clientplattform für das Lesen verwendet (obwohl einige intelligente Webbrowser wie Firefox den Zeichensatz automatisch erkennen können, wenn er im HTTP-Antwortheader nicht angegeben ist).

Siehe auch:

• Unicode - Wie erhalten Sie die richtigen Zeichen?

Aktualisieren : Sind Sie sicher, dass die Unicode-Escapes nicht in den Eigenschaftendateien auf dem Linux-Rechner selbst zurückgeschleust werden? Das heißt, Sie sehen \u00E und mögen überall und daher nicht \u00E ? Das würde das Problem erklären.

Zitat aus javadoc für java.util.Properties,

  

Die Methoden load (InputStream) / store (OutputStream, String) arbeiten genauso wie das Paar load (Reader) / store (Writer, String), außer dass der Eingabe- / Ausgabestrom in der ISO 8859-1-Zeichenkodierung codiert ist . Zeichen, die in dieser Codierung nicht direkt dargestellt werden können, können mit Unicode-Escapes geschrieben werden; In einer Escape-Sequenz ist nur ein einziges 'u' erlaubt. Das native2ascii-Tool kann zum Konvertieren von Eigenschaftendateien in und aus anderen Zeichenkodierungen verwendet werden.

Vielleicht haben Sie eine Build-Phase, die Ihre UTF-8-kodierte Datei in ascii konvertiert. Versuchen Sie, die Codierung der Eigenschaftendateien in 8859-1 zu ändern. Klingt so, als ob Ihre Eigenschaftendatei die Unicode-Zeichen bereits korrekt entkoppelt.

Verwenden Sie auch getClassLoader().getResourceAsStream(...) , um selbst einen Stream in die Eigenschaftendatei zu laden und in eine Properties-Datei zu laden. Sehen Sie, ob die Werte die gewünschten Zeichenfolgen sind. Dies wird das Problem einer Codierung + Verpackung gegenüber einem Federproblem sein.

Aktualisierung basierend auf Kommentarthread:

Die Java 1.5 java.util.Properties funktioniert nicht haben eine load(Reader) API. Dies war eindeutig ein Bereich der Verbesserung im Zeitrahmen von Java 1.6.