Falsches Encoding bei Drag and Drop von Umlauten

  • Themenstarter Themenstarter Smoovie
  • Beginndatum Beginndatum
S

Smoovie

Gast
Hallo liebe Forum-Gemeinde!
Ich hab eine Postgre DB wo ich Pfade einlese. Die DB ist als UTF8 angelegt. Sowohl pgAdmin als auch das JTable wo ich die Pfade anzeige zeigt die Umlaute korrekt an.
Wenn ich aber mit Drag and Drop den Pfad nach winamp einlese erhalte ich statt eines Ü nur Ü und statt eines Ä nur cÄ usw.. Für Pfade ohne Sonderzeichen funktioniert das Droppen einwandfrei.
Soweit ich bisher festgestellt habe liegt das irgendwie am Encoding der Sonderzeichen, also hab ich mir aus der API den UTF8 converter genommen und versucht alle Pfade die gedroppt werden vorher ins passende Format zu bringen. Aber egal welche Kombination aus UTF8, UTF-8, CP1252,windows-1252, ISOxx-1/15 ich kombiniere, immer werden die Umlaute in Winamp falsch dargestellt. Lass ich parallel die konvertierten Pfade im IDE Terminal ausgeben, (also wenn ich nen Pfad ins Winamp schiebe lass ich den grad kopierten String ins Terminal schreiben, das sollte doch der gleiche sein der dann auch im Winamp landet?) werden die Namen aber korrekt angezeigt.

Ich nutze NetBeans IDE 7.1.2 mit UTF-8 encoding auf Windows XP

Hier noch bisschen Code der hoffentlich hilft^^. Bin noch recht frisch beim Programmieren, also bitte habt Nachsicht wenn der Code nicht ganz der "Norm" entspricht 😉


Java:
OutputStreamWriter out = new OutputStreamWriter(new ByteArrayOutputStream());
System.out.println(out.getEncoding()); 
liefert UTF8
System.out.println(System.getProperty("file.encoding"));
liefert UTF-8
System.out.println(Charset.defaultCharset());
liefert UTF-8

Die Drag and Drop Klassen:
Java:
package main.java;

import java.awt.datatransfer.Transferable;
import java.util.ArrayList;
import javax.swing.JComponent;
import javax.swing.JTable;
import javax.swing.TransferHandler;

public class DnDTransferHandler extends TransferHandler{   
        
    private JTable table;    
    
    @Override
      public int getSourceActions(JComponent comp) {
        return COPY;
    }    

    @Override
    public Transferable createTransferable(JComponent c)
    {
        this.table = (JTable) c;  
        int[] values = table.getSelectedRows(); 
        ArrayList files = new ArrayList();
        for(int i=0; i<table.getSelectedRowCount(); i++) //hier stehen die makierten Pfade drin
        {
            System.out.println((String)table.getValueAt(values[i], (table.getColumnCount())-1));
            files.add((String)table.getValueAt(values[i], (table.getColumnCount())-1));                
        }      
        DnDTransferableFile  tf = new DnDTransferableFile(files);
        return tf;
    }
}

Java:
package main.java;

import java.awt.datatransfer.DataFlavor;
import java.awt.datatransfer.Transferable;
import java.awt.datatransfer.UnsupportedFlavorException;
import java.io.UnsupportedEncodingException;
import java.util.List;

public class DnDTransferableFile implements Transferable{
   private List fileList;

   public DnDTransferableFile(List files)
   {
      fileList = files;
   }

    @Override
   public Object getTransferData(DataFlavor flavor)
      throws UnsupportedFlavorException
   {       
       if( flavor.equals(DataFlavor.javaFileListFlavor) ) 
       {              
           try {
               for(int i = 0; i < this.fileList.size();i++){
                   byte[] utf8Bytes = ((String)this.fileList.get(i)).getBytes("UTF8");                   
                   String Convert = new String(utf8Bytes, "UTF-8");
                   fileList.set(i, Convert);
                   System.out.println(fileList.get(i));
               }
           } 
           catch (UnsupportedEncodingException e) {
	//compiler empfiehlt hier nichts machen wegen throwable
           }
      }      
      return fileList;      
   }

    @Override
   public DataFlavor[] getTransferDataFlavors()
   {
      return new DataFlavor[] {DataFlavor.javaFileListFlavor} ;      
   }

    @Override
   public boolean isDataFlavorSupported(DataFlavor flavor)
   {
      return flavor.equals(DataFlavor.javaFileListFlavor) ;
       
   }
}

