UTF-8-Kodierung ; Nur einige japanische Zeichen werden nicht umgewandelt bekommen

Ich bin immer der parameter-Wert als parameter aus der Jersey-Web-Service -, die in der Japaner-Zeichen.

Hier, 'japaneseString' ist die web-service-parameter, der die Zeichen in der japanischen Sprache.

   String name = new String(japaneseString.getBytes(), "UTF-8");

Allerdings bin ich in der Lage zu konvertieren ein paar sting-Literale erfolgreich, während einige von Ihnen sind Probleme zu schaffen.

Wurden erfolgreich konvertiert:

 1) アップル
 2) 赤
 3) 世丕且且世两上与丑万丣丕且丗丕
 4) 世世丗丈

Während diese din nicht:

 1) ひほわれよう
 2) 存在する

Als ich weiter untersuchte, fand ich, dass diese 2 strings werden immer umgewandelt in einige JUNK-Zeichen.

 1) Input: ひほわれよう        Output : �?��?��?れよ�?�
 2) Input: 存在する            Output: 存在�?�る

Jede Idee, warum es mit den japanischen Zeichen werden nicht richtig konvertiert?

Dank.

Warum die Codierung und Decodierung einer Zeichenfolge in der gleichen Zeile? Das macht keinen Sinn. Offensichtlich japaneseString ist bereits ein string, so können Sie einfach verwenden, in dem code anstelle von name. Als Antwort auf: String.getBytes() nutzt die Plattform die Standard-Kodierung für die Erstellung des byte-array. Und das ist vielleicht nicht UTF-8. Die Dekodierung mit UTF-8 dann wird die junk-chars.
Das Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Seine eine dumme Frage, aber ich muss Sie trotzdem stellen: sind Sie sicher, dass die schriftart verwendet, kann eigentlich machen alle diese Zeichen, richtig?
Ja, die anderen sind rendering absolut Recht.
Die 3. und 4. strings nicht Aussehen wie die japanischen. Ich bin nicht sicher, ob UTF für Kanji und Hiragana sind die gleichen.

InformationsquelleAutor Janak | 2014-06-03

  1. 4

    Versuchen mit JVM-parameter-Datei.Kodierung festlegen, mit Wert UTF-8 in der startup von Tomcat(JVM).
    E. x.: -Dfile.encoding=UTF-8

    InformationsquelleAutor Nitul

  2. 9

    Mischen Sie Konzepte hier.

    Einen String ist nur eine Folge von Zeichen (chars); eine String an sich hat keine Kodierung. Für was es Wert ist, zu ersetzen characters in der oben mit carrier pigeons. Gleiche Sache. Eine Brieftaube hat keine Kodierung. Weder ein char. (1)

    Was Sie hier tun, ist:

    new String(x.getBytes(), "UTF-8")

    ist ein "poor man' s encoding/decoding-Prozess". Sie haben wahrscheinlich bemerkt, dass es zwei Versionen von .getBytes(): eine, wo Sie passieren einen Zeichensatz, der als argument das andere, wo nicht.

    Wenn Sie nicht, und das ist das, was hier passiert, es heißt, Sie erhalten das Ergebnis der Kodierung mit Ihrem Standard - Zeichensatz; und dann Sie versuchen und re-decode diese byte-Sequenz UTF-8 verwenden.

    Nicht. Einfach nur den string, wie es kommt. Wenn Sie jedoch Schwierigkeiten haben, Lesen Sie den original-byte-stream in einen string, es bedeutet, dass Sie verwenden eine Reader mit dem falschen charset. Fix , dass Teil.

    Weitere Informationen, Lesen Sie dieser link.

    (1) die Tatsache, dass in der Tat, ein char ist ein UTF-16-code-unit ist irrelevant für diese Diskussion

    Bitte sehen Sie sich den JAVA-Doc-es ist nicht re-Kodierung die bytes wieder in UTF-8. docs.oracle.com/javase/6/docs/api/java/lang/..., java.nio.charset.Zeichensatz) erstellt einen neuen String mit der Entschlüsselung des angegebenen Byte-array mit dem angegebenen Zeichensatz.
    ja, es funktioniert. Finden Sie in der Dokumentation für .getBytes() und der Konstruktor, der hier aufgerufen wird.
    Lesen Sie die Antwort wieder; ein String hat keine Ahnung von der Decodierung oder Codierung überhaupt, du nur codieren char-Sequenzen zu byte-Sequenzen, und Dekodieren von byte-Sequenzen in char-Sequenzen. Das anfängliche problem, wenn überhaupt, ist, dass die OP ausfällt, um decode wird die byte-Reihenfolge richtig.
    UTF-8 ist eine Codierung! Sie nicht decodiert eine Zeichenkette in UTF-8. Ein string ist ein einfaches char array, und die chars haben keine inhärenten Codierung. Ein Zeichen ist einfach ein Wert zeigen in einer Zeichen-Tabelle. Eine Codierung wird verwendet für die Speicherung, die den Charakter (der Charakter) als ein oder mehrere bytes. Sonst nichts. Und die Entschlüsselung Prozess ist das Gegenteil: Nehmen Sie sich etwas bytes, und erstellen Sie Zeichen, abhängig von der verwendeten Kodierung.
    Auch wenn die String Klasse wahrscheinlich wird implementiert unter Verwendung einer Sequenz oder Reihe von chars, die definition der String Instanz ist noch abstrakter: "Die Klasse String repräsentiert Zeichenketten.' Die Klasse String kann genauso gut verwenden Sie eine UTF-8-kodierten byte-array oder ein int-array mit code Punkte als interner Speicher und noch erfüllen die API-Vertrag.

    InformationsquelleAutor fge

  3. 2

    Ich Stimme mit @fge.

    Klärung

    In java String/char/Reader/Writer Griff (Unicode -) text, und können kombinieren alle Skripts in der Welt.

    Sowie byte[]/InputStream/OutputStream sind binäre Daten, die ein Anzeichen für eine Codierung in eine Zeichenfolge konvertiert werden.

    In Ihrem Fall japaneseStingr sollte schon eine richtige Zeichenfolge, ersetzt werden oder indem die ursprüngliche byte[].

    Fallen in Java

    Codierung oft ist ein optionaler parameter, der verwendet anschließend standardmäßig den Plattform-Codierung. Sie fiel in die Falle zu:

    String s = "...";
byte[] b = s.getBytes(); //Platform encoding, non-portable.
byte[] b = s.getBytes("UTF-8"); //Explicit
byte[] b = s.getBytes(StandardCharsets.UTF_8); //Explicit,
                         // better (for UTF-8, ISO-8859-1)

    Im Allgemeinen vermeiden Sie das überladen von Methoden ohne encoding-parameter, wie Sie für aktuelle computer nur Daten: die nicht-portable. Für die Vollständigkeit: Klassen FileReader/FileWriter sollte vermieden werden, da Sie auch keine encoding-Parameter.

    Fehler

    japaneseString ist schon falsch. So haben Sie richtig gelesen.
    Es hätte Lesen erroneouslyas Windows-1252 (Windows Latin-1) und erlitt bei der Umkodierung auf UTF-8. Offenbar nur einige Fälle Durcheinander geraten.

    Vielleicht hatten Sie:

    String japanesString = new String(bytes);

    statt:

    String japanesString = new String(bytes, StandardCharsets.UTF_8);

    Ende:

    String name = japaneseString;

    Zeigen den code, der für das Lesen japaneseString für weitere Hilfe.

    InformationsquelleAutor Joop Eggen

Schreibe einen Kommentar