Vytvoření a čtení datového souboru – .NET – Fórum – Programujte.com

Zdravím,

napadlo mě čirou náhodou, že bych mohl udělat datovej soubor (třeba pro víc obrázků do 1 souboru), ale vůbec mě nenapadá jak by mohl vypadat kód. Teda jako mám rozvržený jak by měl vypadat alg na zabalení, ale jak to napsat to už nevím.

 Nějak takhle bych si představoval algoritmus toho datového souboru, ale nevím jak to prostě napsat.

uint countFiles;
for (int i = 0; i < countFiles; i++)
{
	ushort ID; // ID by se zvětšovalo podle počtu údajů
	ushort NameFile_Length;
	string Name = (nějaká fce na přečtení stringu o délce NameFile_Length);
	ushort FileLength;
	//tady jsi nejsem jist ale aby to přečetlo počet udaju podle FileLength a třeba výsledek zobrazil v PictureBoxu
}

Děkuji za pomoc.

Trvalo mi to asi 23,5 sekundy

{
	string[] fn = Directory.GetFiles("...\\Pictures", "*.jpg");
	FileStream sw = new FileStream("obrazky.data", FileMode.Create);
	foreach (string f in fn)
	{
		 using (FileStream sr = new FileStream(f, FileMode.Open))
		 {
			  byte[] b = new byte[sr.Length];
			  sr.Read(b, 0, (int)sr.Length); // 1
			  sr.Close();
			  byte[] bb = Encoding.ASCII.GetBytes(f); // 2
			  sw.Write(bb, 0, bb.Length); // ulozime info 2
			  sw.Write(b, 0, b.Length);  // ulozime info 1
		 }
	}
	sw.Close();
}

info 

1 nacteme cely obsah soboru obrazku

2 vytvorime oddelovaci hlavicku do vystupniho souboru

a v patricnem poradi ulozime

#2 VladislavK
Tos mi odpověděl jak zapisovat do souboru jen ... Já chci právě dodržovat určitou strukturu bez oddělování ...

Aby to vlastně ze začátku načetlo 8 byte a pak ve for četlo

4 byte (ID)

4 byte (Delka nazvu)

string /ten samozřejme je velkej podle předchozí informace

4 byte (Delka obrazku/souboru)

"buffer nebo něco" co mi dokáže sestrojit délku souboru a třeba načíst v pictureboxu ...

Samozřejmě je to jen example nemusí tam bejt přímo obrázek ale že bych rád zachoval tuhle strukturu ...

Edit : Ale jinak dík, že jsi mě poslal správným směrem jakým se mám zaměřit.

Tak ted ti nerozumim.

Ty chces cist a ukladat jednotlive frame z obrazku??

Nebo ti nerozumim - podle ceho chces ridit ten pocet nactenych byte??

#4 VladislavK
Jde o to abych si ukladal jednotlivé informace zvlášt.

ID (to si vygeneruju podle toho kolik bude souboru)

Délka nazvu

Název

Délka souboru

Soubor

a to vlastně celý opakovat podle počtu souboru v dataarchivu

Ale to jsou ty info oznacene indexem 2

string odd=";";
string nazev="jmeno.ext";
byte[] bb = Encoding.ASCII.GetBytes(ID.ToString()+odd+nazev.Length.ToString()+odd+nazev+odd+ ....... a tak dale

#6 VladislavK
Jojo teď na to koukám taky ... jenom si nejsem přesnej jistej zda jde narvat délka souboru a délka nazvu do ushort nebo musi bejt int prostě aby se délka mohla uložit do 4 byte jak délka nazvu tak souboru ...

Myslím tím zápis podobný tomuhle kdyby to šlo.

byte[] newData = new byte[2];
newData[0] = 0x4F; 
newData[1] = 0;

doporučuju udělat tabulku o obsahu binarky, kde jsou uložený jednotlivý obrázky a potom jen všechny obrázky nasypat vedle sebe... nevýhoda je, že soubor bude o něco málo větší (pár B/KB max) ale rychlost čtení maximální možná, protože nečteš soubor, ale jen část jelikož víš, kde se obrázek nachází

například stylem.. že prvních 512b bude hlavička a zbytek obrázky 

[name;entry;size| ... | ...] byte(1)byte(2)byte(3)
---------- 512b ------------ -obr1---obr2---obr3-

ideální možnost by ještě byla, udělat hlavičku dynamickou v závislosti na obsahu (počtu obrázků).. tim ušetříš další místo v binárce

a samotný přidání dalšího obrázku nebude nijak náročný, protože na konec zapíšeš obrázek a do hlavičky jen přidáš další záznam o názvu/pozici obrázku

to co radí mutagen je sice klasická možnost, ale při velkým počtu obrázků je to celkem mazec procházet :-)

Uz ti asi rozumim

Takze schvalne, mas velikej obrazek typu BMP jehoz velikost je radove ve stovkach megabytu treba 321Mb jeho velikost v byte je kolik ??? no prece 321 nnn nnn byte a myslis ze se tato hodnota vejde do short nebo ushort pokud vim tak short je 16bit typ tedy rozsah 0-65535 pro ushort nebo -32767 az 32768 pro short 

takze uz si umis odpovedet???

#8 Mutagen
No ja si myslim ze si docela komplikujes - takhle set nedela.

budesli takto ukladat ciselne hodnoty a pak tyto data odneses ke zpracovani na jinem OS typicky linux tak narazis na problem ktery se jmenuje MALY/VELKY endian

nikdy pokud to není opravdu nutný neukládejte velikost názvu zvlášt!! do binárky jde zapsat string jako takovej a on si dynamicky určí jestli je potřeba uložit byte/short/int jako délku názvu

#11 VladislavK
Nejde o Big a Little endian ... Ten teďka nechci řeěit, jde mi čistě jen o Win ...

Jen prostě chci aby to mělo peknou strukturu jak jsem tu už psal no i kdyz upravim to díky par radám.

uint početSouboru;

for (int i = 0; i < početSouboru; i++)

{

ushort ID;

ushort názevSouboru;

string Nazev (tady bude vlastně readbyte s číslem názevSouboru);

int/uint délkaSouboru;

buffer nebo něco do čeho bych zapsal celej soubor (podle délkySouboru);

}

#11 VladislavK
Přesně takhle a různě podobně se to běžně dělá. Problém LE/BE je věc HW a ne OS a řeší se prostě tak, že se řekne v jakém formátu mají hodnoty být a pak se tak zapisují a načítají.

Počuli ste už niekedy o XML ? (ale nie, ale tak na čo objavovať ameriku zbytončým ukladaním do .dat súboru...)

http://www.codeproject.com/…erialization

#15 lkjhg
myslim, že tady je trochu o něco jiného.. kdyby si tvořil řekněme balík třeba 100 obrázků, tak to nebudeš přece dávat takto do XML... jednak serializace objektu je dobrej žrout velikosti a potom nemá smysl ukládat věci do XML, když obrázek má maximálně název a jeho serializovanou podobu

a to bych ještě zapoměl, žě XML je čitelný, takto v .dat souboru si to můžeš dát třeba pod heslo apod. a teď nechci kecat, ale mám dojem, že pokud dobře promyslíš struktůru dat. souboru, tak je s ním mnohem rychlejší práce

#15 lkjhg
Ty jsi o něm zjevně jen slyšel. Kolo znovu objevují všichni bezmozci, kteří nedokázali včas posoudit, na co se XML hodí.