Ich bin für jede Hilfe dankbar =)
Gruß
Smoovie
 
(Ich benutze schon seit Ewigkeiten kein Windows oder Winamp mehr, das nur am Rande.) An welcher Stelle sagst du denn Winamp, dass das, was jetzt kommt, kein CP-1252 (oder ISo-8859-1, weiß ich gerade nicht), sondern UTF-8 ist? Ich denke nämlich, Winamp geht davon aus, dass die Zeichenkodierung die des Betriebssystems ist, wahrscheinlich also CP-1252. Und die passt bei Unicode-Zeichen >0x7F nicht mehr. ;-)

Was du wohl machen solltest: Benutze mal an der Stelle, an der du mit Winamp kommunizierst, als Encoding CP-1252 und nicht UTF-8. Vielleicht hilft das, falls du das nicht schon probiert hast. (Wenn ich das richtig lese, hast du das ja wohl schon; in dem Fall also einfach ignorieren, was ich geschrieben habe. Spannend klingt das Problem aber dennoch. 😀)

Ark

EDIT: Vielleicht statt String nur byte[] verwenden? Also nur einmal getBytes("CP-1252"), und das war's?

(Hoffentlich merkt man diesem Beitrag hier nicht an, dass sein Autor lange nicht in diesem Forum war … ^^; )
 
Zuletzt bearbeitet:
Hallo ihr beiden,
danke erstmal für die Hinweise, leider half keiner =(

@Ark
wenn ich nun ein byteArray übergebe also schreibe
Java:
byte[] utf8Bytes = ((String)this.fileList.get(i)).getBytes("UTF8");                   
fileList.set(i, utf8Bytes);
return fileList;
dann erhalte ich ne Exception dass er Byte nicht casten kann
Java:
java.lang.NullPointerException
	at java.io.File.<init>(File.java:222)
	at sun.awt.datatransfer.DataTransferer.castToFile(DataTransferer.java:1303)
	at sun.awt.datatransfer.DataTransferer.access$000(DataTransferer.java:122)
	at sun.awt.datatransfer.DataTransferer$3.run(DataTransferer.java:1159)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1155)
	at sun.awt.windows.WDataTransferer.translateTransferable(WDataTransferer.java:163)
	at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2145)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
java.lang.ClassCastException: [B cannot be cast to java.lang.String
	at main.java.DnDTransferableFile.getTransferData(DnDTransferableFile.java:40)
	at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:957)
	at sun.awt.windows.WDataTransferer.translateTransferable(WDataTransferer.java:163)
	at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2145)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

