Nettleser

Hva som må skje før en nettside gir deg filen sin

Du kan se videoen. Den spiller, akkurat der, i nettleseren. Så hvorfor er det ingen måte å beholde den på? Svaret er at en nettside sjelden overleverer en fil — den overleverer instruksjoner, og filen nettleseren setter sammen fra dem eksisterer kanskje ikke som én ting i det hele tatt.

6 min lesing Oppdatert 29. juli 2026

FoxDL

Fire måter en side leverer video på, bare én av dem er en fil

Den eldste og enkleste er en direkte fil: siden peker på en adresse som slutter på .mp4 og nettleseren henter den. Hvis du kan finne den adressen, har du filen. Dette er fortsatt hvordan de fleste mindre nettsteder, forumer, nyhetskanaler og filverter fungerer.

Den andre er adaptiv strømming — HLS eller DASH. Siden laster en spilleliste som lister opp hundrevis av korte segmenter i flere kvalitetsnivåer, og spilleren syr dem sammen etter hvert som den går, og bytter kvalitet når forbindelsen din endres. Det finnes ingen enkelt fil å finne. Å lagre det betyr å hente hvert segment og bygge en fil fra dem.

Den tredje er en blob-URL. Siden har allerede hentet dataene med JavaScript og gitt spilleren en referanse til noe som lever i nettleserens eget minne. Adressen du kan se (blob:https://…) er meningsløs utenfor den siden og den økten — den kan ikke åpnes, deles eller lastes ned, og dette snubler de fleste naive «videofinnere».

Den fjerde er beskyttet innhold: krypterte segmenter spilt gjennom et DRM-system, der dekrypteringsnøkkelen utstedes til nettleseren under betingelser som eksplisitt forbyr å beholde en kopi. Dette er ikke en hindring man skal omgå; det er mekanismen en lisensavtale er bygget på, og ingen legitim verktøy overvinner det.

Hvordan en nettleser oppdager at det er noe å lagre

En app-intern nettleser som tilbyr å lagre det den finner, gjør flere jobber samtidig. Hver fanger et tilfelle de andre går glipp av.

Lese sidens medieelementer
Gå gjennom dokumentet etter <video>-, <audio>- og <source>-tagger og lese adressene deres. Fanger det direkte-fil-tilfellet umiddelbart, går glipp av alt bygget av JavaScript etter at siden lastet.
Se inni shadow DOM
Moderne spillere er egendefinerte elementer hvis indre er bevisst forseglet fra siden. Et søk som stopper ved det vanlige dokumentet, ser en tom boks der videoen er.
Følge med på hva siden faktisk forespurte
Nettleseren vet om hver ressurs en side hentet. En mediefil som ble lastet — uansett hvilket skript som forespurte den, eller når — dukker opp her selv om ingenting i den synlige siden peker på den.
Snuse på responstypen
En URL som slutter på .php kan returnere en video, og en URL som slutter på .mp4 kan returnere en feilside. Det Content-Type serveren faktisk sendte er hva som forteller deg hvilken — filtyper er en gjetning.

Hvordan det ser ut når lagring fra en side fungerer

Rekkefølgen betyr noe. De fleste feil kommer fra å hoppe over det andre trinnet og starte en fire-gigabyte-overføring av en påloggingsside.

  1. Spill et sekund av mediet først

    Mange sider laster ingenting før avspilling starter. To sekunder med avspilling er ofte forskjellen mellom en tom liste med kandidater og en full en.

  2. Sjekk hva kandidaten faktisk er

    Før du forplikter deg, se på den oppgitte størrelsen og typen. En «film» på 14 KB er en HTML-side. En type på text/html der du forventet video/mp4 betyr at du har feil lenke.

  3. Velg kvaliteten du vil ha

    En strøm tilbyr vanligvis flere. Den høyeste er ikke alltid riktig svar på en telefon, der forskjellen er usynlig og lagringen ikke er det.

  4. La økten følge med

    Beskyttede lenker sjekker hvem som spør: informasjonskapslene fra den innloggede økten din, siden som henviste deg, noen ganger nettleseridentiteten. En nedlasting startet uten dem får en 403 selv om siden spilte fint.

  5. Bekreft hva som landet

    Åpne den. En fil som spiller i to sekunder og stopper var avkuttet — vanligvis en utløpt lenke — og er verdt å starte på nytt heller enn å beholde.

Hva en app-intern nettleser må gjøre riktig

Utover å finne mediet, er dette tingene som avgjør om nedlastingen faktisk fullføres.

  • Bær økten gjennom til nedlastingen

    Informasjonskapsler, referer og brukeragent må reise med forespørselen. Uten dem løser en beskyttet lenke seg på siden og feiler i nedlasteren.

  • Hold den legitimasjonen ute av lagring

    Øktinformasjonskapsler er like gode som et passord i øktens varighet. De hører hjemme i minnet for overføringens varighet og ingen andre steder — ikke i en database, ikke i en logg.

  • Nekte å gi lenken til en annen app

    iOS vil gjerne åpne en trykket lenke i en annen app hvis den hevder det domenet. En nettleser ment for å lagre media må avbryte og utstede navigeringen selv, ellers forsvinner siden du ville ha inn i en annens app.

  • Beskjær siden før den rendres

    En innholdsblokkering handler ikke bare om reklame her — færre sporere og overlegg betyr færre falske kandidater i medielisten.

  • Håndtere dokumenter så vel som video

    PDF-er, ZIP-er og Office-filer er den andre halvparten av det folk lagrer fra nettet, og de bør havne i samme bibliotek som alt annet.

Spørsmål folk stiller

Hvorfor kan ikke Safari gjøre dette på egen hånd?

Safari laster faktisk ned filer — det har den gjort siden iOS 13. Det den ikke gjør er å inspisere en side for media som strømmes i stedet for lenket, eller bygge et segmentert strøm om til en fil. Den er en nettleser, og det arbeidet hører hjemme i en nedlastingsbehandler.

Hva er en blob-URL og hvorfor kan jeg ikke laste den ned?

Det er et håndtak til data siden allerede holder i minnet. Den har ingen eksistens utenfor den fanen, så å lime den inn noe sted gir ingenting. Det underliggende mediet ble hentet fra et sted som er ekte, og den adressen — ikke blob-en — er den verdt å finne.

Siden spiller fint men nedlastingen får en 403. Hvorfor?

Nedlastingsforespørselen ankom uten tingene siden hadde: øktens informasjonskapsel, den henvisende siden, noen ganger en matchende nettleseridentitet. Servere bruker akkurat den kombinasjonen for å skille en seer fra en skraper.

Kan alt lagres?

Nei, og det er med hensikt. Innhold beskyttet med DRM er kryptert med nøkler utstedt under en lisens som forbyr å beholde det. Noen nettsteder signerer også hvert segment individuelt med kortlevde tokens. Begge fungerer som tiltenkt.

FoxDL

Nettleseren inne i FoxDL

Det er en vanlig nettleser med faner hvis jobb er å få ting inn i biblioteket ditt heller enn å være din hverdagslige nettleser.

  • Seks deteksjonskanaler, inkludert shadow DOM og loggen over hva siden faktisk forespurte, så en spiller bygget helt i JavaScript er fortsatt synlig.
  • Den virkelige typen snuses fra responsen i stedet for gjettet fra filtypen, og blob:-kandidater som ikke kan hentes filtreres bort i stedet for å bli tilbudt og feile.
  • Informasjonskapsler, referer og brukeragent bæres gjennom til nedlastingen slik at en beskyttet lenke løser seg — og ingen av dem skrives noensinne til disk.
  • En innholdsblokkering beskjærer siden før den rendres.
  • PDF-er, ZIP-er og dokumenter lagres inn i samme bibliotek som media, med ett trykk.
  • Faner, bokmerker og en startside med dine egne snarveier.

FoxDL leverer ikke noe innhold selv. Det du lagrer er det du brakte, og du er ansvarlig for å ha rett til å beholde det.

Vanlige spørsmål

Alle spørsmål

Les mer

Hva en nedlastingsbehandler gjør som en nettleser ikke vil

Hvorfor overføringer stopper når du bytter app, hva gjenopptaking egentlig krever, og hvordan strømmer blir filer.

Hva en medieapp på telefonen din kan se, og hva den aldri bør sende

Hva en medieapp kan se, hvordan lese en personvernetikett, og hvorfor en lås ikke er kryptering.

Hvor filene dine faktisk bor på en iPhone, og hvem som kan se dem

Sandkassen, hvor nedlastinger faktisk går, og hvorfor å gi en fil nytt navn ødelegger så mange apper.

Biblioteket ditt, endelig på ett sted.

Gratis nedlasting. Ingen konto, ingen registrering — hele funksjonssettet er i gratisversjonen.

Last ned fra App Store