Serialisering ska man helst inte använda slentrianmässigt, speciellt inte för saker som sparas till disk. Java lämnar inga garantier för att den lagrade data kommer gå att läsa tillbaka i framtiden. Bättre är att formatera hela filen på något smart sätt som man sjäv bestämmer över. XML har varit väldigt populärt ett tag och skulle säkert fungera bra för dig då det enbart rör sig om skrivbara tecken[1]. En modernare variant är JSON, vilket är i stort sett likvärdigt med XML. Det borde inte vara svårt att hitta Java-bibliotek som klarar det du behöver, det här är första Google-träffer jag fick http://www.xom.nu/. Har inte kollat på det själv, men det skulle förvåna mig om det inte skulle klara av all underligheter du kan komma på att kasta på det.
Ett annat alternativ är att skapa ett eget binärt lagringsformat. Du kan då själv ha kontroll över vad som händer och kan acceptera att användare matar in precis vilken dynga som helst. Det är också väldigt lärorikt att tänka ut bra filformat och ger en del förståelse i hur dom fungerar. Jag ger ett exempel nedan som du kan utgå ifrån för att göra ditt eget format. Se till att det visas i en fixed-width font.
== HEADER ==
-------------------
| 4B Num entries | // Four-byte integer holding the number of stored entries. Simplifies looping.
-------------------
== ENTRY LIST ==
| --------------------
| | 8B File offset | // Eight-byte byte offset in the file where this entry begins.
| --------------------
| | 4B String length | // Four-byte integer giving the number of character in the string.
| --------------------
| ....
| The above repeated <Num entries> times.
|
|---------------------
== Payload ==
| -------------------
| | 8B Time stamp | // Time stamp representing the user recorded date, stored as seconds since the epoc in an eight-byte integer.
| |------------------
| | String content | // <String length>[entry index] bytes of string content.
| -------------------
| ....
| The above repeated <Num entries> times.
|--------------------
En exempelfil skulle kunna se ut som följer. Varje [] är en byte och | används för att separera fälten listade ovan.
Byte 0 Byte 4 Byte 12 Byte 16 Byte 24 Byte 28 Byte 36 Byte 41 Byte 49
v v v v v v v v v
[0][0][0][2] | [0][0][0][0][0][0][0][28] | [0][0][0][5] | [0][0][0][0][0][0][0][41] | [0][0][0][4] | [32][4][234][21][45][21][1][43] | [H][e][j][D][u] | [32][4][234][21][45][21][1][43] | [&]["][#][¤]
Num entries File offset entry 0 Length string 0 File offset entry 1 Length string 1 Time stamp for entry 0 Content entry 0 Time stamp entry 1 Content entry 1
Vissa tycker om att aligna varje element på något sätt, men för Java tror jag inte det behövs. Det är mest i C när man vill rikta strukt-pekare in i fil-buffern. Skit i det.
Om du tycker ovan är lite för inveklat kan du göra som Teknocide föreslår, med specialla marker-tecken som escapas när det behövs. Exemplet ovan, med andra datum, skulle då exempelvis kunna bli
2012-06-14#HejDu#2012-06-14#&"##¤
eller kanske
2012-06-14"HejDu"2012-06-14"&\"#¤"
Notera användadet av dubbla # i första exemplet för att signalera att det är tecknet '#' som avses och inte slutet på strängen, samt motsvarande \" i det andra.
Om du vill ta det hela lite längre kan du implementare båda, ett Reader/Writer interface som dina två Reader/Writers implementerar och till sist en Reader/WriterFactory som tar ett filnamn som argument, läser lite av filen och sedan spottar ur sig en Reader/Writer av rätt typ.
En sak att tänka på är att Java använder Unicode för sina strängar, så det är inte säkert att
aString.length()] är antalet bytes som behövs för att spara strängen på disk. Se exempelvis http://stackoverflow.com/questions/4385623/bytes-of-a-string-in-java
[1] Du skriver att "Användaren tillåts skriva in alla tecken som kan skrivas genom tangentbordet." Inkluderar det även alla otrevligheter man kan få via alt+<numpad>?
