[www] Waarom gebruikt niet iedereen UTF-8?

[usr-local-dick]

Hoi

TOen ik begon met websites en formulieren waar veel niet-westerse mensen dingen invulden, kwam ik al snel tot de conclusie dat UTF-8 de enige manier is om e.e.a. goed in beelde te krijgen.
Standaard encoding schema's zoals ISO-8859-*, KOI etc zijn eigenlijk maar een subset van UTF-8.
Als iedereen nou gewoon UTF-8 gebruikt dan heb je nooit meer last van karakters die ergens niet goed doorkomen.
Iedereen die webscripting doet komt er vroeg of laat achter dat de accenten en umlauts niet goed gaan, en stapt dan over op UTF-8. Waarom niet gelijk dit overal doen?

[.oisyn]

Of UTF-16, of gewoon 32 bits unicode

[PommeFritz]

Misschien omdat het correct editen van UTF-8 files nogal eens problemen oplevert?
UltraEdit (wat ik gebruik) kan het wel prima, maar er zijn niet zo heel veel text editors die het snappen. En dan is het makkelijker om ISO-8859-1 of Windows-1252 te gebruiken (wat die editors WEL snappen).
Hoewel je dan in de problemen komt als je een teken wilt tonen dat niet in deze character set zit: je moet dan terugvallen op de HTML entity. (b.v. © ofzo).

[NMe]

PommeFritz schreef op 11 maart 2004 @ 01:31:
Misschien omdat het correct editen van UTF-8 files nogal eens problemen oplevert?
UltraEdit (wat ik gebruik) kan het wel prima, maar er zijn niet zo heel veel text editors die het snappen. En dan is het makkelijker om ISO-8859-1 of Windows-1252 te gebruiken (wat die editors WEL snappen).
Hoewel je dan in de problemen komt als je een teken wilt tonen dat niet in deze character set zit: je moet dan terugvallen op de HTML entity. (b.v. © ofzo).

Beetje een zwak argument vind ik. Een editor installeren is geen moeite, en er zijn zat professionele editors te bedenken die UTF-8 aankunnen. Je noemt zelf al UltraEdit en zo is er bijvoorbeeld ook TextPad. Iemand die aan websites doet en die een editor gebruikt die geen UTF-8 ondersteunt is gewoon fout bezig. Notepad is nou eenmaal een rotprogramma...

[Hican]

Hey, hey... kom niet aan mijn altijd heerlijk werkende notepadje he Maarem, wel een goed punt heb je daar local. Het zou idd makkelijker zijn als iedereen volgens UTF-8 ging 'coden'. Ik zal het eens aankaarten bij de rest van nederland

[Soultaker]

PommeFritz schreef op 11 maart 2004 @ 01:31:
Misschien omdat het correct editen van UTF-8 files nogal eens problemen oplevert?
UltraEdit (wat ik gebruik) kan het wel prima, maar er zijn niet zo heel veel text editors die het snappen. En dan is het makkelijker om ISO-8859-1 of Windows-1252 te gebruiken (wat die editors WEL snappen).

Welke versie van UltraEdit heb jij dan?? Want het is mij dus nog nooit gelukt om UNICODE tekst te editen in UlraEdit en dat is gelijk m'n grootste bezwaar tegen dat programma. Zie hieronder.

Microsoft Notepad kan trouwens perfect Unicode tekst editen en lezen/opslaan in UTF-8 formaat.

Experimentje
Men zoeke een website met Unicode tekst:


Pasten naar Notepad werkt perfect:


Maar pasten naar UltraEdit werkt niet; de vraagtekentjes doen vermoeden dat er inderdaad conversie naar een simpele codepage wordt uitgevoerd en dat al die Japanse karakters buiten de boot vallen:


Het UTF-8 bestand inlezen dat door Notepad geschreven werd, werkt ook niet: UltraEdit beschouwt 't gewoon als (extended) ASCII:


edit:
En toen kwam ik de optie File > Conversions > UTF-8 to Unicode tegen en ging het wel goed:

Ik neem mijn bezwaren tegen UltraEdit dus terug.

.oisyn schreef op 10 maart 2004 @ 22:50:
Of UTF-16, of gewoon 32 bits unicode

