Denne siden inneholder informasjon om lokalitetsrelaterte problemer og problemstillinger. I de følgende avsnittene finner du en generisk oversikt over ting som kan dukke opp når du konfigurerer systemet ditt for ulike steder. Mange (men ikke alle) eksisterende lokalitetsrelaterte problemer kan klassifiseres og faller inn under en av overskriftene nedenfor. Alvorlighetsgradene nedenfor bruker følgende kriterier:
Kritisk: Programmet utfører ikke hovedfunksjonen sin. Løsningen ville være veldig omfattende, det er bedre å søke etter en erstatning.
Høy: En del av funksjonaliteten som programmet gir er ikke brukbar. Hvis den funksjonaliteten er nødvendig, er det bedre å søke etter en erstatning.
Lav: Programmet fungerer i alle typiske brukstilfeller, men mangler noe funksjonalitet som normalt leveres av dets ekvivalenter.
Hvis det er en kjent løsning for en bestemt pakke, vil den vises på pakkens side.
Alvorlighet: Kritisk
Noen programmer krever at brukeren spesifiserer tegnkodingen for
deres inndata eller utdata og presenterer bare et begrenset utvalg
av kodinger. Dette er tilfellet for -X
alternativet i Enscript-1.6.6, -input-charset alternativet i uoppdatert Cdrtools-3.02a09, og tegnsettene som tilbys
for visning i menyen til Links-2.30. Hvis
den nødvendige kodingen ikke er i listen blir programmet vanligvis
helt ubrukelig. Til ikke-interaktive programmer, kan det være mulig
å omgå dette ved å konvertere dokumentet til et støttet
inndatategnsett før innsending til programmet.
En løsning på denne typen problemer er å implementere den nødvendige støtten for den manglende kodingen som en oppdatering til det originale programmet eller å finne en erstatning.
Alvorlighet: Høy for ikke-tekst dokumenter, lav for tekst dokumenter
Noen programmer, nano-8.4 eller JOE-4.6 for eksempel, antar at dokumenter alltid er i kodingen antydet av gjeldende lokalitet. Mens denne antakelsen kan være gyldig for de brukeropprettede dokumentene, er det ikke trygt for eksterne. Når denne antagelsen mislykkes, blir ikke-ASCII tegn vist feil, og dokumentet kan bli uleselig.
Hvis det eksterne dokumentet er helt tekstbasert, kan det bli konvertert til gjeldende lokalitetskoding ved hjelp av iconv programmet.
For dokumenter som ikke er tekstbaserte er dette ikke mulig. Faktisk kan forutsetningen i programmet være fullstendig ugyldig for dokumenter der Microsoft Windows operativsystemet har satt de facto standarder. Et eksempel på dette problemet er ID3v1 koder i MP3-filer. For disse tilfellene er den eneste løsningen å finne et erstatningsprogram som ikke har problemet (f.eks. et som lar deg spesifisere den antatte dokumentkodingen).
Blant BLFS pakker gjelder dette problemet nano-8.4, JOE-4.6, og alle mediespillere unntatt Audacious-4.4.2.
Et annet problem i denne kategorien er når noen ikke kan lese dokumentene du har sendt dem fordi deres operativsystem er satt opp til å håndtere tegnkodinger annerledes. Dette kan skje ofte når den andre personen bruker Microsoft Windows, som kun gir en tegnkoding for et gitt land. For eksempel, dette forårsaker problemer med UTF-8 kodede TeX dokumenter opprettet i Linux. På Windows vil de fleste applikasjoner anta at disse dokumentene har blitt opprettet med standard Windows 8-bits koding.
I ekstreme tilfeller kan problemer med Windows kodingskompatibilitet kun løses ved å kjøre Windows programmer under Wine.
Alvorlighet: Kritisk
POSIX standarden krever at filnavnkodingen er kodingen implisert av
gjeldende LC_CTYPE lokalekategori. Denne informasjon er godt skjult
på siden som spesifiserer atferden av Tar og Cpio
programmer. Noen programmer tar feil som standard (eller har rett
og slett ikke nok informasjon til å få det riktig). Resultatet er
at de oppretter filnavn som senere ikke vises riktig av
ls, eller de nekter å
godta filnavn som ls
vises ordentlig. For GLib-2.84.0 biblioteket, kan problemet
rettes ved å stille inn G_FILENAME_ENCODING miljøvariabel til den spesielle
"@locale" verdien. Glib2 baserte
programmer som ikke respekter den miljøvariabelen er buggy.
.zip formatet har dette problemet
fordi den ikke lagrer kodingen for navnene på arkiverte filer. Når
unzip (faktisk en
symbolkobling til bsdunzip fra libarchive-3.7.9) pakker det ut, som
standard antas navnene å være kodet som CP850, Windows kode for
vesteuropeiske språk. Men navnene kan faktisk være kodet på en
annen måte hvis den inneholder ikke-latinske tegn (for eksempel
CP936 for forenklet kinesisk). Deretter uten manuelt å spesifiserer
kodingen, vil disse ikke-latinske tegnene bli omgjort til uleselige
sekvenser av bsdunzip.
Den generelle regelen for å unngå denne klassen av problemer er å unngå å installere ødelagte programmer. Hvis dette er umulig, vil convmv kommandolinjeverktøy kunne brukes til å fikse filnavn opprettet av disse ødelagte programmene, eller med vilje mangle de eksisterende filnavnene for å møte de brutte forventningene til slike programmer.
I andre tilfeller er et lignende problem forårsaket av import av filnavn fra et system som bruker en annen lokalitet med et verktøy som er ikke lokalbevisst (f.eks., OpenSSH-9.9p2). For å unngå mangling av ikke-ASCII tegn når du overfører filer til et system med en annen lokalitet, kan en av følgende metoder brukes:
Overfør uansett, fiks skaden med convmv.
På avsendersiden oppretter du et tar arkiv med --format=posix bryteren
overført til tar (dette vil være
standard i fremtidige versjoner av tar).
Send filene som vedlegg. E-postklienter spesifiserer koding av vedlagte filnavn.
Skriv filene til en flyttbar disk formatert med et FAT eller FAT32 filsystem.
Overfør filene med Samba.
Overfør filene via FTP ved å bruke en RFC2640-bevisst server (dette betyr for øyeblikket bare wu-ftpd, som har dårlig sikkerhetshistorikk) og klient (f.eks. lftp).
De siste fire metodene fungerer fordi filnavnene blir automatisk konvertert fra avsenderens lokalitet til UNICODE og lagret eller sendt i denne formen. De blir deretter transparent konvertert fra UNICODE til mottakerens lokalitetskoding.
Alvorlighet: Høy eller kritisk
Mange programmer ble skrevet i en eldre tid hvor multibyte lokaliteter ikke var vanlige. Slike programmer antar at C "char" data type, som er en byte, kan brukes til å lagre enkelttegn. Videre antar de at enhver sekvens av tegn er en gyldig streng og at hvert tegn opptar en enkelt tegncelle. Slike forutsetninger bryter fullstendig i UTF-8 lokaliteter. Den synlige manifestasjon er at programmet trunkerer strenger for tidlig (dvs. ved 80 byte i stedet for 80 tegn). Terminalbaserte programmer plasserer ikke markøren riktig på skjermen, reager ikke på "Tilbake" tasten med å slette ett tegn, og lar søppeltegn stå igjen rundt når du oppdaterer skjermen, som vanligvis gjør skjermen til et komplett rot.
Å fikse denne typen problemer er en kjedelig oppgave fra en programmerers synspunkt, som alle andre tilfeller av ombygging av nye konsepter inn i det gamle feilaktige designet. I dette tilfellet må man redesigne alle datastrukturer for å imøtekomme det faktum at en komplett karakter kan spenne over et variabelt antall "char"-er (eller bytte til wchar_t og konvertere etter behov). Også for hver kall til "strlen" og lignende funksjoner, finne ut om et antall byte, et antall tegn, eller bredden på strengen var egentlig ment. Noen ganger er det raskere å skrive et program med samme funksjonalitet fra bunnen av.
Blant BLFS pakker gjelder dette problemet xine-ui-0.99.14 og alle skallene.