Trenger oppklaring ang charset

[South_Bridge]

På de aller fleste sidene jeg surfer er det som regel en av to standarder som er gjeldende:

 

UTF-8

 

eller

 

Latin1 (ISO 8859-1)

 

Hva er egentlig forskjellen på disse? Begge to er bakoverkompatibel med ASCII. Denne siden bruker Latin1 mens vg.no bruker UTF-8? Fordeler, ulemper? Og i database sammenheng?

[GeirGrusom]

UTF-8 er bedre. Den støtter langt flere tegn, som vel er det viktigste med tegnsett.

[South_Bridge]

UTF-8 er bedre. Den støtter langt flere tegn, som vel er det viktigste med tegnsett.

 

Men hvorfor er det noen da som bruker Latin1? Bruker UTF-8 mer plass?

[GeirGrusom]

Kan gjøre det. Etter det jeg vet, så er det bare de 128 første tegnene som er like som ASCII, og resten dannes av to eller flere bytes. Dette er grunnen til at ÆØÅ blir til ÿ□ (altså to tegn) og lignende når en ser UTF-8 som ASCII.

Edit: når det kommer til HVORFOR noen bruker andre ting, så tror jeg det er mest på grunn av uvitenhet eller en "meh" holdning.

I USA er det ikke noe stress å bruke ASCII, ettersom alle engelske tegn er støttet direkte i ASCII. For andre språk er det derimot en helt annen sak. Noen utenlandske tegn kan ta 2, 3 og 4 byte i Unicode, men alle engelsk-latinske tegn passer inn i 1.

Endret 17. mars 2010 av GeirGrusom

[South_Bridge]

Jeg satt å tenkte på det... hvis man har en egen side på norsk (feks) eller vet at brukerene til siden kommer til å holde seg til norsk/engelsk er vel det et argument for å velge Latin1 om det sparer plass.

 

Her er det også et spm ang mengde da, for mine prosjekter tror jeg UTF-8 vs Latin1 ikke spiller en rolle, så da kan en jo bare ta UTF-8.

[GeirGrusom]

Bruk UTF-8, det funker overalt. Etter min mening er datamengden en sparer ved å bruke extended ASCII småtterier i forhold til problemene som kan oppstå ved å bruke det. I Norsk er det snakk om <1%(røft overslag fra min side) spart båndbredde å bruke extended ASCII.

[South_Bridge]

Etter å ha lest litt så er jeg veldig enig. UTF-8 4 the win!

[GeirGrusom]

Det er også et krav at alle weborienterte programmer som browsere eller mailklienter minst støtter UTF-8. Det er ingen krav til hvilke codepages som støttes.

[steingrim]

Skal man lage helt nye frittstående løsninger i dag, så er det UTF-8 som gjelder. (Hvertfall så lenge du har europeiske brukere, asiatene vil selvsagt klage og heller ønske seg UTF-16 eller 32 når de skal integrere med deg, men den tid den sorg.)

 

Skal man integrere med andre systemer kan det feks være at UTF-8 eller andre multibyte-enkodinger er direkte dumt eller feil. Mange systemer forventer 1 tegn = 1 byte, og med en multibyte-enkoding kan man få rare følgefeil om man starter på feil sted i en datastrøm. Ekstra artig blir det når man introduserer *helt* andre tegnsett som ikke er kompatible med ASCII og man har mange oversettelser på forskjellige systemer gjennom dataflyten.

[GeirGrusom]

Dette er vel i stor grad gamle systemer? Ihvertfall på web som sagt, så forventes det at alle programmer støtter minst UTF-8.

Forresten angående tegnsett, er det vanlig i dag å utvikle C++ programmer med UTF-16? De fleste (alle?) prosjekter jeg har sett bruker std::string fremfor std::wstring av grunner jeg ikke aner.

[steingrim]

Dette er vel i stor grad gamle systemer? Ihvertfall på web som sagt, så forventes det at alle programmer støtter minst UTF-8.

Forresten angående tegnsett, er det vanlig i dag å utvikle C++ programmer med UTF-16? De fleste (alle?) prosjekter jeg har sett bruker std::string fremfor std::wstring av grunner jeg ikke aner.

For web er det vel UTF-8 ja, noe annet er bare dumt.

 

C++ kan jeg heldigvis ingenting om

[duckers]

Et innlegg fra Joel On Software som omhandler temaet. Kan være vell verdt lesingen dersom du er ukjent med temaet.

[Emancipate]

wchar er som regel UCS-2 (som alltid bruker to byte per tegn), ikke UTF-16 (som bruker en kjede på et eller flere (flere=2) words (to byte) per tegn). Bare så det er sagt.

[GeirGrusom]

Den forskjellen var jeg ikke klar over, men det sier egentlig seg selv når en tenker over det.