Når man tænker på, hvor fleksible reglerne for navngivning af filer og mapper er, så er det egentligt forbavsende, hvor sjældent det giver anledning til problemer. Det betyder så, at når problemer opstår, så står man ofte ret uforberedt. Men der er kun én regel, som altid holder: Navngivning foretages af det program, der opretter filen og hvis filen også skal bruges af et andet program, fx et program til sikkerhedskopiering, så er det sikreste at prøve det. Det er muligt at oprette et dokument fra din tekstbehandling med et langt og beskrivende navn med mange mellemrum og andre specialtegn, men det er ikke ensbetydende med, at dit backup program kan læse og tilbageføre den samme fil med det samme navn. En meget konservativ navngivning der kun benytter US Ascii bogstaver og tal og ingen mellemrum, er det, der er størst sikkerhed for at kunne genbruges i ethvert program, men det er måske en anelse mere restriktivt end nødvendigt – det afhænger helt af, hvor forskelligartet din anvendelse af dine dokumenter er – fx om du bruger de samme filer fra Windows, fra Mac og fra Linux. Og om du bruger dem i systemer med meget forskellig alder (Du skal ikke flytte en harddisk fra en Windows 10 PC til en ældre Windows XP maskine eller en Linux PC og umiddelbart forvente, at du kan læse alle filnavne, hvis du har brugt specialkarakterer og danske tegn.
Et filnavn er egentligt blot en streng af tegn, men som udgangspunkt kan benyttes forskellige tegnsæt. I gamle dage var et udbredt filnavn et DOS 8.3 navn: Filen indeholdt 1 punktum efterfulgt af en extension på max 3 tegn (extension kan være hvad som helst, men har en speciel betydning, se senere) så selve “navnet” var på 8 tegn. Disse 8 tegn blev dannet ved hjælp af 127 (senere 255) forskellige koder og computerens codepage, så hvis filen sørens.txt blev flyttet fra en PC med dansk codepage til en maskine med en anden codepage, så kom den måske til at hedde s|rens.txt, s[rens.txt eller s¢rens.txt. Denne type forskel eksisterer også med de længere filnavn som bliver kodet med ANSI tegnsættet: ANSI tegnsættet kan ikke på en gang indeholde alle verdens tegn og derfor fortolkes det altid ved hjælp af en codepage eller locale. Det har længe været lidt irriterende og løsningen er selvfølgelig at benytte Unicode tegnsæt. Unicode tegnsæt indeholder plads til mange, mange flere forskellige tegn. Desværre er der forskellige varianter af Unicode:
- UCS-2 (benyttet af vfat filsystemet i Windows 95 / Windows NT og frem) hvor hvert tegn repræsenteres ved 2 bytes (16 bit).
- UCS-16 (benyttes som primære encoding på Windows systemer med NTFS formaterede partitioner og på Mac systemer med HFS+) hvor hvert tegn består af 2 eller 4 bytes.
- UTF-8 (benyttes som udgangspunkt på Linux og på hjemmesider/webløsninger) hvor hvert tegn består af 1 til 4 bytes.
De forskellige kodetabeller er (stort set) enige om fortolkningen af den første byte og derfor kan man nogen gange se flyttede filer, der har delvist rigtige navne (og det er også derfor, at man som regel ikke løber ud i problemer, hvis man holder sig til konservativ navngivning).
Selv om det måske lyder lidt kompliceret, så er det faktisk meget værre. Fx så er det indbygget i Windows operativsystemet, at det kan finde ud af at fortolke både ANSI og UCS-16 (og dermed også UCS-2) filnavne i den samme partition og Linux (som jeg kan næsten alt) giver mulighed for at man kan montere en partition med forskellige drivere, så man tvinger systemet til at fortolke fx en harddisk fra et gammelt Windows system med vfat fortolkning.
Nederst i artiklen er der en række henvisninger til mere detaljerede beskrivelser af disse problemstillinger samt oversigter over forbudte tegn og forbudte filnavne.
Typiske problemer
Backup programmer: Tjek dem. Selv om du kan kalde filer næsten hvad som helst så er det ikke sikkert at dit backup program kan sikkerhedskopiere og genindlæse filen med samme navn.
Flytning af data fra et system til et andet: Selv om disken eller USB-pinden godt kan læses på forskellige systemer (fx en kopi af data fra Mac til Linux) så er det ikke sikkert, at de læser det samme. Brug konservativ navngivning eller flyt filerne via skyen (Dropbox, NextCloud og lignende): Så bliver de gemt og læst fra skyen af et program (Dropbox/Nextcloud klienten), der forstår reglerne på det system, hvor det er installeret.
Fortolkning af extension: Tegnene efter det sidste punktum benyttes til at fortælle operativsystemet, hvilket program, det som udgangspunkt skal bruge til at arbejde med den pågældende fil. Så hvis du på en Windows PC dobbelklikker på en fil mitbrev.docx, så vil Windows automatisk starte Office Word og indlæse filen. Men tegnene efter punktum er blot tegn, så hvis du i Notesblok laver en fil, som du kalder mitbrev.docx, så vil Word forsøge at åbne den og ikke kunne finde ud af det. I den sammenhæng kan det varmt anbefales at man ændrer en standard indstilling i Windows: Microsoft er så glade for brugervenlighed, så de som udgangspunkt skjuler extension, hvis der findes et program, der kan forstå dem. Slå det fra. Straks. (Indstillingen er blevet flyttet rundt i de forskellige Windows udgaver, men i Windows 10 finder du den i Stifinder på fanen Vis)
Mere om regler og begrænsninger for filnavne: https://en.wikipedia.org/wiki/Filename
Mere om Unicode: https://da.wikipedia.org/wiki/Unicode og UTF-16: https://en.wikipedia.org/wiki/UTF-16
Mere om montering af diske under Linux (fstab): https://www.howtogeek.com/howto/38125/htg-explains-what-is-the-linux-fstab-and-how-does-it-work/