UTF-16 vind ik voor transmissie niet echt een nuttige standaard; dan heb je tekst die én niet echt compact is én niet verwerkt kan worden door 'ouderwetse' programma's die nog uitgaang van 8-bits codepages (extended ASCII). Enige nut van UTF-16 is naar mijn idee om nog enige vorm van ondersteuning voor echt hoge Unicode karakters te krijgen in programma's die intern met 16-bits karakters werken (en zich anders dus tot UCS-2 zouden moeten beperken). UCS-4 heeft hetzelfde probleem als UCS-2 en (extended) ASCII: in principe is de Unicode karakterset niet beperkt tot 32 bits codepoints (al is dat wel erg theoretisch ).

[ Voor 34% gewijzigd door Soultaker op 11-03-2004 03:12 ]

[.oisyn]

Overigens is mijn inziens de reden dat weinig mensen het gebruiken juist omdat multibyte strings een ware programming hell zijn. Goed, strings opslaan en uitlezen gaat prima, maar echte stringbewerking wordt al gauw een ramp. Het aantal tekens in de string hoeft niet gelijk te zijn aan het aantal chars, waaruit volgt dat het teken op positie N niet per se het N-de teken hoeft te zijn. Veel van de stringbewerkingsroutines ondersteunen geen multibyte strings: de perl en posix regex libs van php bijvoorbeeld kunnen flink de soep in gaan

De ideale manier is eigenlijk intern altijd te werken met de volledige unicode charset (32 bits chars dus), en dat op het eind te converteren naar de juiste encoding.

Soultaker: overigens heten die dingen UCS-2 en UCS-4, niet UCS-16 en UCS-32

[ Voor 6% gewijzigd door .oisyn op 11-03-2004 03:02 ]

[Soultaker]

Ik begrijp niet dat de evaluatie met reguliere expressies fundamenteel moeilijker is met multibyte strings, wat die worden doorgaans toch geïmplementeerd met statemachines waar karakters één voor één ingevoerd worden. Ik kan me het probleem met traditionele code wel voorstellen (ik loop zelf ook vaak genoeg strings door met for-lusjes) maar dat is meer een gevolg van code op een onhandige manier schrijven. Ik kan namelijk geen stringbewerkingen bedenken die van indexing afhankelijk zijn; als je simpelweg een cursor heen en weer kunt bewegen in een string zou dat voldoende moeten zijn (en gelukkig heeft UTF-8 de prettige eigenschap dat karakterscheidingen altijd geïdentificeerd kunnen worden). Een en ander is wel wat complexer en de processor zal wat harder moeten werken, maar voor heel veel toepassingen zou dat nauwelijks uit moeten maken.

Sowieso zouden dit soort implementatiedetails webdesigners (bijvoorbeeld) er niet van hoeven weerhouden UTF-8 te gebruiken, aangezien de meeste browsers en editors dit ondersteunen.

[.oisyn]

Soultaker schreef op 11 maart 2004 @ 03:02:
Ik begrijp niet dat de evaluatie met reguliere expressies fundamenteel moeilijker is met multibyte strings, wat die worden doorgaans toch geïmplementeerd met statemachines waar karakters één voor één ingevoerd worden.

/.{3}/
Een regex-library die geen weet heeft van multibyte chars zal hier altijd gewoon 3 chars doorlaten. Als ik echter 2 tekens opgeef die dmv surrogate codepoints totaal 4 bytes beslaan in utf-8 dan heb ik dus een match, en is die string bovendien geen geldige utf-8 aangezien ie wordt afgekapt

[Soultaker]

Accoord, bestaande functies die gemaakt zijn voor de ene codering werken doorgaans niet goed op een andere, maar het lijkt me nog steeds niet fundamenteel moeilijker om een regexp library te maken voor UTF-8 of UCS-2/4 encoded strings dan voor simpele ASCII strings. (Als het gaat om het gebruik van bestaande functies dan is UTF-8 sowieso veel prettiger dan UCS-2/4.)

[.oisyn]

Nou ja windows NT en java zijn gebaseerd op UCS-2, dus wat dat betreft is het niet zo'n probleem, maar verder ben ik het wel met je eens. In de state machines van regexen kun je gemakkelijk de surrogate codepoints opnemen zodat er in zo'n geval meerdere codepoints tegelijk gematched kunnen worden

