Karsten: Funktion decoder() unter Linux

Hallo!

Ich habe ein Java-Servlet, in dem ich die Funktion URLDecoder.decode("string"); verwende um aus einer URL wieder einen "normalen" html-String zu basteln. Wenn ich die Funktion verwende, kommt allerdings die Meldung warning: decoder(java.lnag.String) in java.net.Decoder has been deprecated.

Hat jmd eine Ahnung, woran das liegt, hab das unter windows in nem normalen Java-Programm (also kein Servlet) getestet und da liefs ohne Probleme.

VIele Grüße
Karsten

  1. Hallo,

    Ich habe ein Java-Servlet, in dem ich die Funktion URLDecoder.decode("string"); verwende um aus einer URL wieder einen "normalen" html-String zu basteln. Wenn ich die Funktion verwende, kommt allerdings die Meldung warning: decoder(java.lnag.String) in java.net.Decoder has been deprecated.

    Hat jmd eine Ahnung, woran das liegt, hab das unter windows in nem normalen Java-Programm (also kein Servlet) getestet und da liefs ohne Probleme.

    Die Methode ist seit Java 1.4 deprecated. Du solltest sie nicht
    mehr verwenden, weil sie jederzeit entfernt werden könnte.

    Verwende stattdessen die Methode ecode(Strings, String enc).
    Siehe auch den JavaDoc zur veralteten Methode. Da steht üblicherweise
    auch drin welche Methode du stattdessen verwenden sollst.

    Auf deinem Windows-System ist wohl noch Java 1.3 installiert. Du
    solltest mal ein Update fahren. Der Server hat ein neueres Java.

    Gruß
    Slyh

    1. Danke euch beiden ;-))

      kam imr dann auch dass deprecated ja überschrieben heißt oder so. naja habs dann ma mit der decoder(string, string)-Methode versucht. dachte klar erst, ist ja nur ne WArnung, müsste ja auch so gehn, aber da es nicht richtig funktioniert hat, hab ichs natürlich darauf geschoben.

      hab die Funktion jetz folgendermaßen verwendet:
      strText = URLDecoder.decode(string_zum_decodiren, "ISO-8859-1);

      das gemeine ist, dass es trotzdem nicht funktioniert. In dem Servlet wird str_codiert dann in eine xml-Datei geschrieben mittels

      Text tItem = xmlDoc.createTextNode(strText);
      ..
      OutputFormat format = new OutputFOrmat(xmlDoc, "iso-8859-1", flase);
      StringWriter stringout = new StringWriter();
      XMLSerializer serial = new XMLSErializer(stringout, format);
      ...

      Er schreibt leider anstatt das ä ein ? in die Datei :-(

      Habt ihr ne Ahnung, woran das liegen könnte?
      Viele Grüße
      Karsten

      1. Hallo Karsten,

        kam imr dann auch dass deprecated ja überschrieben heißt

        Nein, "to deprecate" heißt ablehnen, missbilligen.

        Er schreibt leider anstatt das ä ein ? in die Datei :-(

        Probiere mal aus, ob das Problem beim decodieren oder beim Codieren auftrittst, indem Du Dir den String zwischen drin ausgeben lässt.
        Evtl. handelt es sich bei Deiner codierten Eingabe gar nicht um ISO-8859-1

        Grüße

        Daniel

        1. Huch! dachte das heißt so *peinlich*

          beim codieren gibt er mir für ä ein "%E4" aus, das müsste passen oder?

          Grüße
          Karsten

          1. Habe jetz festgestellt, dass ich nicht die Funktion escape() im JavaScript nehmen darf, sondern encodeURI() nehmen muss. der enkodierte String ä wird zu "%C3%A4" - aber wenn ich den ServletAufruf mache und den enkodierten String als Paramter mitgebe, kann er ihn nicht interpretieren und gibt Ä mit einem ~ über dem A und ein seltsames Zeichen aus.

            mein 2.Problem ist, wenn ich den String richtig ins Servlet bekommen könnte, dann macht er auch Fehler beim Schreiben der xml-Datei. Möchte in dem SErvlet eine XML-Datei schreiben, wenn ich jetz mal den enkodierten String (nehmen wir ma an, er würde richtig übergebn werden) dekodiere, kommt ja wieder ein ä raus und wenn ichs per out.println ausgebe, steht das ä auch drinnen, schreibe ich die xml mit

            // Datei xmlDoc speichern
            OutputFormat format = new OutputFormat(xmlDoc,"iso-8859-1",false);
            StringWriter stringout = new StringWriter();
            XMLSerializer serial = new XMLSerializer(stringout, format);
            try {
              serial.asDOMSerializer();
              serial.serialize(xmlDoc.getDocumentElement());
              pout = new PrintWriter(new OutputStreamWriter(new FileOutputStream("/home/localuser/note.xml")));
            }catch(IOException ioe) {
              System.out.println("IO-error");
            }
            pout.println(stringout.toString());
            pout.close();

            dann schreibt er ? anstelle des ä's in die Datei.

            apropos ich verwende Mozilla 1.7 und programmiere ja unter Linux mit Java 1.4.2.

            Hat da jmd einen Tipp???
            Viele Grüße
            Karsten

            1. Hallo Karsten,

              OutputFormat format = new OutputFormat(xmlDoc,"iso-8859-1",false);
              StringWriter stringout = new StringWriter();
              XMLSerializer serial = new XMLSerializer(stringout, format);

              Du gibst beim OutputFormat die Zeichenkodierung an, verwendest für die Ausgabe aber einen Writer. Ein Writer arbeitet aber nicht Byte-, sondern Zeichenbasiert. (In Java sind Zeichen immer utf-16-kodiert) Vermutlich hat Deine Zeichensatzangabe also exakt überhaupt keinen effekt.

              Später gibst Du den Text über einen Stream aus, ohne einen Zeichensatz anzugeben.
              Dabei wird wohl der Standardzeichensatz verwendet, wobei ich nicht genau weiß, wie Java diesen bestimmt.
              Du solltest also entweder direkt einen Stream zur Ausgabe verwenden oder bei der Ausgabe den Zeichensatz angeben.
              Ersteres ist auch schon deshalb sinnvoll, weil serialisieren in einen String nur unnötig Arbeitsspeicher benötigt.

              Grüße

              Daniel

              1. Hallo Daniel,

                es funktioniert ;-)) vielen lieben Dank!

                das 1.Problem hab ich gelöst, indem ich die Funktion getQueryString() benutzt habe, da kann man den ganzen Servletaufruf sich ausgeben lassen. und dann die Zeile geparst und nach die einzelnen Werte ausgelesen, zwar bisschen aufwendiger wie mit getParameter(), aber immerhin hats so funktioniert. Dann eben wieder decodiert.

                Du hattest recht, es lag an dem StringWriter. Habe jetz einen FIleOutputStream anstatt dessen verwendet. War nur verwirrt, weil es unter Windows auch mit dem StringWriter ging.

                Nochma vielen lieben Dank
                LG Karsten

                1. Hallo Karsten,

                  Du hattest recht, es lag an dem StringWriter. Habe jetz einen FIleOutputStream anstatt dessen verwendet. War nur verwirrt, weil es unter Windows auch mit dem StringWriter ging.

                  Die Standardzeichencodierung ist Platformabhängig. Unter neueren Windowsversionen ist das vermutlich UTF-8, unter Linux kann es praktisch jeder beliebige Zeichensatz sein.

                  Grüße

                  Daniel

  2. hallo,

    Ich habe ein Java-Servlet, in dem ich die Funktion URLDecoder.decode("string"); verwende um aus einer URL wieder einen "normalen" html-String zu basteln. Wenn ich die Funktion verwende, kommt allerdings die Meldung warning: decoder(java.lnag.String) in java.net.Decoder has been deprecated.

    JAVA wird, wie nahezu alles, beständig weiterentwickelt. Dabei kann es vorkommen, daß bestimmte Funktionen in einer jüngeren JAVA-Version eben "deprecated" werden, der Compiler gibt dir dann diese Warnung aus. Du solltest also bitte mal deine installierte Version überprüfen und die entsprechende Hilfe nachschlagen, beispielsweise http://java.sun.com/j2se/1.5.0/docs/api/java/net/URLDecoder.html

    Hat jmd eine Ahnung, woran das liegt, hab das unter windows in nem normalen Java-Programm (also kein Servlet) getestet und da liefs ohne Probleme.

    Es sollte keine Rolle spielen, ob Windows oder Linux, ob Servlet oder Applikation. Wichtig ist, daß das installierte SDK mit den angegebenen Funktionen etwas anfangen kann.

    "Deprecated" bedeutet im übrigen meistens nicht, daß es nicht funktioniert. Du erhältst ja auch eine Warnung, aber keine Abbruchmeldung.

    Grüße aus Berlin

    Christoph S.