# bufferedReader readline, encoding



## Azeruel (19. Apr 2010)

Hallo zusammen,

ich stehe gerade vor einer kleineren Problematik die ich im Moment so nicht nachvollziehen kann. 

Ich habe eine Logdatei, welche im UTF-16 zeichensatz gespeichert ist. Soweit kein Problem... sollte man meinen.

Anbei der Code: 

```
BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream(temp), "UTF-16"));
          int i=0;
          while(true)
          {
            line = reader.readLine();
            if(line!=null)
              System.out.println(++i+" "+line);
            else 
              Thread.sleep(500);
          }
          } catch(Exception e) { }
```

Der Output ist bis zum ersten Ende der Datei korrekt. Gedacht ist dieses Konstrukt aber zur Überwachung einer Logdatei. Ergo habe ich testweise mittels Ultraedit eine Zeile hinzugefügt (wärend das Programm weitergelaufen ist). Die Ausgabe folgte prommt... auf Chinesisch. In der Textdatei selbst wird die Zeile absolut korrekt gespeichert. 

Die Hex werte sehen absolut sauber aus. Nach restart des Programms (und damit das erste Einlesen bis zum Ende der Datei) erfolgt die Ausgabe ebenfalls wieder korrekt. 

Über Ideen und Anregungen würde ich mich freuen. 

Lg


----------



## SlaterB (19. Apr 2010)

nicht schön, aber vielleicht eine Notlösung:
kommst du weiter wenn du die Daten als Stream in ein byte[] einliest
und darauf immer einen neuen UFT-16-Reader erstellst (ByteArrayInputStream usw.)

muss nicht für jede Zeile sein, sondern nur 1x pro Thread.sleep(500);
die while-Schleife sollte dann vielleicht über eine eigene Klasse laufen, um das intern zu regeln


----------



## Azeruel (19. Apr 2010)

Sobald ich Zeit dafür finde, werde ich das mal genauer ausprobieren, nichts desto trotz kann das ganze ja nicht der Sinn der Sache sein.Ich verstehe ja derzeit nichtmal wirklich wo genau das Problem liegt. Am InputStreamReader selbst kann es ja eigentlich nicht liegen. Das Encoding ist ja eindeutig gesetzt. Der BufferedReader dürfte ja den Stream nicht ändern.

EDIT: 
Ich habe gerade das Encoding auf UTF-8 gestellt. Dabei scheint er das Problem nicht zu haben. Die Buchstaben werden mir korrekt angezeigt. Das ganze stellt aber dennoch keine Lösung dar, da nun natürlich der Textstream falsch interpretiert wird (00 74 => "leerzeichen"t). Nachträgliches manipulieren würde natürlich zum Ziel führen, aber das soll an dieser Stelle kein Diskussionsthema sein.


----------



## Wortraum (19. Apr 2010)

Eine Lösung kann ich Dir nicht bieten, aber ich kann das Verhalten in ähnlicher Weise bestätigen. Zwar wurde bei mir nichts weiter ausgegeben, nachdem ich eine Zeile zur Datei hinzufügte, aber die Datei war danach zerschossen oder von Chinesen gehakt. Das betraf nicht nur die neue Zeile, sondern die komplette Datei.

Auffällig ist, daß sie vorher 270 Byte lang war, und nachdem ich eine Zeile mit weiteren Zeichen hinzufügte, war sie nur noch 170 Byte lang.

Das ganze probierte ich unter Windows mit Gvim und diesem Quelltext (der ist weitesgehend von Dir raubkopiert):

```
public static void main(String[] args) throws Exception {
    File txtFile = new File("c:/Users/xyzzy/a.txt");
    String txtEncoding = "UTF-16";
    InputStream fis = new FileInputStream(txtFile);
    Reader isr = new InputStreamReader(fis, txtEncoding);
    BufferedReader reader = new BufferedReader(isr);

    String line;
    int lineNum = 0;
    while (true) {
        line = reader.readLine();
        if (line != null) {
            ++lineNum;
            System.out.println(lineNum + ":\t" + line);
        } else {
            Thread.sleep(500);
        }
    }
}
```

Statt einer Notlösung interessiert mich überhaupt erst einmal das Warum. Was passiert da?


----------



## Azeruel (19. Apr 2010)

Ich weiß nicht genau ob ich dich richtig verstanden habe?!? Aber ich kann nicht bestätige dass die Datei an sich verändert wird, das wäre ja auch schlimm. Der Fehler müsste an dieser Stelle bei dir beim Speichern der Datei im GVim sein. Dies kann ich jedoch ausschließen, da wie gesagt, nach dem Speichern der Datei und erneuten öffnen im Editor alles korrekt angezeigt wird.


----------



## Wortraum (19. Apr 2010)

Das hast Du schon richtig verstanden. Da ich sonst mit UTF-16 nichts mache – also in Textdateien –, kann es durchaus sein, daß hier Vim oder Vim-Einstellungen schuld sind. Nein, nein, nicht der Benutzer, sondern Vim!  Aber die chinesischen Zeichen erhalte ich dort auch. Wenn ich die „zerstörte“ Datei als UTF-8 lade, ist fast alles richtig. Einzig die ersten beiden Bytes verstehe ich spontan nicht; es ist keine gültige Folge für den BOM, weder in UTF-8, UTF-8Y noch UTF-16.

In meinem Fall mag das sogar noch Sinn ergeben, wenn Vim das ganze als UTF-8 rausschiebt, aber bei Dir … Eigentlich liebe ich ja solche Kodierungsprobleme (ja, krank), aber für mehr als eine oberflächliche Betrachtung fehlt mir gerade die Zeit.

EDIT: Also ich habe das jetzt einfach mit Jedit gemacht, der schreibt es auch nach der Änderung brav als UTF-16. Nun kommt die für Dich „schockierende“ Nachricht: es funktioniert alles so, wie es soll; in Java wird jede weitere Zeile korrekt angezeigt.

Eine kleine Fehlerquelle gibt es dennoch: Wenn man Zeichen an die letzte Zeile anhängt und speichert, wird der neue Teil vom BufferedReader als neue Zeile gewertet. Die Zählvariable für die Zeile wird dann erhöht und eine neue Zeile angezeigt, kurz: hier kommt dann etwas durcheinander. Das kann theoretisch jederzeit passieren, wenn nach 500ms der Thread zum Leben erwacht und sich voller Eifer in die Arbeit stürzt, während ein anderer Prozeß Zeichen an die Datei anhängt. Das ist aber unabhängig von Deinem jetzigen Problem, aber ich dachte, ich erwähne es mal.


----------