[Juup]

.oisyn schreef op 11 maart 2004 @ 02:48:
de perl en posix regex libs van php bijvoorbeeld kunnen flink de soep in gaan

Kleine toevoeging voor de Perlers onder ons:

code:

use utf8;

Zorgt ervoor dat je wel gewoon regexes op unicode strings kan loslaten en dat zaken als substr en index goed gaan.

[Korben]

.oisyn schreef op 11 maart 2004 @ 02:48:
Overigens is mijn inziens de reden dat weinig mensen het gebruiken juist omdat multibyte strings een ware programming hell zijn.

Enter: .NET. Lang leve System.Char.

[TeeDee]

Misschien een extra aanvulling.
Voor de liefhebbers: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Toevallig gisteren nog in een topic gezien. Leuk leesvoer, en historisch is het ook wel interessant.

[Soultaker]

Korben schreef op 11 maart 2004 @ 14:47:
Enter: .NET. Lang leve System.Char.

Het probleem met System.Char en andere 'wide' characters zoals Java's char en C/C++'s wchar_t is dat ze 'slechts' 16 bits bevatten en dus alleen geschikt zijn voor codepoints onder de 65536. Jammer genoeg bevat Unicode veel meer karakters (ik dacht dat ze nu maximaal 20 bits gebruikten voor de zeldzamere codepoints). Wide characters zijn dus vaak goed genoeg, maar in principe niet fundamenteel beter dan ouderwetse characters.

Een veel mooiere oplossing is het gebruik van 32-bits characters. Dat is voor het verwerken op moderne CPU's geen enkel probleem, aangezien dat tenminste 32-bits processoren zijn. Het enige probleem (zeker in een byte-addressed architectuur als IA-86) is dat het zo veel bytes verspilt.

En dan is UTF-8 dus ideaal: karakters lezen en schrijven in UTF-8 codering om geheugen en bandbreedte te besparen maar verwerken als 32-bits waarden. Die oplossing lijkt mij in veel opzichten efficiënter en completer dan het werken met UCS-2 codering zoals tegenwoordig gangbaar is. Het enige nadeel van werken met UTF-8 is dat het coderen en decoderen relatief veel werk is (al valt het nog wel een beetje mee: het zijn alleen wat bit-operaties en geen vermenigvuldigingen/delingen zoals bij oudere Unicode coderingen wel voorkwam). Ik denk dat dat ook de reden is dat UTF-8 nog niet overal gebruikt wordt: werkgeheugen is relatief goedkoop en veel strings zijn betrekkelijk kort (zeker vergeleken met dingen als plaatjes of geluid) waardoor UCS-2 toch nog erg efficiënt werkt.

edit:
Dat artikel van Joel Spolsky is inderdaad een goede introductie. Ik sla daar ook regelmatig mensen mee om de oren. De technische introductie op de Unicode website is trouwens een andere korte, goede introdcutie.

[ Voor 20% gewijzigd door Soultaker op 11-03-2004 15:29 ]

[.oisyn]

Soultaker schreef op 11 maart 2004 @ 15:25:
[...]

Het probleem met System.Char en andere 'wide' characters zoals Java's char en C/C++'s wchar_t is dat ze 'slechts' 16 bits bevatten en dus alleen geschikt zijn voor codepoints onder de 65536.

wchar_t is op veel linux distro's 32 bits geloof ik

Jammer genoeg bevat Unicode veel meer karakters (ik dacht dat ze nu maximaal 20 bits gebruikten voor de zeldzamere codepoints). Wide characters zijn dus vaak goed genoeg, maar in principe niet fundamenteel beter dan ouderwetse characters.

Iets meer dan 70.000, aldus unicode.org. De range van codepoints is nu iig 0 tot 0x10fffd, wat neerkomt op ruim 1 miljoen codepoints (inclusief surrogate en private codepoints dan)

Korben schreef op 11 maart 2004 @ 14:47:
[...]
Enter: .NET. Lang leve System.Char.

.oisyn in "[www] Waarom gebruikt niet iedereen UTF-..."

[ Voor 13% gewijzigd door .oisyn op 11-03-2004 17:48 ]