SkÃ¥ne Sjælland Linux User Group - http://www.sslug.dk Forside   Tilmelding   Postarkiv   Forum   Kalender   Søg
MhonArc Dato: [Date Prev] [Kronologisk oversigt] [Date Next]   TrÃ¥d: [Date Prev] [Oversigt trÃ¥de] [Date Next]   MhonArc
 

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



Keld Jørn Simonsen skrev:
> Jacob Sparre Andersen skrev:
> > Keld Jørn Simonsen skrev:

> > > anbefalingen var at ekstern kodning, i filer, på
> > > netværksinterfaces var utf-8, mens intern
> > > programmering var 32 bit.
> > 
> > Den anbefaling må vi så hellere se at få ændret til et
> > krav om at alle grænsesnit køre med 32 bit tegnkodning.
> 
> Lidt mere: Hvorfor? Anbefalingen tilsikrer at al
> programmering med tegn foregår i 32-bit, som du ønsker.

Mener du at compileren selv finder ud af hvilken tegnkodning
der blev brugt til at skrive de tekstfiler jeg indlæser?  
Det lyder næsten som microsoftsk magi.

> Det, der sker er at al kodet tekst konverteres til intern
> 32 bit, så det kan behandles på en ensartet og nem måde,
> og så når behandlingen er overstået konverteres det så til
> ekstern repræsentation igen når data skal udskrives. Den
> eksterne repræsentation kan iøvrigt være alle slags
> tegnsæt, incl utf-8 utf-16 og ucs4.

Problemet er at ca. halvdelen af alle programmørerne kun
husker at konvertere dataene den ene vej og den anden
halvdel kun husker at konvertere dem den anden vej.  Og
variabel-længde tegnkodninger er noget slam - også i filer
og netværkskabler.  Hvad pokker er der galt med at køre UCS4
(det ér den rene 32 bit-kodning, ikke?) konsekvent?

Jacob
-- 
"There are two ways of constructing a software design. One way is to
 make it so simple that there are obviously no deficiencies. And the
 other way is to make it so complicated that there are no obvious
 deficiencies."                                    -- C. A. R. Hoare



 
Forside   Tilmelding   Postarkiv   Oversigt   Kalender   Søg

 
 
Henvendelse vedrørende websiderne til <www_admin>. Senest ændret 2005-08-10, klokken 20:55
Denne side vedligeholdes af MHonArc .