java.nio.Datei.InvalidPathException: Fehlerhafte Eingabe oder die Eingabe enthält unmappable Zeichen bei der Verwendung von nationalen Sonderzeichen

Ich versuche zu schaffen, einige Verzeichnisse, die nationale Symbole wie "äöü" etc. Leider bin ich immer diese exception, wenn versucht wird:

java.nio.file.InvalidPathException: Malformed input or input contains unmappable characters: /home/pi/myFolder/löwen
        at sun.nio.fs.UnixPath.encode(UnixPath.java:147)
        at sun.nio.fs.UnixPath.<init>(UnixPath.java:71)
        at sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:281)
        at java.nio.file.Paths.get(Paths.java:84)
        at org.someone.something.file.PathManager.createPathIfNecessary(PathManager.java:161)
...
        at java.lang.Thread.run(Thread.java:744)

Mein code, in denen es Auftritt, sieht wie folgt aus:

public static void createPathIfNecessary(String directoryPath) throws IOException {
        Path path = Paths.get(directoryPath);
        //if directory exists?
        if (!Files.exists(path)) {
            Files.createDirectories(path);
        } else if (!Files.isDirectory(path)) {
            throw new IOException("The path " + path + " is not a directory as expected!");
        }
    }

Suchte ich nach möglichen Lösungen und die meisten empfehlen das Gebietsschema mit UTF-8, so dass ich dachte, ich würde dieses Problem behoben, wenn ich die locale unter Linux UTF-8, aber ich fand heraus, dass es bereits UTF-8 all der Zeit und trotz neu einstellen, ich bin immer noch mit dem gleichen problem.

 $ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Ich bin nicht mit diesem problem unter Windows 7, erstellt er die Verzeichnisse perfekt, so Frage ich mich, ob ich brauche, um zu verbessern, die den java-code, um diese situation zu verbessern, oder etwas ändern in meinem Linux.

Linux hab ich, läuft es auf ein Raspbian auf einem Raspberry Pi 2:

$ cat /etc/*-release

    PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
    NAME="Raspbian GNU/Linux"
    VERSION_ID="7"
    VERSION="7 (wheezy)"
    ID=raspbian
    ID_LIKE=debian
    ANSI_COLOR="1;31"
    HOME_URL="http://www.raspbian.org/"
    SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
    BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Ich bin läuft meine Anwendung auf einem Tomcat 7 Server (die Java-version ist 1.8 glaube ich), meine setenv.sh beginnt mit: export JAVA_OPTS="-Dfile.encoding=UTF-8 ...

Hat jemand eine Lösung für dieses problem? Ich muss in der Lage sein zu verwenden, diese nationalen Symbole in der Verzeichnis/Datei-Namen...

EDIT:

Nach dem hinzufügen der zusätzlichen option-Dsun.jnu.encoding=UTF-8 am Anfang meiner setenv.sh für Tomcat und der Neustart etwas geändert.

Derzeit das mein start setenv.sh sieht so aus

export JAVA_OPTS="-Dsun.jnu.encoding=UTF-8 -Dfile.encoding=UTF-8 

es scheint, wie diese Ausnahme ist Weg und der Ordner mit den nationalen Symbolen angelegt wird, jedoch scheint das problem nicht vollständig gelöst, immer wenn ich versuche zu erstellen/schreiben von Dateien in diesem Verzeichnis habe ich nun bekommen:

java.io.FileNotFoundException: /home/pi/myFolder/löwen/Lowen.tmp (No such file or directory)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:206)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:156)
        at org.someone.something.MyFileWriter.downloadFiles(MyFileWriter.java:364)
        ...
        at java.lang.Thread.run(Thread.java:744)

Den code, wo es geschieht, sieht wie folgt aus:

//output here
File myOutputFile = new File(filePath);
FileOutputStream out = (new FileOutputStream(myOutputFile));
out.write(bytes);
out.close();

Scheint es zu scheitern (new FileOutputStream(myOutputFile)); wenn er versucht zu initialisieren, der FileOutputStream mit Datei-Objekt, das den Pfad erstellt aus einem string, das war wieder der Pfad in der Ausnahme vor und ein weiteres mit dem Namen am Ende.

So, jetzt das Verzeichnis erstellt wurde, jedoch das schreiben oder erstellen alles, was im inneren es führt immer noch in der Ausnahme vor, obwohl die Datei im es nicht-Ereignis enthalten nationale Symbole.

Erzeugen von Pfaden und Dateien in Ihnen, wenn Sie keine nationalen Symbole funktioniert genauso perfekt wie vor der änderung setenv.sh so wie es aussieht ist das problem verbunden ist, um die nationalen Symbole, die in den Pfad noch...

  • Der Täter ist eindeutig der o-umlaut-Zeichen. Tut es das Verzeichnis schon gibt? Wenn nicht, machen Sie einen Fehler, erhalten wenn Sie mkdir /home/pi/myFolder/löwen?
  • Ja, es ist die ö Zeichen, das das problem verursacht. Nein, der Pfad ist noch nicht da, daher wird der code weiter versucht zu erstellen, falls es noch nicht da, aber es schlägt fehl, wenn es die noch nicht. Wenn ich mkdir-Befehl aus der bash über SSH funktioniert es tadellos, deshalb finde ich das so komisch. Kann es sein, in Bezug auf Java/Tomcat-setup? Aber Tomcat scheint etwas setup zu tun Datei-Kodierung mit UTF-8, also weiß ich nicht, welche anderen möglichen Punkte gibt es.
  • Ist der Pfad hardcoded irgendwo im Quellcode oder ist es die Benutzereingabe, oder in einer properties-Datei? Was auch immer die Quelle der name des Pfads, der in einem nationalen Zeichensatz und aus irgendeinem Grund nicht in UTF-8 konvertiert, zu dem Fehler führen.
  • Hat das Unix-Dateisystem tatsächlich unterstützt ein Dateiname wie das? Kann es sein, erstellt von einer shell?
  • Nein, der Weg besteht aus einigen Werten, die Lesen von xml, und ein Teil (die mit dem nationalen symbol ö), Lesen von E-Mail. Hmm, derzeit habe ich noch die zusätzliche option beim start von setenv.sh Dsun.jnu.encoding=UTF-8, während die anderen ein und es scheint nach dem Neustart nicht werfen diese Ausnahme nicht mehr, aber es wirft eine neue auf und es muss mit dem gleichen problem, ich habe meine Frage bearbeitet
  • Ja kann es, ich habe es versucht.

InformationsquelleAutor Arturas M | 2016-08-27
Schreibe einen Kommentar