Lokale Relaterte Problemer

Den Nødvendige Kodingen er Ikke et Gyldig Alternativ i Programmet

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.

Programmet Forutsetter Lokalitetsbasert Koding av Eksterne Dokumenter

Alvorlighet: Høy for ikke-tekst dokumenter, lav for tekst dokumenter

Noen programmer, nano-8.2 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.2, 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.

Programmet Bruker eller Oppretter Filnavn med Feil Koding

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.82.2 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-3.0 og UnZip-6.0 har dette problemet fordi de hardkoder den forventede filnavnkodingen. UnZip inneholder en hardkodet konverteringstabell mellom kodingene CP850 (DOS) og ISO-8859-1 (UNIX) og bruker denne tabellen når du trekker ut arkiver opprettet under DOS eller Microsoft Windows. Men, denne antagelsen fungerer bare for de i USA og ikke for alle som bruker en UTF-8 lokalitet. Ikke-ASCII tegn vil bli ødelagt i de utpakkede filnavn.

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.9p1). 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:

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.

Programmet Ødelegger Multibyte Tegn eller Teller Ikke Karakterceller Riktig

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.

Pakken Installerer Manualsider i Feil eller Ikke-visbar Koding

Alvorlighet: Lav

LFS forventer at manuelle sider er på det språkspesifikke (vanligvis 8-bit) koding, som spesifisert på LFS Man DB side. Men, noen pakker installerer oversatte manualsider i UTF-8 koding (f.eks. Shadow, allerede behandlet), eller manualsider på språk som ikke er i tabellen. Ikke alle BLFS pakker har blitt revidert for samsvar med krav satt i LFS (de aller fleste er sjekket, og fikser plassert i boken for pakker som er kjent for å installere ikke-konform manualsider). Hvis du finner en manualside installert av noen av BLFS pakkene, dvs åpenbart i feil koding, vennligst fjern eller konverter den etter behov, og rapporter dette til BLFS teamet som en feil.

Du kan enkelt sjekke systemet for eventuelle ikke-konforme manualsider ved å kopiere følgende korte shell skript til et tilgjengelig sted,

#!/bin/sh
# Begin checkman.sh
# Usage: find /usr/share/man -type f | xargs checkman.sh
for a in "$@"
do
    # echo "Checking $a..."
    # Pure-ASCII manual page (possibly except comments) is OK
    grep -v '.\\"' "$a" | iconv -f US-ASCII -t US-ASCII >/dev/null 2>&1 \
        && continue
    # Non-UTF-8 manual page is OK
    iconv -f UTF-8 -t UTF-8 "$a" >/dev/null 2>&1 || continue
    # Found a UTF-8 manual page, bad.
    echo "UTF-8 manual page: $a" >&2
done
# End checkman.sh

og deretter utstede følgende kommando (endre kommandoen nedenfor hvis checkman.sh skriptet ikke er i din PATH miljøvariabel):

find /usr/share/man -type f | xargs checkman.sh

Merk at hvis du har manualsider installert på et annet sted enn /usr/share/man (f.eks., /usr/local/share/man), må du endre kommandoen ovenfor for å inkludere denne ekstra plasseringen.