>> [Musikgengivelse]
>> ROB BOWDEN: Hej.
Jeg er Rob, og lad os håbe, at denne løsning hjælper sætte dig
på vejen til bedring.
Så lad os komme i gang.
>> Vi ser, at det samme er vi bare sørge for, at vi er
hjælp Recover korrekt.
Så brug bare skal være noget ligesom dot skråstreg komme sig.
>> Nu skal vi til at åbne den forventede kort dot rå fil.
Vi ser her, at vi bruger den konstant rå understregning filnavn,
der op her har vi hash defineret som kort prik rå.
OK.
>> Så vi er nødt til at sørge for, at der succes åbnet fordi hvis det
ikke, så vi bør advare brugeren.
Men det antages, at det gjorde, vi nu kommer til at erklære en buffer størrelse JPEG
filnavn længde.
Så dette vil være den buffer, der vi kommer til at sprintf ind.
>> Så hvad er JPEG filnavn længde?
Heroppe ser vi, at det er hash defineres som otte.
Så hvorfor otte?
Nå en given fil vil blive navngivet noget som nul nul nul.
JPG og så har vi brug for en backslash nul.
Så vi har brug for en buffer, der kan gemme otte tegn.
Nu skal vi til at have en tæller, der er kommer til at holde styr på
antal JPEG vi fundet.
>> Og endelig vil vi have en JPEG-fil, der er i første omgang null
der kommer til at være den aktuelt åben fil, som vi skriver til.
Nu vil vi have en yderligere buffer.
Dette er ikke det samme som vores sprintf buffer hvor denne buffer er den ene
at vi læser i de data, fra kortet dot rå.
>> Så bufferen vil være til chars signerede, som du kan
dybest set bare behandle os bytes, og det er vil være til størrelse blokstørrelse
hvor, som vi fortæller dig, blokstørrelse er 512.
Så JPEG kan du behandle alt som blokke af 512 bytes.
>> Nu skal vi til at sløjfe over hele filen.
Vi kommer til at f læse i vores buffer en enkelt byte blok størrelse gange fra
kortet dot rå fil.
Nu hvad betyder f læse tilbage?
Den returnerer antallet af elementer at den med held læse.
Så hvis det lykkedes at læse 512 bytes, så vi ønsker at se, om det var en
JPEG eller skrive det til en JPEG-fil.
Og hvis det ikke vendte tilbage 512 byte, derefter enten filen er afsluttet i
hvilket tilfælde vi vil bryde ud af y loop, eller der er en form for fejl
i hvilket tilfælde vi vil også bryde ud af y loop, men vi vil få lyst til at rapportere
gik der noget galt.
>> OK.
Så under forudsætning af, at vi med succes læse i 512 bytes, ønsker vi at først kontrollere
at gøre disse bytes, som vi bare læse i begynde en JPEG.
Så hvis er JPEG header på vores buffer.
Nu, hvad er det JPEG header gør?
Lad os se.
>> Heroppe ser vi, at denne funktion er returnere en tyr, og at der i noget -
godt her, vi kontrol for at se, om header nul er lig med denne konstante og
header en er lig med denne konstante og header to er lig med denne konstant,
header tre er lig med dette eller dette konstant, hvor alle disse konstanter er
bare hash defineret lige her og er præcis, hvad vi fortalte dig i spec
at en JPEG begynder med.
Og så denne funktion er bare at returnere sand, hvis denne buffer repræsenterer
starten på en ny JPEG og falsk ellers.
>> OK.
Så hvis dette ikke udgør en ny JPEG, så vi først ønsker at kontrollere, om
JPEG-fil er ikke lig med nul, i hvilket tilfælde vi lukke det.
Og så hvorfor har vi brug for at kontrollere at se, om det ikke er null?
Nå den allerførste JPEG, at vi finder vi ikke allerede har
en åben JPEG-fil.
Og så, hvis vi forsøger at lukke det, så Vi laver ikke noget helt rigtigt.
>> Men hver efterfølgende JPEG som vi åbner, vi ønsker at lukke
den foregående fil.
Så nu vil vi bruge sprintf som vi sagde før, hvor vi ved hjælp af
buffer JPEG-fil navn.
Og vi kommer til at bruge JPEG-fil navngive format som vores format.
Og hvad er det?
Heroppe ser vi, at det er procent nul 3D.JPEG hvor nul tre lige
siger, at vi vil bruge tre heltal for dette nuller.
Så dette er, hvordan vi får nul nul one.JPEG og nul 10.JPEG og så videre.
>> Vi kommer til at bruge sprintf.
Og det heltal, at vi indsætter i strengen er følelsesløs JPEG
genvundet, som er oprindeligt nul.
Så den første fil åbnes går at være nul nul nul prik JPEG.
Og så er vi forøge det, så næste fil åbner vi vil være nul nul
en prik JPEG og vi vil forøge det igen, så det vil være nul nul to prik
JPEG og så videre.
>> Ok.
Så nu inde i JPEG-fil navn, har vi navnet på den
fil, vi ønsker.
Vi kan f åbne den pågældende fil til skrivning.
OK.
Og endnu en gang, er vi nødt til at tjekke for at sikker på, at filen med succes
åbnet siden, hvis det ikke gjorde det, så der var en fejl.
>> Så nu har vi fået forbi den er dette en JPEG-del.
Og her ser vi vi vil at skrive til JPEG.
Men vi først har denne kontrol, som siger Hvis JPEG-fil er ikke lig nul.
Hvorfor har vi brug for det?
Nå JPEG-fil er lig nul, når vi øjeblikket har en åben JPEG.
>> Hvad hvis kortet dot rå starter med en flok bytes,
ikke udgør en JPEG?
Så vi vil gerne springe over disse bytes.
Hvis vi ikke har denne check, så er vi kommer til at skrive til en uåbnet
indgive de første 512 bytes kortet, som ikke er god.
OK.
>> Så antager vi har en åben fil, så vi kommer til at skrive til denne fil
512 bytes, som vi har i vores buffer.
Og vi er endnu engang kontrol for at sikker på, at de 512 bytes succes
blev skrevet, fordi hvis de ikke var skrevet korrekt, så noget
gik galt.
Vi lukker vores filer, udskrive denne gik noget galt, og vende tilbage.
Antages alt går korrekt, så vi vil holde looping lukke
gamle fil, åbner den nye fil, skrivning data til den nye fil, og så
indtil endelig denne f læse returneres nul hvilke organer
at filen er færdig.
>> Så nu, at kortet læsning er overstået, vi se, at vi kommer til at f lukke
sidste fil, som vi havde åbent, men Vi tjekker, om JPEG-fil
ikke er lig nul.
Nå f tæt giver mening, fordi som Vi åbner filer, vi lukker
den tidligere fil, men den allersidste fil, som vi åbnede aldrig bliver lukket.
Så det er hvad det gør.
>> Men hvorfor er vi nødt til at tjekke for null?
Jamen hvad nu hvis kortet dot rå gjorde ikke har en enkelt JPEG inde i det?
I så fald ville vi have aldrig åbnet en fil.
Og hvis vi aldrig åbne en fil, skal vi ikke forsøger at lukke filen.
Så det er hvad denne kontrol gør.
>> Nu her, som jeg sagde før, vi kunne har brudt ud, at y loop enten hvis
kortet er afsluttet, eller hvis der er nogle fejl ved læsning fra kortet.
Så dette er kontrol for at se, om der var en fejl ved læsning fra kortet, i
hvilket tilfælde, vil vi sige, at der var en fejl læsning.
Vi ønsker ikke, at brugeren til at tænke alt gik med succes.
Og vi vil man vende tilbage til fejl.
>> Endelig vil vi f lukke vores rå fil, vores kort dot rå, for at angive,
alt gik godt og afkast nul og det er det.
>> Mit navn er Rob og dette var Recover.
>> [Musikgengivelse]