> aus Gründen der Performanzerhaltung in meinem Fall nicht zielführend ist.
warum schätzt du das, irgendwas schon dazu getestet? geht es dir nur um abstrakte Punkte wie 'Erzeugen des Stream-Objekte
oder hast du praktische Hinweise wie 'jedes Lesen aus der Schnittstelle kostet sowieso erstmal 3 sec'?
was Java-intern zum Anfordern eines Stream/ Erzeugen eines Objektes an Arbeit anfällt besser selber nicht zu beurteilen versuchen falls nicht unumgänglich
-----
ein Vorschlag: den Stream aus der Schnittstelle cachen, bei kleinen Dateien unter 1 MB vielleicht komplett in ein byte[] einlesen,
darauf dann einen Stream der die ersten bytes liest (ByteArrayInputStream) und mit bekanntem Encoding einen neuen Stream auf das immer noch komplett vorliegende byte[], das wird nicht 'verbraucht',
oder das Encoding direkt aus den bytes feststellen,
inwiefern das Performance-Probleme macht (z.B. zusätzliche 1 MB Arbeitsspeicher), kann man belieblig entscheinden,
komplizierter aber performanter wäre wahrscheinlich doch ein ein eigener Stream, der nur die ersten x bytes cacht
(herausfinden wieviel zur Encoding-Bestimmung benötigt werden),
dieser ersten x bytes eben zur Encoding-Bestimmung einsetzen und danach normal weitergeben, die restlichen bytes direkt durchreichen bzw. aus einen dann mit Encoding initialisieren wirklichen InputStreamReader als Klassenattribut,
(ich sehe gerade Reader statt Stream, überall ruhig byte durch char ersetzen)
auf Methoden der Basisklasse InputStreamReader kannst du dich dann natürlich nicht verlassen, du musst alle wichtigen Methoden überschreiben und direkt aus dem Parameter in lesen,
manche Methoden muss man nicht überschreiben, z.B.
[code=Java]
public int read(char cbuf[]) throws IOException {
return read(cbuf, 0, cbuf.length);
}
[/code]
kann so bleiben, wenn
> public int read(char cbuf[], int off, int len)
überschrieben ist usw.
