Entrées/sorties

Les différentes méthodes dont le nom commence par read permettent de lire — et, ce faisant, de consommer — un ou plusieurs octets :

• int read() : lit et retourne le prochain octet sous la forme d'une valeur comprise entre 0 et 255 inclus, ou –1 si la fin du flot a été atteinte,
• int readNBytes(byte[] b, int o, int l) : lit au plus l octets du flot, les place dans le tableau b à partir de la position o et retourne le nombre d'octets lus ; ce nombre n'est inférieur à l que si la fin du flot a été atteinte durant la lecture,
• byte[] readNBytes(int l) : similaire à la méthode précédente, mais les octets lus sont placés dans un nouveau tableau de bonne taille, qui est retourné,
• byte[] readAllBytes() : lit la totalité des octets restants dans le flot et les place dans un tableau de bonne taille, qui est retourné.

D'autres variantes de la méthode read existent également, mais ont un comportement assez peu intuitif dans certains cas, et ne sont donc pas décrites ici.

Les méthodes skip et skipNBytes permettent d'ignorer des octets :

• long skip(long n) : ignore au plus n octets du flot et retourne le nombre d'octets ignorés.
• void skipNBytes(long n) : ignore exactement n octets du flot.

Les méthodes ci-dessus sont potentiellement bloquantes (blocking). Cela signifie que si la totalité des octets demandé à ces méthodes n'est pas encore disponible mais le sera dans le futur — p.ex. après avoir été lus du disque ou reçus du réseau — le programme est bloqué jusqu'à l'arrivée des octets. Cette caractéristique facilite la programmation mais peut nuire aux performances ou à l'interactivité de l'application. L'un des buts de java.nio est d'ailleurs de fournir des méthodes permettant l'accès non bloquant aux données.

Pour éviter de bloquer le programme, il peut être utile de connaître le nombre d'octets qu'il est possible d'obtenir du flot sans blocage. C'est le but de la méthode available :

• int available() : retourne une estimation du nombre d'octets qu'il est possible de lire ou d'ignorer sans bloquer.

Il est garanti qu'un appel aux méthodes de lecture demandant le nombre d'octets retourné par available ne bloquera pas.

Pour mémoire, le type byte de Java représente un octet signé dont la valeur est comprise entre -128 et +127. Cela implique une différence importante entre les deux principales variantes de la méthode read :

• celle qui retourne le prochain octet en tant qu'entier int le retourne sous forme d'une valeur comprise entre 0 et 255 inclus, -1 étant utilisé pour signaler la fin du flot,
• celle qui stocke les octets dans un tableau de type byte[] les stocke sous forme de valeurs comprises entre -128 et +127 inclus, -1 étant une valeur normale n'indiquant aucunement la fin du flot !

Par exemple, étant donné un flot s contenant les deux octets suivants (donnés ici en binaire) :

00000000 11111111

Le morceau de programme ci-dessous :

System.out.println(s.read() + "," + s.read());

affiche 0,255 tandis que celui ci-dessous

byte[] b = new byte[2];
s.read(b);
System.out.println(b[0] + "," + b[1]);

affiche 0,-1.

La méthode transferTo permet de transférer la totalité des octets restants dans un flot de sortie :

• long transferTo(OutputStream o) : lit tous les octets du flot et les écrit dans le flot de sortie o, puis retourne le nombre d'octets ainsi transféré.

Les méthodes de marquage, peu utilisées, permettent de marquer une position dans le flot et d'y retourner plus tard :

• boolean markSupported() : retourne vrai si et seulement si le flot gère le marquage,
• void mark(int l) : place la marque à l'endroit actuel et promet que si la méthode reset est appelée plus tard, elle le sera lorsqu'au plus l octets auront été lus depuis la position actuelle,
• void reset() : revient à la position marquée précédemment.

Souvent, à un flot est associé une resource du système d'exploitation sous-jacent. Par exemple, l'ouverture d'un fichier ou la création d'une connexion réseau provoquent l'allocation de mémoire au niveau du système, mémoire qui n'est libérée que lorsque le fichier ou la connexion sont fermés.

Pour cette raison, les flots ont tous une méthode close permettant de fermer le flot et de libérer les éventuelles resources du système qui lui sont associées :

• void close() : ferme le flot, libérant ainsi les éventuelles resources associées et rendant par là même le flot inutilisable.

Attention : après fermeture, un flot est inutilisable et l'appel de n'importe laquelle de ses méthodes — autre que close — provoque une exception.

La classe FileInputStream représente un flot d'entrée primaire dont les octets proviennent d'un fichier.

Par exemple, un flot fournissant les octets du fichier nommé file.bin peut s'obtenir ainsi :

InputStream s = new FileInputStream("file.bin");

La classe ByteArrayInputStream représente un flot d'entrée primaire dont les octets proviennent d'un tableau Java de type byte[].

Par exemple, un flot fournissant les octets 1, 2 puis 3 peut s'obtenir ainsi :

byte[] b = new byte[]{ 1, 2, 3 };
InputStream s = new ByteArrayInputStream(b);

