Skriving (til fil) af String's og double's i faste positioner

Jeg formoder at det er en tekst fil du skriver. Ellers er double altid 8 bytes.

Java 1.5 (5.0):
  brug printf

ældre Java:
  kald toString metoden og pad selv med det nødvendig blanke
eller
  kig på DecimalFormat

Hm.

DecimalFormat har vist et problem med leading spaces.

Men så kombinerer du bare !

import java.text.*;

public class DFormat {
    public static void main(String[] args) {
        DecimalFormat df = new DecimalFormat("#.00");
        for(int i = 0; i < 5; i++) {
            String s = df.format(Math.exp(i));
            s = "          ".substring(s.length()) + s;
            System.out.println(s);
        }
    }
}

giver:

      1.00
      2.72
      7.39
    20.09
    54.60

-> arne_v: Du skriver at double altid er 8 bytes. Formatet, som double gemmes i, afhænger vel af, om man skriver til en tekst- eller en binary-fil eller? Såfremt man gemmer i en binary-fil, hvordan gemmer man så en double, så den fylder mindst muligt og alligevel har samme længde uanset værdien? (når man gemmer tal, går jeg ud fra, at det er mest pladsbesparende at gemme som binary)

Det er kun ved binært at double altid er 8 bytes.

Hvis du vil skrive en binær fil er en DataOutputStream et godt valg.

En binær fil er hurtigst. Om den fylder mindst afhænger af antal cifre i tekst format.

PS: DataOutputSTream skriver big endian !

-> arne_v: Ja, hvis man skriver til DataOutputStream er det sådan, at den fysiske repræsentation er i 256-decimalsystem (00-FF i hex), hvor char fylder 2 bytes (svarende til et værdispænd på 256**2=65.536 eller [0;65.535]), int fylder 4 bytes (svarende til et værdispænd på 256**4=4.294.967.296 eller [-2.147.483.648;2.147.483.647]), double fylder 8 bytes svarende til et værdispænd på 256**8=1.84E19) osv., dvs. numeriske størrelser har fast længde. Strenge derimod har i sagens natur variabel længde.

Når man skriver til DataOutputStream, kan man bruger metoderne writeInt(), WriteDouble() osv., og længden bliver den rigtige. Hvis man yderligere ønsker at skrive tekst, kan man bruge metoden writeUTF().

Ved genindlæsning kan man så bruge DataInputStream og de tilsvarende read()-metoder.

Hvad der umiddelbart undrede mig var, hvordan Java ved genindlæsning holder styr på data, når der er tekst af variabel længde inkluderet (det er selvfølgelig oplagt, hvis der kun er tale om numeriske felter med fast længde, jf. ovenfor). Pointen her er vel, at Unicode-karakterer fysisk i output-filen repræsenteres ved karakterer, der alle afviger fra de karakterer, som de numeriske størrelser lagres med. Når der så læses Unicode-tekst med readUTF(), læses der indtil der ikke er flere Unicode-karakterer.

Jeg kan ikke forestille mig, at den samme funktionalitet ville være mulig, hvis man skrev tekst med writeBytes() eller writeChars().

Har du nogle kommentarer vedr. dette?

De 4 byte i en int kan antale ale værdier, så det kan ikke ære helt sådan.

writeUTF må enten skrive en længde først eller bruge et terminator tegn.

Det er længde !

Fra docs:

public final void writeUTF(String str)
                    throws IOException

    Writes a string to the underlying output stream using Java modified UTF-8 encoding in a machine-independent manner.

    First, two bytes are written to the output stream as if by the writeShort method giving the number of bytes to follow. This value is the number of bytes actually written out, not the length of the string. Following the length, each character of the string is output, in sequence, using the modified UTF-8 encoding for the character. If no exception is thrown, the counter written is incremented by the total number of bytes written to the output stream. This will be at least two plus the length of str, and at most two plus thrice the length of str.

-> arne_v: Det er vel rigtigt, at int kun antager værdier i intervallet [-2.147.483.648;2.147.483.647]? Prøver man med int i = 2147483648; får man fejlen "integer too large".

Ja, det kan jeg godt se mht. writeUTF. De to første bytes i output-filen er reserveret til styring.

Ja.

Men det interval gør også at de 4 bytes kan antage alle mulige værdier. Og at der
ikke kan kendes forskel påint og char's udfra værdierne.

OK ?

->arne_v: Jep :-)