Wann Byte-Stream und wann Character-Stream?

[prashanna]

Hallo

Kann mir jemand kurz erklären, wann man Character Stream einsetzen soll bzw. wann macht es Sinn, bitte mit einem Beispiel ?

Ich habe bis jetzt immer nur Byte-Stream verwendet.

Gruss
prashanna

 

[nillehammer]

Byte-Streams für binäre Daten (exe-Dateien, flash-Videos, zip-Dateien etc.). Character-Streams (in Java-Sprech Reader/Writer) für Daten, die man als Text interpretieren kann (XML, HTML, ini-Dateien, Properties-Dateien, Java-Sourcecode). Word-Dokumente sind übrigens binär. Es steht zwar Text in ihnen, aber sie werden in einem binären Format gespeichert.

 

[Spacerat]

Sinn machen CharacterStreams, wenn man weis, dass eine Datei Unicodes enthält (Chars mit 1 bis 4 Byte langen Zeichen). Die kannst du binär mit einem Bytestream lesen und dich selber mit der Decodierung ans Werk machen oder aber die Vorzüge des CharacterStreams nutzen, der das für dich übernimmt.

 

[prashanna]

Danke vielmals für eure beide Antworten

Gruss
prashanna

 

[nillehammer]

Sinn machen CharacterStreams, wenn man weis, dass eine Datei Unicodes enthält (Chars mit 1 bis 4 Byte langen Zeichen).

Ich glaube nicht, dass Du es so meintest, aber das klingt danach, dass sie nur genau dann Sinn machen. Sie machen bei jeder Art von Text Sinn. Ich hätte auch keine Lust, aus einem byte-Array ASCII-Code auszulesen (obwohl das jetzt nicht so schwer wäre ) Du erlaubst mir darum bitte die kleine Korrektur: CharacterStreams machen besonders Sinn, wenn die Datei Unicode enthält, weil da eine Dekodierung binärer Daten besonders aufwendig ist.

 

[hüteüberhüte]

Oft hilft bei so was auch einfach ein Blick in die API:

InputStreamReader (Java Platform SE 6)

public class InputStreamReader
extends Reader

An InputStreamReader is a bridge from byte streams to character streams: It reads bytes and decodes them into characters using a specified charset. The charset that it uses may be specified by name or may be given explicitly, or the platform's default charset may be accepted.

Oder Tutorial:

Lesson: Basic I/O (The Java™ Tutorials > Essential Classes)

Character Streams handle I/O of character data, automatically handling translation to and from the local character set.

Grüßle

 

[Spacerat]

Ich glaube nicht, dass Du es so meintest, aber das klingt danach, dass sie nur genau dann Sinn machen.

Oh... äh... jetzt wo du es sagst . Naja Glücklicherweise ist die 1. Hälfte der ersten Unicode Seite ja mit ASCII und die 2. Hälfte mit ISO-8859-1 identisch, also wird's hoffentlich niemandem sonst auffallen.

 

[hüteüberhüte]

ISO-8859-1 ist Windows-Krams, der unterscheidet sich nicht wesentlich von ASCII.

Grüßle

 

[Spacerat]

ISO-8859-1 ist Windows-Krams, der unterscheidet sich nicht wesentlich von ASCII.

Grüßle

Woher hast du denn den Schwachsinn? ISO ist eine weltweite Norm und hat mit Windows allein nichts zu tun. Bei ASCII sind nur die ersten 128 Zeichen genormt und stets mit den ersten 128 Unicodes identisch. Der Rest (Enhanced ASCII) ist im Gegensatz zu Unicode relativ frei definierbar. Windows-1252... das ist Windows-Kram
Siehe hier: ISO 8859-1 ? Wikipedia

 

[nillehammer]

Woher hast du denn den Schwachsinn? ISO ist eine weltweite Norm und hat mit Windows allein nichts zu tun.

Habe es jetzt zwar nicht recherchiert, aber ich würde es nicht so schnell als Schwachsinn abtun. Es kommt durchaus vor, dass zunächst proprietäre Dinge irgendwann zu einem ISO-Standard erhoben werden und eine schöne ISO-Nummer bekommen. Könnte mir gut vorstellen, dass es auch einige MS-Encodings geschafft haben könnten...

[EDIT]Ok, der von Dir verlinkte Wikpedia-Artikel ist eindeutig :idea:[/EDIT]

 

[hütte]

Habt ihr auch "wie ISO/IEC 8859, Windows-125X und US-ASCII" gelesen? Im Wesentlichen bedeutet nicht komplett. Ich meine, Win wäre in diesem Fall Wegbereiter gewesen/sein.

Grüßle

 

[Spacerat]

Nicht wirklich... Wenn einer Wegbereiter für diese Norm war, dann eher IBM. Denn Computer gab es schon lange, bevor es Microsoft gab (kein Witz...). Die gesamte Normung basiert auf US-ASCII (nicht Enhanced ASCII) und ist um einiges älter als Microsoft. Schliesslich wurden Computer ja bereits weltweit verwendet und mussten irgendwie miteinander kommunizieren. Die ersten Zeichen, die heute als nicht belegt gelten, wurden damals als Steuercodes bezeichnet. Damit wurden z.B. Drucker mit 0D 0A zu einem Zeilenvorschub (Linefeed) und Wagenrücklauf (Carriage Return) animiert. Manche Drucker benötigten nur eines von beiden und wenn man das 2. davon trotzdem übermittelte gabs Kaudawelsch. Zu drucken gab es meistens Plaintext und 0D 0A verfolgt uns dort heute immer noch ungenormt obwohl Drucker längst andere Protokolle fahren.