Un autre constructeur existe pour ne fournir que les octets dont les index sont dans un intervalle donné.

La classe BufferedInputStream représente un flot filtrant — qui ne filtre rien du tout, en réalité — ajoutant une mémoire tampon au flot sous-jacent. Cette classe lit les octets du flot sous-jacent par blocs, les stocke dans un tableau, puis les fournit lorsqu'on les lui demande.

L'utilisation d'une telle mémoire tampon au-dessus d'un flot dont les données sont coûteuses à obtenir une à une — p.ex. car elles proviennent d'un disque lent — peut améliorer les performances. Elle est donc souvent utilisée sur un flot de type FileInputStream, ainsi :

InputStream s =
  new BufferedInputStream(new FileInputStream(…));

De plus, la classe BufferedInputStream gère le marquage, donc ses méthodes mark et reset peuvent donc être utilisées pour marquer une position lors de la lecture et y revenir ultérieurement. Bien entendu, sa méthode markSupported retourne vrai.

La classe GZIPInputStream — du paquetage java.util.zip — décompresse à la volée les données fournies par le flot sous-jacent au moyen de l'algorithme gzip.

En d'autres termes, son flot sous-jacent doit fournir des données compressées au format gzip, qu'elle fournit à son client — via la méthode read — sous forme décompressée.

Il est très fréquent d'empiler plusieurs flots filtrants sur un flot primaire. Par exemple, pour lire un fichier nommé in.gz compressé avec gzip, en utilisant une mémoire tampon, on peut écrire :

InputStream s =
  new GZIPInputStream(
    new BufferedInputStream(
      new FileInputStream("in.gz")));

Dans un tel empilement, la fermeture du flot au sommet — ici référencé par s — provoque la fermeture de la totalité des flots qui le composent.

L'extrait de programme ci-dessous compte le nombre d'octets nuls dans le fichier in.gz, compressé avec gzip :

InputStream s =
  new GZIPInputStream(
    new BufferedInputStream(
      new FileInputStream("in.gz")));
int b, c = 0;
while ((b = s.read()) != -1) {
  if (b == 0)
    c += 1;
}
s.close();
System.out.println(c);

Les trois variantes de la méthode write permettent d'écrire un ou plusieurs octets dans le flot :

• void write(int b) : écrit les 8 bits de poids faible de b dans le flot (les 24 bits de poids fort sont ignorés),
• void write(byte[] b, int o, int l) : écrit les l octets obtenus du tableau b à partir de la position o dans le flot,
• void write(byte[] b) équivaut à write(b, 0, b.length).

Les variantes de la méthode write ne garantissent pas que les données sont écrites immédiatement dans le flot. Pour s'en assurer, on peut utiliser la méthode flush :

• void flush() : force les données du flot à être écrites effectivement, p.ex. sur le disque ou sur la console.

Tout comme les flots d'entrée, les flots de sortie possèdent une méthode close permettant de fermer le flot :

• void close() : ferme le flot, libérant ainsi les éventuelles resources associées et rendant par là même le flot inutilisable.

La hiérarchie des sous-classes de OutputStream est très similaire à celle des sous-classes de InputStream.

Toutes les classes de flots d'entrée que nous avons décrites ont un équivalent dans le monde des flots de sortie. Par exemple, à la classe FileInputStream correspond la classe FileOutputStream, et ainsi de suite. Ces classes correspondant directement à d'autres déjà examinées ne le seront plus ici.

La classe PrintStream ajoute à la classe OutputStream des méthodes print, println et printf permettant d'écrire des représentation textuelles de données Java dans le flot. Les flots représentant la « sortie standard » (standard output) et « l'erreur standard » (standard error), stockés respectivement dans les attributs statiques out et err de la classe System sont de type PrintStream.

UTF–8, encodage d'Unicode à taille variable, est le plus fréquemment rencontré en pratique. Un caractère y est représenté par une séquence de 1 à 4 octets, selon la plage à laquelle il appartient :

• 1 octet : de 0₁₆ à 7F₁₆,
• 2 octets : de 80₁₆ à 7FF₁₆,
• 3 octets : de 800₁₆ à FFFF₁₆,
• 4 octets : de 10000₁₆ à 10FFFF₁₆.

Sachant que les 128 premiers caractères d'Unicode sont ceux de ASCII (dans le même ordre), une chaîne composée uniquement de caractères représentables en ASCII a le même encodage en ASCII qu'en UTF–8.

La chaîne « œuf à €1 » comporte 8 caractères dont les points de codes Unicode hexadécimaux (base 16) sont :

Le nombre d'octets nécessaire à l'encodage de chacun de ces points de code en UTF-8 varie de 1 à 3 :

Comme on le voit, les caractères qui existent aussi dans la norme ASCII — ici u, f, 1 et l'espace — sont encodés exactement comme en ASCII, sur un octet.

UTF–16 est un autre encodage à taille variable d'Unicode. Un caractère y est représenté par une séquence de 2 ou 4 octets, selon la plage à laquelle il appartient :

