Kryptering mot lösenordsskydd: vad Skydda och Lås upp faktiskt gör
Lösenordsskydd av en PDF är kryptering med ett öppningslösenord. Skydda lägger till det, Lås upp tar bort det när du kan det. Ingen återskapar ett glömt lösenord.
Folk säger ”lösenordsskydda en PDF” och ”kryptera en PDF” som om det vore två olika produkter. I PDF-formatet tillhör de samma mekanism: filen bär på en /Encrypt-post, och läsaren kräver ett lösenord (eller motsvarande behörighet) innan den ger dig sidinnehållet i klartext.
Vad ”lösenordsskydd” faktiskt betyder
En skyddad PDF är inte bara ett lås i ett enskilt programs gränssnitt. Läsare som följer standarden vägrar öppna dokumentet förrän rätt öppningslösenord har angetts. Det handlar alltså om kryptering av filens innehåll, med en nyckel som gör lösenordet nödvändigt för att dekryptera.
Lägg till lösenord (POST /api/v1/security/add-password) tar ett lösenord som du väljer och returnerar en krypterad fil som frågar efter lösenordet när den öppnas. Formuläret i portalen har ett enda lösenordsfält. Servern krypterar via qpdf (--encrypt) och använder värdet som användarlösenord för öppning; om inget separat ägarlösenord skickas till API:et används samma sträng för ägarrollen. Standardlängden på nyckeln är 256 bitar. Verktyget sparar inte ditt lösenord när bearbetningen är klar. Tappar du bort det förblir filen låst.
Användarlösenord mot ägarlösenord
PDF-kryptering skiljer sedan länge på två roller:
- Användarlösenord (öppning): krävs för att alls öppna och visa dokumentet.
- Ägarlösenord (behörigheter): används ofta för att sätta begränsningar för utskrift och ändring, samtidigt som någon fortfarande kan öppna filen med användarlösenordet (eller med ett tomt öppningslösenord, beroende på hur filen skapades).
Det är begrepp i formatet, inte marknadsföringsetiketter. Många vardagliga flöden för att ”låsa en PDF” sätter bara ett öppningslösenord. Att begränsa utskrift eller redigering utan att blockera öppning är en fråga om behörigheter via ägarrollen, och det blandas lätt ihop med ”filen går inte att öppna”.
På PDF123 ber formuläret för Skydda om ett enda lösenord och behandlar det som det öppningslösenord som krävs för att visa filen. Lås upp behöver samma kända lösenord för att dekryptera. Avancerade API-anropare kan skicka ownerPassword, keyLength, canPrint och canModify till add-password; formuläret i webbläsaren visar inte de inställningarna.
Vad Lås upp gör och inte gör
Ta bort lösenord (POST /api/v1/security/remove-password) tar bort befintlig lösenordskryptering när du anger det aktuella lösenordet. Sidor, teckensnitt och layout är oförändrade; bara kravet på kryptering försvinner.
Den återskapar, gissar eller knäcker inte ett glömt lösenord. Kan du inte lösenordet redan skapar Lås upp inget åt dig. Reparera tar inte heller bort kryptering: om Dokumentinfo rapporterar Encrypted: true måste du låsa upp först och redigera sedan.
När du ska använda vilket
| Mål | Verktyg |
|---|---|
| Kräv ett lösenord för att öppna före sändning eller delning | Lägg till lösenord |
| Du kan redan lösenordet och vill ha en fritt öppningsbar kopia | Ta bort lösenord |
| Du har glömt lösenordet | Inget av verktygen hjälper; förvara lösenord utanför PDF:en |
| Filen går inte att öppna av strukturella skäl (inte kryptering) | Reparera PDF / Dokumentinfo, inte Lås upp |
Både Skydda och Lås upp körs på servern och kräver inget konto i katalogvägen. Kryptering krymper inte filen; Komprimera PDF är en separat omkomprimering av strömmar och kräver fortfarande en upplåst (eller aldrig krypterad) PDF. OCR, tabellexport och de flesta redigeringsoperationer behöver på samma sätt klartextåtkomst först: lås upp med ett känt lösenord och kör sedan det andra verktyget.
Förvara lösenord utanför PDF:en, i en lösenordshanterare eller ett hemlighetsvalv. Att skicka öppningslösenordet i samma e-post som bilagan gör skyddet verkningslöst. För samma uppgifter över HTTP, se Utvecklare.