Das mit dem "wo ich kommuniziere" verstehe ich nicht ganz, das dachte ich macht die JVM quasi für mich sofern ich die benötigten Klassen/Methoden implementiere was ich dachte getan zu haben. Winamp/Terminal reagiert ja auch auf meinen Converterversuch, also die Zeichen ändern sich manchmal aber das richtige ist eben nie dabei =(. Also in den Converterzeilen hab ich denk ich alle o.g. Kombinationen ausprobiert sowohl die der .io als auch .nio weil ich nicht genau wusste was der unterschied ist.

@FFNB
Der Thread hat ich auf meiner Suche schon gefunden, aber
Java:
String Convert = URLDecoder.decode((String)this.fileList.get(i), "Cp1252");
fileList.set(i, Convert);
return fileList;
liefert leider auch keine korrekten Umlaute (mit keinem der obigen encodings).

Gruss Smoovie
 
Wenn ich es recht habe, sind in utf8 die Zeichen in 1 bis 4 Bytes codiert.
Ich denke, wenn du die ASCII-Codierung haben willst, dann bräuchtest nur jeweils das letzte Byte der Zeichen als char zu interpretieren, um das in ASCII-Codierung zu bekommen. Zeichen, die mehr als 2 Bytes haben, solltest du besser rausfiltern.
Poste doch exemplarisch mal den Inhalt eines Byte-Array.
 
Hi pappawinni,
was meinst du genau mit Inhalt des ByteArray?

also nach
Java:
byte[] utf8Bytes = ((String)this.fileList.get(i)).getBytes("UTF8");
liefert
Java:
public static void printBytes(byte[] array, String name) {
    for (int k = 0; k < array.length; k++) {
        System.out.println(name + "[" + k + "] = " + "0x" +
            UnicodeFormatter.byteToHex(array[k]));
    }
}
(entnommen aus dem API beispiel)
das:
Java:
nach getBytes[0] = 0x44
nach getBytes[1] = 0x3a
nach getBytes[2] = 0x5c
nach getBytes[3] = 0x4d
nach getBytes[4] = 0x75
nach getBytes[5] = 0x73
nach getBytes[6] = 0x69
nach getBytes[7] = 0x6b
nach getBytes[8] = 0x5c
nach getBytes[9] = 0x74
nach getBytes[10] = 0x65
nach getBytes[11] = 0x6d
nach getBytes[12] = 0x70
nach getBytes[13] = 0x5c
nach getBytes[14] = 0xc3
nach getBytes[15] = 0x9c
nach getBytes[16] = 0x55
nach getBytes[17] = 0x73
nach getBytes[18] = 0x68
nach getBytes[19] = 0x65
nach getBytes[20] = 0x72
nach getBytes[21] = 0x20
nach getBytes[22] = 0x2d
nach getBytes[23] = 0x20
nach getBytes[24] = 0x53
nach getBytes[25] = 0x63
nach getBytes[26] = 0xc3
nach getBytes[27] = 0x84
nach getBytes[28] = 0x65
nach getBytes[29] = 0x61
nach getBytes[30] = 0x6d
nach getBytes[31] = 0x2e
nach getBytes[32] = 0x6d
nach getBytes[33] = 0x70
nach getBytes[34] = 0x33
ne andere Variante die ich gefunden habe ist
Java:
for(byte c : utf8Bytes) {
                       System.out.format("%d ", c);}
                   System.out.println();
und das liefert
Java:
68 58 92 77 117 115 105 107 92 116 101 109 112 92 -61 -100 85 115 104 101 114 32 45 32 83 99 -61 -124 101 97 109 46 109 112 51
Interessant ist vllt, getestet hab ich das mit: D:\Musik\temp\ÜUsher - ScÄeam.mp3
(Dateiname ist extra falsch damit umlaute drin sind), und wenn man das abzählt ist das 8 letzte Zeichen Ä in der zweiten Ausgabe -124 was wohl nicht richtig ist, aber wieso?^^

Wenn du was anderes meintest mit dem Inhalt sag bescheid 😉

Gruß
Smoovie
 
Ahh, nee mit UTF-8 wird das wohl nix.
Dein Pfad hiess: "D:\Musik\temp\ÜUsher - ScÄeam.mp3"
Ist ja auch ein blöder Name, da hätt ich auch verweigert :lol:

Ich würd es etwa so versuchen:
Java:
String test = "ÜUsher - ScÄeam";   
byte[] isoBytes = test.getBytes("ISO8859_1");
String s = new String(isoBytes);

[EDIT]
Welche Zeichen kommen denn an?
Steht das schon irgendwo? Hab ich das überlesen?
[/EDIT]
 
Zuletzt bearbeitet von einem Moderator:
Also ich hab jetzt noch mal dein Zeug durchgelesen.
Wenn ich es recht habe, dann ist dein String UTF-8
Dann bekommst du den so nach ISO-8859-1

Java:
byte[] utf8Bytes = ((String)this.fileList.get(i)).getBytes("UTF8");
byte[] latin1 = new String(utf8Bytes, "UTF-8").getBytes("ISO-8859-1");
String s = new String(latin1);
fileList.set(i, s);

Das sollte jetzt aber funktionieren, oder sag was damit ankommt.
 
Zuletzt bearbeitet von einem Moderator:
Hi pappawinni,
leider klappt das auch nicht =(
Java:
try {
for(int i = 0; i < this.fileList.size();i++){                   
                   byte[] utf8Bytes = ((String)this.fileList.get(i)).getBytes("UTF8");
                   byte[] latin1 = (new String(utf8Bytes, "UTF-8")).getBytes("ISO-8859-1");               
                   
                   String s = new String(latin1);
                   fileList.set(i, s);
                   
                   for(byte c : latin1) {
                       System.out.format("%d ", c);
                   }
                   System.out.println();
}           
           catch (UnsupportedEncodingException e) {
            //   compiler empfiehlt hier nichts machen wegen throwable
           }
          catch(Exception e){
               e.printStackTrace();
           }
liefert wie gehabt
Java:
68 58 92 77 117 115 105 107 92 116 101 109 112 92 -36 85 115 104 101 114 32 45 32 83 99 -60 101 97 109 46 109 112 51

Inzwischen hab ich folgende Erklärung gefunden:
Da in Java auch der Typ byte signed ist, werden Zeichen >127 falsch interpretiert weil sie negativ werden. Ein Ä wird damit zerlegt in A und die zwei Punkte oben drauf, daraum stehen auch in dem UTF-8 array zwei negative Zahlen. Wenn man das jetz kovertiert wird daraus zwar nur noch EINE negative Zahl aber die ist genau um 256 falsch, also Ä ist 196 im Array ist sie aber -60 und -60 + 256 = 196.
Ich hab jetz ne weile rumgesucht und nach dem was ich gelesen habe kann mann diese Werte nicht in ein Byte bringen, sondern der Empfänger muss diese negativen Zahlen korrekt interpretieren.

hab dann recht hässliche Workarounds versucht in denen ich die negativen Zahlen von Hand +256 rechne was dann etwa so aussah:
Java:
try {
               
               for(int i = 0; i < this.fileList.size();i++){                   
                   byte[] utf8Bytes = ((String)this.fileList.get(i)).getBytes("UTF8");
                   byte[] latin1 = (new String(utf8Bytes, "UTF-8")).getBytes("ISO-8859-1");                   
                   char[] chars = new char[this.fileList.get(i).toString().length()];
                   
                   for(byte c : latin1) {
                       System.out.format("%d ", c);
                   }
                   System.out.println();
               
                   for(int j = 0; j < latin1.length; j++){
                       if((int)latin1[j] < 0){
                           System.out.println("latin1 " + j + " :" + (int)latin1[j]);
                           int s = latin1[j] & 0xff;
                           System.out.println("latin1 " + j + " :" +s);                           
                           chars[j] = (char)s;
                           System.out.println("CHARlatin1 " + j + " :" +chars[j]);
                       }     
                       else
                       {
                           System.out.println("latin1 " + j + " :" + (int)latin1[j]);
                           byte[] ba = new byte[]{latin1[j]};
                           String t = new String(ba);                           
                           chars[j] = t.charAt(0);
                       } 
                   }
                   String s = new String(chars);
                    fileList.set(i, s);
               }                   
               }           
           catch (UnsupportedEncodingException e) {
            //   compiler empfiehlt hier nichts machen wegen throwable
           }
          catch(Exception e){
               e.printStackTrace();
           }
und wie gewollt auch meine Umlaute erzeugte (-60 und -36 sind Ä und Ü geworden):
Java:
68 58 92 77 117 115 105 107 92 116 101 109 112 92 -36 85 115 104 101 114 32 45 32 83 99 -60 101 97 109 46 109 112 51 
latin1 0 :68
latin1 1 :58
latin1 2 :92
latin1 3 :77
latin1 4 :117
latin1 5 :115
latin1 6 :105
latin1 7 :107
latin1 8 :92
latin1 9 :116
latin1 10 :101
latin1 11 :109
latin1 12 :112
latin1 13 :92
latin1 14 :-36
latin1 14 :220
CHARlatin1 14 :Ü
latin1 15 :85
latin1 16 :115
latin1 17 :104
latin1 18 :101
latin1 19 :114
latin1 20 :32
latin1 21 :45
latin1 22 :32
latin1 23 :83
latin1 24 :99
latin1 25 :-60
latin1 25 :196
CHARlatin1 25 :Ä
latin1 26 :101
latin1 27 :97
latin1 28 :109
latin1 29 :46
latin1 30 :109
latin1 31 :112
latin1 32 :51
aber am Ende ist bei Winamp wieder nur Murks rausgekommen...
Dann hab ich das gefunden: (was in die Richtung von FFNBs Hinweis geht)
Java:
if( flavor.equals(DataFlavor.javaFileListFlavor) ) 
       {     
          Charset charset = Charset.forName("UTF-8");
          CharsetDecoder decoder = charset.newDecoder();
          CharsetEncoder encoder = charset.newEncoder();  
          
          for(int i=0; i<this.fileList.size(); i++) //hier stehen die makierten Pfade drin
          {
          try {
                try {
                    String s = URLDecoder.decode((String)this.fileList.get(i),"UTF8");
                    System.out.println(s);                    
                    // Convert a string to ISO-LATIN-1 bytes in a ByteBuffer
                    // The new ByteBuffer is ready to be read.
                    ByteBuffer bbuf = encoder.encode(CharBuffer.wrap(s));                                        
                    
                    // Convert ISO-LATIN-1 bytes in a ByteBuffer to a character ByteBuffer and then to a string.
                    // The new ByteBuffer is ready to be read.
                    CharBuffer cbuf = decoder.decode(bbuf);                    
                    String s2 = cbuf.toString();           
                    this.fileList.set(i, s2);
                                        
                    System.out.println(s);
                    System.out.println(s2);
                } catch (UnsupportedEncodingException ex) {
                    Logger.getLogger(DnDTransferHandler.class.getName()).log(Level.SEVERE, null, ex);
                }
          } catch (CharacterCodingException e) {}
      }
Aber neee, auch hier wieder: Terminal passt, Winamp nicht..
Was ich echt nicht raffe ist, wieso NetBeans wenn es den UTF8 String aus dem ResultSet der DB bekommt NICHT das Problem hat den zu interpretieren. Der muss ja auch intern irgendwie gespeichert werden, dann müsst ich doch das gleiche Format nutzen können?

Achja, im Winamp kommt übrigens das hier an (was auch immer er da aus den negativen oder doppelten Zeichen macht...):
D:\Musik\temp\ÜUsher - ScÄeam.mp3

Gruß
Smoovie
 
Nachtrag:
Kleiner Fehler, die Ausgabe D:\Musik\temp\ÜUsher - ScÄeam.mp3 kam bei einer meiner Lösungsversuche,
bei dir kommt: D:\Musik\temp\�Usher - Sc�eam.mp3
was aber irgendwie keinen so großen Unterschied macht fürcht ich ^^

Smoovie
 
Stimmt denn überhaupt der Pfad, der dann in Winamp landet? Ich meine, es bringt ja auch nix, wenn du zwar dafür sorgen kannst, dass Winamp hübsche Zeichen anzeigt, aber dafür dann die Datei nicht findet, weil ihr euch missversteht.

Ark
 
Jo, der Pfad wäre korrekt sofern es die Zeichen wären. Wie gesagt bei allen Namen die keine Umlaute oder Sonderzeichen enthalten, also bei Buchstaben mit Akzenten tritt der Fehler auch auf denk aber aus demselben Grund.., funktioniert es ja =(
Die Pfade die ich gepostet habe sind auch direkt aus der Winamp fileinfo entnommen also schon das wo Winamp sucht. Es gibt auch die Möglichkeit die Pfade quasi im winamp "on the fly" zu ändern und wenn ich dort die komischen Zeichen lösche und von Hand den umlaut eintrage spielt er die auch ab...aber das merkt der sich leider nicht wenn ich nen neuen Track reinziehe oder den gleichen nochmal ist wieder kaputt :/

Smoovie
 
Nachtrag:
Kleiner Fehler, die Ausgabe D:\Musik\temp\ÜUsher - ScÄeam.mp3 kam bei einer meiner Lösungsversuche,
bei dir kommt: D:\Musik\temp\�Usher - Sc�eam.mp3
was aber irgendwie keinen so großen Unterschied macht fürcht ich ^^

Smoovie

Das "D:\Musik\temp\ÜUsher - ScÄeam.mp3" leuchtet mir ja ein, weil das die 1 zu 1 Umsetzung der UTF-8 Bytes in Character ist.
UTF-8 benutzt für manche Zeichen 2 Bytes.
Für das Ä z.B. dezimal 195 und 132.
Wenn du mal z.B. im Notepad auf deiner Tastatur die Alt-Taste drückst und festhältst und dann 0195 tippst, dann die Alt-Taste loslässt, dann kommt "Ã" bei ALT-0132 kommt "„" heraus.
Merkwürdig, denn das Zeichen "Ã" hat ja offensichtlich den Code 195 und liegt oberhalb der 127.
Das Ä wäre Code 196, wie du selbst festgestellt hast.

Da fällt mir echt nicht mehr viel ein. Vielleicht noch reinen Unicode?
mal mit nur einem Buchstaben?

byte[] latin1 = {0,0,2,12};
String s = new String(latin1);

oder auch
byte[] latin1 = {0,196};
String s = new String(latin1);
 
Zuletzt bearbeitet von einem Moderator:
Sonderzeichen (Leerzeichen, Hochkomma etc) und Umlaute/sz in Dateinamen... sowas würde man von einer unkundigen Putzfrau erwarten, nicht einem "Informatiker" der programmieren kann. Ich habe so in manch einer Firma ein Praktikum gemacht und gearbeitet, kann mich aber nicht erinnern, dass irgendein "Systemintegrator" je gesagt hätte "ja Umlaute, gaaaaaaaaar kein Problem". An deiner Stelle würde ich da ansetzen und einfach deine Dateien umbenennen.

Wenns zuviel ist, ein Java Programmchen schreiben (ist eine Frage von ein paar Minuten). Wie du schon gesagt hast, dein Java Tool hat mit den Umlauten ja kein Problem.

Wie auch immer, Winamp kann mit Unicode nicht, in die Richtung brauchst es also nicht weiterversuchen (seltsamerweise kanns aber ID3 Tags in Unicod lesen). Dateipfade werden allerdings im System Default eingelesen, da würde ich aber nicht zwangsläufig von windows1252 ausgehen.

Btw, neben dem Encoding gibt es auch noch sowas wie "Zeichentyp". Ich hatte davon keine Ahnung, gab hier jede Menge Probleme mit der Datei eines Kunden, am Ende hat sich rausgestellt "Latin9 erweitert um das Euro Zeichen"... in Folge wurde in der Firma alels auf LATIN9 de_DE@euro umgestellt.

Man würde sich jede Menge Stress ersparen, wenn einfach alles in UTF8 laufen würden, tuts aber nicht. Scheitert evtl an den Chefs? KA hier heisst es "UTF8 ist müll, wozu brauche ich chinesische Zeichen"... wohl wahr, man benutzt stattdesen lieber LATIN1, 9, 15 und Buxtehude und konvertiert hin und her, wir leben ja auch in den 60ern wo Speicher eine sehr knappe, extrem teure Angelegenheit ist.

Kernaussage ist aber ersteinmal: du ersparst dir jede Menge Stress und Arbeit wenn du die Dateinamen in handelsübliche ASCII trimmst.
 
Bester mla.rue,

in gewisser Weise sprichst du mir aus der Seele.
Ich mag noch nicht mal Leerzeichen in Dateinamen, aber das ist ein anderes Thema.
Wie "ÜUsher - ScÄeam" zustande kommt, wird mir auch ewig ein Rätsel bleiben.
Mir grausst es auch vor Variablennamen mit äöüß oder so, selbst wenn das kein Problem sein sollte.

UTF-8 ist im Grunde eine Kodierung für Unicode-Zeichen, schön.
Leider wird das halt offensichtlich auch von Java nicht 100% supported.
Es gibt UTF-8 Zeichen, die bis 4 Byte benötigen und was ich so gelesen habe, besteht ne char in Java aus 2 Byte, scheint also eher so eine Krücke wie CESU-8.

Wie dem auch sei, ich fänd es dennoch intressant zu wissen, wie das mit ÄÖÜ funktioniert hätte.

/Winni
 
Hallo,
dass es leichter wäre auf die Sonderzeichen zu verzichten ist mir auch klar, aber ich neige doch glatt dazu einen Namen mit ä,ö,ü oder sonstwas auch mit selbigem Buchstaben zu schreiben...und wenn man nun einen Track von DJ Ötzi oder Beyoncé oder sonst wem hat, macht das eben Probleme,zumindest mir, denn ausm Windows nach Winamp gezogen läufts ja, weshalb ich auch nicht dachte dass das sone große Sache sei...
Was den komischen testnamen betrifft, da hab ich einfach irgendwelche Sonderzeichen reingehackt, natürlich in die Originalfile die sich auch abspielen lässt, um zu testen ob die Zeichen korrekt gelesen werden.
Ausserdem hab ich nie behauptet "Umlaute, gaaaaaaaaar kein Problem" aber ich hab sie nunmal bisher und wollt das eigentlich nicht alles ändern...
wie dem auch sei, werd mir wohl was anderes ausdenken müssen seis nun die umbenennung oder der Verzicht auf das DnD oder kA..
Falls ich doch noch rausfinde wie das klappt oder wer anders kann ers ja Kund tun..

Trotzdem Danke für die Hinweise und Mühen
Gruß Smoovie

P.S. Könnt das bitte jemand als erledigt makieren?
 
Hattest du eigentlich schon mal UTF-16 versucht ?

Java:
byte[] utf8Bytes = ((String)this.fileList.get(i)).getBytes("UTF-8");
byte[] utf16Bytes = (new String(utf8Bytes, "UTF-8")).getBytes("UTF-16BE");               
String s = new String(utf16Bytes);
 

Neue Themen


Zurück
Oben