• 2 octets : de 0₁₆ à D7FF₁₆ et de E000₁₆ à FFFF₁₆
• 4 octets : de 10000₁₆ à 10FFFF₁₆

La première plage couvre la quasi-totalité des alphabets en usage actuellement, donc dans la plupart des cas un caractère Unicode est encodé par un unique mot de 16 bits — donc 2 octets — en UTF–16. Les émoticônes, qui appartiennent à la seconde plage, sont une exception notable.

Tous les caractères de la chaîne « œuf à €1 » sont dans la première plage UTF-16, donc représentables chacun par deux octets :

UTF–32 est un encodage à taille fixe d'Unicode. Il consiste à trivialement représenter chaque caractère au moyen de son point de code, sur 32 bits — donc 4 octets. La chaîne « œuf à €1 » s'encode donc en UTF–32 au moyen de 32 octets :

Les chaînes écrites dans des langues utilisant l'alphabet latin sont représentées de manière plus compacte avec l'encodage UTF–8 qu'avec UTF–16 ou UTF–32. Cela est visible avec la chaîne d'exemple « œuf à €1 » qui s'encode au moyen de :

• 12 octets en UTF–8,
• 16 octets en UTF–16 et
• 32 octets en UTF–32.

Cette économie et la compatibilité avec ASCII — qui permet à d'anciens outils comme grep sur Unix de fonctionner plus ou moins sur les fichiers encodés en UTF–8 — font d'UTF–8 l'encodage le plus populaire pour Unicode.

La classe Reader est l'équivalent de InputStream mais travaille sur des caractères Java plutôt que des octets :

abstract public class Reader {
  int read();
  int read(char[] c, int o, int l);
  int read(char[] c);

  long transferTo(Writer w);

  long skip(long n);
  boolean ready();

  boolean markSupported();
  void mark(l);
  void reset();

  void close();
}

Contrairement à InputStream, Reader ne possède pas de méthode available permettant de connaître une estimation du nombre de caractères pouvant être lus sans bloquer. Au lieu de cela, elle possède la méthode ready qui retourne vrai s'il est certain que le prochain appel à read sans argument ne bloquera pas. La raison de cette différence est que fournir une méthode available demanderait de décoder les octets disponibles en caractères, ce qui peut être coûteux.

La classe Writer est l'équivalent de OutputStream mais travaille sur des caractères Java et pas des octets :

abstract public class Writer {
  void write(int c);
  void write(char[] a);
  void write(char[] a, int o, int l);
  void write(String s);

  Writer append(char c);
  Writer append(CharSequence c);
  Writer append(CharSequence c, int s, int e);

  void flush();

  void close();
}

Le lien entre les lecteurs/écrivains et les flots d'octets est fait par deux classes :

• InputStreamReader qui, étant donnés un flot d'entrée d'octets et un encodage de caractères, fournit un lecteur, et
• OutputStreamWriter qui, étant donnés un flot de sortie d'octets et un encodage de caractères, fournit un écrivain.

La classe FileReader représente un lecteur dont les caractères proviennent d'un fichier. Son constructeur prend en argument le nom du fichier ainsi que l'encodage à utiliser pour transformer les octets du fichier en caractères.

La classe FileWriter représente un écrivain dont les caractères sont écrits dans un fichier. Son constructeur prend les mêmes arguments que celui de FileReader.

La classe CharArrayReader représente un lecteur dont les caractères proviennent d'un tableau de caractères Java de type char[] passé au constructeur.

La classe CharArrayWriter représente un écrivain écrivant ses caractères dans un tableau de caractères Java de type char[]. Celui-ci peut être obtenu au moyen de la méthode toCharArray.

Les classes StringReader et StringWriter sont similaires mais basées sur des chaînes de caractères Java de type String plutôt que sur des tableaux.

A l'image de Buffered…Stream, les classes BufferedReader et BufferedWriter ajoutent une mémoire tampon au lecteur (resp. écrivain) sous-jacent, améliorant ainsi potentiellement les performances.

De plus, BufferedReader ajoute une méthode à Reader :

• String readLine() : lit et retourne la prochaine ligne du lecteur sous-jacent, ou null si la fin a été atteinte,

et BufferedWriter ajoute une méthode à Writer :

• void newLine() : écrit une fin de ligne dans l'écrivain sous-jacent.

LineNumberReader est une sous-classe de BufferedReader qui garde trace du numéro de ligne actuel — en commençant à 0 — et permet de le consulter ou modifier au moyen des méthodes suivantes :

• int getLineNumber() : retourne le numéro de ligne actuel, et
• void setLineNumber(int l) : définit le numéro de ligne à la valeur donnée — sans que cela n'affecte le lecteur sous-jacent de quelque manière que ce soit.

L'extrait de programme ci-dessous lit un fichier nommé utf8.txt encodé en UTF–8 et l'écrit en UTF–16 dans utf16.txt :

try (Reader i = new FileReader("utf8.txt",
			       StandardCharsets.UTF_8);
     Writer o = new FileWriter("utf16.txt",
			       StandardCharsets.UTF_16)) {
  i.transferTo(o);
}