>> [Musikk spilles]
>> ROB BOWDEN: Hei.
Jeg er Rob, og la oss håpe at denne løsningen bidrar til å sette deg
på bedringens vei.
Så la oss komme i gang.
>> Vi ser at straks vi er bare for å være sikker på at vi er
ved å bruke Recover riktig.
Så det behandling bør bare være noe som dot slash gjenopprette.
>> Nå skal vi åpne den forventede kort dot rå fil.
Vi ser her at vi bruker den konstant rå strek filnavn,
som her oppe har vi hash definert som kort dot rå.
OK.
>> Så vi må sørge for at det hell åpnet fordi hvis det
ikke, så vi bør advare brukeren.
Men forutsatt at det gjorde, er vi nå kommer til å erklære en buffer på størrelse JPEG
Lengden på filnavnet.
Så dette kommer til å være den buffer som vi kommer til å sprintf inn.
>> Så hva er JPEG filnavnlengde?
Her oppe, ser vi at det er hash definert som åtte.
Så hvorfor åtte?
Vel en gitt fil vil bli navngitt noe som null null null.
JPG og da trenger vi en backslash null.
Så vi trenger en buffer som kan lagre åtte tegn.
Nå skal vi ha en teller som er kommer til å holde orden på
tall JPEG vi fant.
>> Og til slutt, kommer vi til å ha en JPEG-fil som er utgangspunktet null
som kommer til å være det i dag åpen fil som vi skriver til.
Nå skal vi ha en ytterligere buffer.
Dette er ikke det samme som vår sprintf buffer hvor denne bufferen er en
at vi leser i data fra kortet dot rå.
>> Så bufferen kommer til å være av usignerte tegn, som du kan
utgangspunktet bare behandler oss bytes, og det er kommer til å være av størrelsen blokkstørrelse
der, som vi fortelle deg, blokkstørrelse er 512.
Så JPEG du kan behandle alt som blokker med 512 bytes.
>> Nå skal vi sløyfe over hele filen.
Vi kommer til å f lese i vår buffer en enkelt byte blokkstørrelse ganger fra
kortet dot rå fil.
Nå hva betyr f lese tilbake?
Den returnerer antall elementer at det med hell leses.
Så hvis det klarte å lese 512 bytes, deretter Vi ønsker å se om dette var en
JPEG eller skrive det til en JPEG-fil.
Og hvis det ikke returnerte 512 bytes, deretter enten filen har endt i
hvilket tilfelle vi vil bryte ut av y loop, eller er det noen slags feil
I så fall vil vi også bryte ut av y loop, men vi vil ønske å rapportere
at noe gikk galt.
>> OK.
Så forutsatt at vi klarer å lese i 512 bytes, vi ønsker å først sjekke
å gjøre at disse bytes som vi bare lest i begynne en JPEG.
Så hvis er JPEG header av vår buffer.
Nå hva det er JPEG header gjør?
La oss se.
>> Her oppe, ser vi at denne funksjonen er returnere en okse, og at oksen -
vel her, vi sjekker for å se om header null tilsvarer dette konstant og
header ett tilsvarer dette konstant og header to tilsvarer dette konstant,
header tre tilsvarer dette eller dette konstant hvor alle disse konstantene er
bare hash definert akkurat her og er akkurat hva vi fortalte deg i spec
at en JPEG begynner med.
Og så denne funksjonen er bare kommer til å return true hvis denne bufferen representerer
starten på en ny JPEG og falsk ellers.
>> OK.
Så hvis dette ikke representerer en ny JPEG, Da vi først ønsker å sjekke for å se om
JPEG-fil er ikke lik null, i hvilket tilfelle vi lukke den.
Og så hvorfor trenger vi å sjekke for å se om det ikke er null?
Vel den aller første JPEG at vi finner vi vil ikke allerede har
en åpen JPEG-fil.
Og så, hvis vi prøver å lukke det, så vi ikke gjør noe helt riktig.
>> Men hver påfølgende JPEG som vi åpner, ønsker vi å lukke
forrige fil.
Så nå skal vi bruke sprintf som vi sagt før hvor vi bruker
buffer JPEG filnavn.
Og vi kommer til å bruke JPEG-fil nevne format som vår format.
Og hva er det?
Her oppe, ser vi at det er prosent null 3D.JPEG der null tre like
sier at vi vil bruke tre heltall for dette polstret med nuller.
Så dette er hvordan vi får null null one.JPEG og null 10.JPEG og så videre.
>> Vi kommer til å bruke sprintf.
Og heltall som vi setter inn inn i strengen er nummen JPEG
gjenopprettet, noe som er opprinnelig null.
Så den første filen åpnes kommer å være null null null dot JPEG.
Og så skal vi økes det slik at neste fil åpner vi vil være null null
en prikk JPEG og vi vil øke den igjen slik at det vil være null null to prikk
JPEG, og så videre.
>> OK.
Så nå innsiden av JPEG-fil navn, har vi navnet på
fil som vi ønsker.
Vi kan f åpne denne filen for skriving.
OK.
Og nok en gang, trenger vi å sjekke for å være sikker på at filen vellykket
åpnet siden hvis det ikke gjorde det, så det var noen feil.
>> Så nå har vi fått forbi Dette er en JPEG-delen.
Og her ser vi vi skal å skrive til JPEG.
Men vi først har denne sjekken som sier hvis JPEG-fil er ikke lik null.
Hvorfor trenger vi det?
Vel JPEG-fil er lik null når vi øyeblikket en åpen JPEG.
>> Hva om kortet dot rå starter med en haug med byte som
ikke representerer en JPEG?
Så får vi kommer til å ønske å hoppe over disse bytes.
Hvis vi ikke har denne kontrollen, så vi er kommer til å skrive til en uåpnet
fil de første 512 bytes kortet som ikke er bra.
OK.
>> Så forutsatt at vi har en åpen fil, deretter vi kommer til å skrive til denne filen
512 bytes som vi har i vår buffer.
Og vi er nok en gang kontrollerer sikker på at de 512 bytes vellykket
ble skrevet fordi hvis de ikke var hell skrevet, så noe
gikk galt.
Vi vil lukke våre filer, skrive ut som noe gikk galt, og retur.
Forutsatt at alt går riktig, så vi vil holde looping lukke
gamle filen, åpner den nye filen, skriving data til den nye filen, og så
på helt til slutt, dette f lese returnerer null hvilke midler
at filen er gjort.
>> Så nå at kortleser er over, vi se at vi kommer til å f lukke
siste fil som vi hadde åpent, men Vi sjekker om JPEG-fil
ikke lik null.
Vel f nær er fornuftig fordi som vi er åpne filer, vi stenger
den forrige fil, men den aller siste fil som vi åpnet aldri blir stengt.
Så det er hva dette gjør.
>> Men hvorfor vi må sjekke for null?
Vel, hva om kortet dot rå gjorde ikke har en enkelt JPEG innsiden av det?
I så fall ville vi ha aldri åpnet en fil.
Og hvis vi aldri åpne en fil, bør vi Ikke prøv å lukke filen.
Så det er hva denne sjekken gjør.
>> Nå her, som jeg sa tidligere, vi kunne har brutt ut at y sløyfe enten hvis
kortet er avsluttet, eller hvis det finnes noen feil ved lesing fra kortet.
Så dette er å sjekke for å se om det var en feil ved lesing fra kortet, i
så fall, vil vi si at det var en feil lesing.
Vi ønsker ikke brukeren å tenke alt gikk vellykket.
Og vi vil returnere en for feil.
>> Til slutt vil vi f lukke våre rå fil, våre kort dot rå, for å indikere at
alt gikk bra og retur null og det er det.
>> Mitt navn er Rob, og dette var Recover.
>> [Musikk spilles]