Seperara information i en txt fil

Du kan ju tabb-separera filen. Eller tillåts användaren att skriva tabbar också? Annars kan du ju separera den med kombinationer av tecken. exempelvis 5 tabbar etc.

Är datumen alltid lika långa? T.ex. på formatet ååååmmdd så är ju problemet löst.

Ett bra alternativ till att spara datat i textfiler är att serialisera det objekt som håller alla datum och textsträngar och spara det till en fil.

http://www.javacoffeebreak.com/articles/serialization/index.h...

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>?

Varför är MrMadMans metod dålig? Vad menar du men att det inte finns några garantier för att den lagrade datan inte kan läsas tillbaka i framtiden? Borde det inte vara betydligt mer effektivt att skriva ned allt precis som det är till hårddisken istället för att ta omvägar som att formatera sin data för lagring och sedan återställa det till vad det var från början?[/QUOTE]
Jag tar mig friheten att svara här.

Effektivitet (som i prestanda) är med största sannolikhet oviktig i sammanhanget.

Vad han menar är att datan bara kan läsas från filen (deserialiseras) så länge klassen som håller datan förblir oförändrad. Om man kommer på att man behöver skriva om klassen så kommer man att få problem att läsa in sina filer igen. Det finns alltså en risk att den sparade datan ej går att återställa om man inte är försiktig.

Att använda serialisering i en sån här applikation är en "genväg". Det är väldigt enkelt, men man har ingen kontroll över vad som faktiskt händer. Jag tror inte ibbles menar att det är dåligt, men man bör vara medveten om riskerna.

ibbles metod med eget binärformat tar ett tag att implementera, och har du inte god programmeringsvana så är det en rejäl utmaning också, men å andra sidan lär du dig mycket om du bestämmer dig för det, och du kommer känna dig mäkta stolt när du väl är klar. Det är dock lite som att uppfinna hjulet igen med tanke på att JSON eller XML duger fint för uppgiften.

I slutändan skulle jag säga så här:
quick and dirty: serialisering
lärorik utmaning: eget binärformat
bra medelväg: JSON eller XML

Jag skulle rekommendera att man använder de redan definierade separatorerna som finns i ASCII standarden vilka är tecken som man aldrig använder. Genom detta får man bra uppdelning på ett standardiserat sätt. Det är på detta sätt som man separerar meddelanden när man tex kommunicerar via modem och olika seriella enheter.

Se tex följande sida för koderna http://www.december.com/html/spec/ascii.html

Ja det är den bästa hittills men jag har ju inte uppfunnit det själv utan bara nyttjar det som är mest effektivt. Glömde nämna att många databaser också använder sig av ASCII för att separera tabeller, rader, fält etc och fungerar det i en databas så fungerar det i en textfil. Det största problemet som jag ser idag är att så många direkt väljer att köra XML bara för det bliviit ett slags standard och det funkar också men XML bygger upp så stora filer i onödan och behöver man inte den komplexiteten som XML medför programmeringsmässigt sätt så är det mycket bättre att köra textfiler med ASCII tecken som separatorer.

Jag programmerar normalt system för kassor i butiker och då behöver jag kommunicera med kvittoskrivar, skannrar, vågar, kortläsare, bankmoduler etc och det som är gemensamt för alla är att de separerar meddelanden med ASCII. Bankmodulerna är intressanta för dessa bygger nästan alltid meddelanden i XML för att standardisera själva strukturen men de använder nästan alltid ASCII tecken för att separera de enskilda XML meddelandena så även där är ASCII viktigt.

Personligen skulle jag hålla mig till ett eget binärt format.

Förstod inte riktigt vad du menade med begränsad inmatning. När ett system kommunicerar med seriella enheter finns ingen begränsning, handlar ju inte om kassörers inmatningar utan om 'säkra' tecken. Om man är rädd att en användare ska trycka typ Alt + en numerisk kombination för att få fram tex värdet av en ASCII separator är det ju bara man gör replace på sina egna separatorer och ersätter med tom sträng innan man sparar ner data så finns ingen risk för korrupt data. Hade det däremot handlat om komplexa objekt så måste man ju serialisera vid transport över TCP protokoll. Men i detta fall, varför göra det svårare än vad det är?

Eftersom du svarar som du gör antar jag att du inte ens tittat på den webbsida jag bifogade, gör det nästa gång. Det du nyss beskrev var precis det som jag med ASCII standard föreslog för \0d1 trådar sedan.