Sammenligning af getPath (), getAbsolutePath () og getCanonicalPath () i Java

1. Oversigt

Det java.io-fil klasse har tre metoder - getPath (), getAbsolutePath () og getCanonicalPath () - for at hente filsystemstien.

I denne artikel vil vi hurtigt se på forskellene mellem dem og diskutere en brugssag, hvor du kan vælge at bruge en frem for de andre.

2. Metodedefinitioner og eksempler

Lad os starte med at gå over definitionerne af de tre metoder sammen med eksempler baseret på at have følgende katalogstruktur til stede i brugerens hjemmekatalog:

| - baeldung | - baeldung.txt | - foo | | - foo-one.txt | \ - foo-two.txt \ - bar | - bar-one.txt | - bar-two.txt \ - baz | - baz-one.txt \ - baz-two.txt

2.1. getPath ()

Kort fortalt, getPath () returnerer Snor repræsentation af filens abstrakte stienavn. Dette er i det væsentlige stienavnet videregivet til Fil konstruktør.

Så hvis den Fil objekt blev oprettet ved hjælp af en relativ sti, den returnerede værdi fra getPath () metode ville også være en relativ sti.

Hvis vi påberåber os følgende kode fra {user.home} / baeldung vejviser:

Filfil = ny fil ("foo / foo-one.txt"); Strengsti = file.getPath ();

Det sti variabel ville have værdien:

foo / foo-one.txt // på Unix-systemer foo \ foo-one.txt // på Windows-systemer

Bemærk, at for Windows-systemet er navneseparatortegnet ændret fra det skråstreg (/), der blev sendt til konstruktøren, til tilbageslagstegn (\). Dette er fordi den returnerede Snor bruger altid platformens standardnavneseparator.

2.2. getAbsolutePath ()

Det getAbsolutePath () metoden vender tilbage stienavnet på filen efter løsning af stien til den aktuelle brugerkatalog - dette kaldes et absolut stienavn. Så for vores tidligere eksempel, file.getAbsolutePath () ville vende tilbage:

/home/username/baeldung/foo/foo-one.txt // på Unix-systemer C: \ Brugere \ brugernavn \ baeldung \ foo \ foo-one.txt // på Windows-systemer

Denne metode løser kun det aktuelle bibliotek for en relativ sti. Forkortelser (som “.” og “..”) løses ikke yderligere. Derfor når vi udfører følgende kode fra biblioteket {user.home} / baeldung:

Filfil = ny fil ("bar / baz /../ bar-one.txt"); Strengsti = file.getAbsolutePath ();

Værdien af ​​variablen sti ville være:

/home/username/baeldung/bar/baz/../bar-one.txt // på Unix-systemer C: \ Brugere \ brugernavn \ baeldung \ bar \ baz \ .. \ bar-one.txt // på Windows-systemer

2.3. getCanonicalPath ()

Det getCanonicalPath () metode går et skridt videre og løser det absolutte stienavn såvel som stenografi eller overflødige navne som “.”Og“.. ifølge katalogstrukturen. Det også løser symbolske links på Unix-systemer og konverterer drevbogstavet til en standard sag på Windows-systemer.

Så for det foregående eksempel, getCanonicalPath () metoden ville vende tilbage:

/home/username/baeldung/bar/bar-one.txt // på Unix-systemer C: \ Brugere \ brugernavn \ baeldung \ bar \ bar-one.txt // på Windows-systemer

Lad os tage et andet eksempel. Givet den aktuelle mappe som $ {user.home} / baeldung og Fil objekt oprettet ved hjælp af parameteren ny fil (“bar / baz /./ baz-one.txt”), output for getCanonicalPath () ville være:

/home/username/baeldung/bar/baz/baz-one.txt // på Unix-systemer C: \ Brugere \ brugernavn \ baeldung \ bar \ baz \ baz-one.txt // på Windows-systemer

Det er værd at nævne, at en enkelt fil på filsystemet kan have et uendeligt antal absolutte stier, da der er et uendeligt antal måder, stenografiske repræsentationer kan bruges. Imidlertid, den kanoniske sti vil altid være unik da alle sådanne repræsentationer er løst.

I modsætning til de sidste to metoder, getCanonicalPath () kan kaste IOUndtagelse fordi det kræver filsystemforespørgsler.

For eksempel på Windows-systemer, hvis vi opretter en Fil objekt med en af ​​de ulovlige tegn, at løse den kanoniske sti vil kaste en IOUndtagelse:

ny fil ("*"). getCanonicalPath ();

3. Brug sag

Lad os sige, at vi skriver en metode, der tager en Fil objekt som parameter og gemmer sit fuldt kvalificerede navn i en database. Vi ved ikke, om stien er relativ eller indeholder stenografi. I dette tilfælde vil vi muligvis bruge getCanonicalPath ().

Men siden getCanonicalPath () læser filsystemet, det koster en præstationsomkostning. Hvis vi er sikre på, at der ikke er overflødige navne eller symbolske links, og drevbogstavet er standardiseret (hvis du bruger et Windows OS), så foretrækker vi at bruge getAbsoultePath ().

4. Konklusion

I denne hurtige vejledning dækkede vi forskellene mellem de tre Fil metoder til at få filsystemsti. Vi har også vist en brugssag, hvor en metode kan foretrækkes frem for den anden.

EN Junit testklasse, der viser eksemplerne på denne artikel, kan findes på GitHub.