Conversie legacy software naar unicode

[doskabouter]

Heeft een van jullie ervaring met het omzetten van oude code (wordt redelijk veel met ansistrings gewerkt) naar unicode strings?

Liefst (ik weet dat dat lastig is) iets van richtlijnen (bv een grove tijdsinschatting op basis van het totaal aantal regels code, aantal occurrences van "string" oid), en mogelijke pitfalls/aandachtspunten?

[RobIII]

Heel veel meer dan een überglobaal antwoord zul je hier niet op krijgen lijkt me. Schattingen op basis van aantal regels code zijn waardeloos; het ene project is het andere niet en de ene devver is er langer mee bezig dan de ander, sommige zaken kun je wellicht geautomatiseerd oplossen en andere zaken zijn misschien monnikenwerk enz. enz.

Mogelijke pitfalls/aandachtspunten zijn de voor de hand liggende: buffers die niet groot genoeg zijn, IO met andere processen naar derden kan nog steeds ansi vereisen, backends die nog ansi zijn, goede ondersteuning voor unicode van je taal/platform is belangrijk (zo is, meen ik, bijvoorbeeld in PHP unicode deels ondersteund en zijn er dus nog functies die er niet mee overweg kunnen) etc. etc.

Zie: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Zeker met de "wijd open" vraag zoals je je topic start is er gewoon nul zinnigs te zeggen op je vraag; of verwachtte je te horen "2 uur per 250 regels code"?

[ Voor 37% gewijzigd door RobIII op 01-07-2009 17:13 ]

[doskabouter]

Het was ook meer een poging om wat meningen te peilen, en misschien te leren van anderen die iets vergelijkbaars gedaan hebben.

Een van de dingen waar ik graag over zou willen discussieren is of het slim is om heel je code om te zetten naar widestrings, of om een utf8 of zo te gaan gebruiken.

Als je er nl van uit gaat dat unicode niet in 16 bits gaat passen dan heeft de omzetting naar widestrings volgens mij niet zo heel veel zin, want dan zou het toch geencodeerd moeten worden en kan je er nog steeds niet van uit gaan dat s[i+1] het character na s[i] is.

[Zoijar]

Als je het toch om gaat zetten, dan zou ik het niet converteren naar 16vit fixed width unicode, maar gewoon naar een UTF8 unicode encoding.

[Matis]

Zoijar schreef op donderdag 02 juli 2009 @ 09:39:
Als je het toch om gaat zetten, dan zou ik het niet converteren naar 16vit fixed width unicode, maar gewoon naar een UTF8 unicode encoding.

16vit, wasda?! Wikipedia: Vit

Met de TS kan ik/we niet zo veel. Het hele probleem bij het omzetten is dat je verdraait goed moet opletten met je encoding charset.
Zoals dedoskabouter al zegt, met 16bit karakter breedte heb je dus het probleem dat je 2 bytes per karakter nodig hebt. Daarbij komt nog het probleem hoe je dit als endiannes op wilt lossen.

Daarnaast gok ik op 16.4 minuten per 10 regels code

[Zoijar]

Matis schreef op donderdag 02 juli 2009 @ 09:46:
16vit, wasda?! Wikipedia: Vit

De letter naast de b

[Voutloos]

Matis schreef op donderdag 02 juli 2009 @ 09:46:
Zoals dedoskabouter al zegt, met 16bit karakter breedte heb je dus het probleem dat je 2 bytes per karakter nodig hebt. Daarbij komt nog het probleem hoe je dit als endiannes op wilt lossen.

Call me stupid, maar tijdens het devven van het gros van de apps heb je daar toch geen ruk mee te maken? Lees bovenstaande link, converteer alles naar je unicode smaakje en zorg dat je de juiste lib functies gebruikt en klaar.

Dat iedereen als micro optimalisatie een vast aantal bytes per char (liefst 1 ) wilt is juist een van de redenen waarom het hele character encoding geklooi bestaat. Ja, in 1960-1990 was dat nog een echte optimalisatie, maar nu bespaar je jezelf gewoon een hoop gezeik door het met volle overtuiging en zonder conecessies in 1x goed te doen.

[Matis]

Voutloos schreef op donderdag 02 juli 2009 @ 10:07:
Call me stupid, maar tijdens het devven van het gros van de apps heb je daar toch geen ruk mee te maken? Lees bovenstaande link, converteer alles naar je unicode smaakje en zorg dat je de juiste lib functies gebruikt en klaar.

Stupid Met het devven heb je daar geen last van, maar wanneer je je programma portable wilt maken, of het extern wilt benaderen. Dat je dan rekening met je encoding moet houden.
Daarnaast *bespaar* je per karakter wel 1 byte

[TheDane]

ugh,

Wij zijn net klaar met precies zo'n project. Website met interface in 31 talen. Van oudsher was de hele setup (db/connection/apache/php/html) in ISO-8559-1 .. En steeds kwamen er talen bij, steeds exotischer, totdat we een mengelmoesje van UTF-8, ISO-8559-1, Windows-1252 en nog wat vage charsets hadden.

Dit hebben we allemaal in 2 weken omgebouwd naar 'alles-UTF-8', inclusief het (laten) hervertalen van +/- 40.000 teksten in talen waarvan de tekst vernaggeld was wegens foutief converteren tussen charsets. Backups anyone?

De link van RobIII, en diverse related topics @ tweakers waren in ieder geval one major eye opener

[ Voor 9% gewijzigd door TheDane op 02-07-2009 10:28 ]

[Creepy]

Matis schreef op donderdag 02 juli 2009 @ 10:11:
[...]

Stupid Met het devven heb je daar geen last van, maar wanneer je je programma portable wilt maken, of het extern wilt benaderen. Dat je dan rekening met je encoding moet houden.

Zolang je alles UTF-8 maakt en alle apps houden daar rekening mee dan hoef je je dus niet druk te maken over bytes e.d. Op je platform de juiste libs gebruiken en gaan.

Zie ook http://unicode.org/faq/utf_bom.html

Q: Is the UTF-8 encoding scheme the same irrespective of whether the underlying processor is little endian or big endian?

A: Yes. Since UTF-8 is interpreted as a sequence of bytes, there is no endian problem as there is for encoding forms that use 16-bit or 32-bit code units. Where a BOM is used with UTF-8, it is only used as an ecoding signature to distinguish UTF-8 from other encodings — it has nothing to do with byte order. [AF] & [KW]

[ Voor 40% gewijzigd door Creepy op 02-07-2009 14:02 ]