Re: [LOCALE] UTF-8 er noget værre slam

[Jacob Sparre Andersen <sslug@sslug>]

Ole Kofoed Hansen skrev:
> Jacob Sparre Andersen skrev:

> > (det med at droppe bagudkompatibiliteten med ASCII
> > følger helt automatisk af 1 og 2)
> 
> Og det er naturligvis det, der er årsagen til at folk ikke
> gør det sådan.

Men hvorfor er det lige ASCII skidtet skal være kompatibelt
med?  Hvorfor ikke ISO-8859-15?

> Det er nemlig meget mere besværligt at implementere på
> kort sigt.

Det er ikke spor mere besværligt at implementere.  
Variabel-længde tegn er kompliceret at implementere og folk
gør det stort set konsekvent forkert.  Den eneste fordel der
er ved UTF-8 er for amerikanerne der kan lade som ingenting
og fortsætte med at bruge ASCII.

> Der er mange folk, der hellere vil have en løsning, der
> virker for dem nu,

Til det formål har vi ISO-8859-1.  Den har faste
tegnlængder.  Den dækker både skånsk og sjællandsk (og alle
de andre sprog jeg kan læse og/eller skrive).

> og der er nok, som synes at UTF-8 er den løsning. Der er
> vistnok en talemåde i stil med "The worst enemy of
> perfection is adequate."

Nu er UTF-8 snarere »worst« end »adequate«, så det giver
ikke mening at referere til den talemåde.

> Problemet er så bare at overbevise tilhængerne om at UTF-8
> ikke er 'adequate'.

Vi kunne starte med at sørge for at
postlisterne/nyhedsgrupperne kun accepterer ISO-8859-1, så
folk bliver vænnet af med at have deres programmer sat til
at bruge UTF-8.

Det næste trin kan så passende være at specificere en
acceptabel delmængde af Unicode (eller en helt ny
tegnkodningsstandard) og begynde at implementere den.

Et andet nyttigt trin kan være at hakke lidt i Linux og
Glibc, så brugerne ikke kan pille ved tegnkodningen efter at
systemadministratoren har fastsat den.

Jacob

PS: Jeg har på fornemmelsen at POSIX er så elendigt skruet
    sammen at det slet ikke _kan_ fungere med
    fast-bredde-tegnkodninger på over 8 bit/tegn, men jeg
    håber da at jeg tager fejl.  Helt specifikt er har jeg
    det indtryk at det er en byte med indholdet 0 der
    afslutter et filnavn og en byte med indholdet 47 der
    skiller katalognavne - og ikke nogle tegn der
    tilfældigvis har de numre.  Med lidt held kan problemet
    klares ved at omdefinere C-typen "char" passende.

-- 
http://lego.jacob-sparre.dk/Transport/Fly/Colibri/
                            Byggevejledning til et LEGO-fly.