[C++/Win32] Unicode/Ascii/UTF8 textfiles inlezen?

[TheBlasphemer]

Zoals velen van jullie weten zijn er verschillende textbestand formats. De gewone ASCII, elke byte een character, Unicode, elke twee bytes een character, UTF-8, encoded, etc.
Ik ben nu met een programma bezig dat een text taalbestand kan inlezen, en die vervolgens naar goed unicode zet en zlib compressed.

Nu zijn de vertalers niet altijd even computer behendig als ikzelf, en krijg vaak die dingen in verschillende formaten. Internet Explorer kan ze meestal allemaal goed lezen als ik ze naar .txt rename, maar om elke release elke language file eerst door IE te halen is echt een ramp. Verder wil ik dat de vertalers binnenkort zelf hun bestanden laten encoden tot het native bestand, en aangezien ze geen idee hebben wat het verschil is tussen unicode/ascii/utf8, of sommige editors de keuze niet geven, is dat allemaal vrij ingewikkeld.

Voor normaal unicode zetten sommige editors (oa UltraEdit) de bytes FFFE voor. Maar anderen doen dat weer niet

Is er ergens een library/Win32 functie die al deze filetypes kan inlezen? en zo niet, hoe zouden jullie dit aanpakken?

Alvast bedankt,
TB

EDIT: Oops! even vermelden waar ik dus in bezig ben Bij deze dus: C++

[ Voor 4% gewijzigd door TheBlasphemer op 23-11-2005 19:36 ]

[LordLarry]

win32: ReadConsole

[ Voor 3% gewijzigd door LordLarry op 23-11-2005 19:41 ]

[TheBlasphemer]

LordLarry schreef op woensdag 23 november 2005 @ 19:41:
win32: ReadConsole

Zou je mij nou een klein plezier willen doen en voortaan even de beginpost lezen?
Dit heeft niets met inlezen van file of unicode/utf8 conversie te maken...

[NMe]

Wil jij mij dan een plezier doen en in de toekomst niet zo bot reageren op mensen die je proberen te helpen?

[TheBlasphemer]

-NMe- schreef op woensdag 23 november 2005 @ 19:48:
Wil jij mij dan een plezier doen en in de toekomst niet zo bot reageren op mensen die je proberen te helpen?

Excuses Ik raak alleen vrij snel geirriteerd als ik een probleem niet kan oplossen (a)

[Lone Gunman]

hiervoor kun je codecvt facets gebruiken die je kunt imbue'n op een iostream. Zo'n codecvt converteert dan bij het schrijven naar de stream van code X naar code Y, en van code Y naar code X bij het lezen.
Als bv je disk representatie UTF8 is, en je wilt in memory UCS2 gebruiken, dan kun je een codecvt gebruiken die UTF8 omzet naar UCS2. Bij de Arabica XML library (http://www.jezuk.co.uk/cgi-bin/view/arabica) zitten wat codecvt's die je zo kunt gebruiken (utf8-ucs2, utf16be-ucs2, utf16le-ucs2). Ik kan geen garantie geven over de correctheid van deze codecvt's, maar zelf gebruik ik de utf8-ucs2 codecvt van deze lib, en ik ben nog geen problemen tegengekomen met de conversie. Je zou evt eens kunnen kijken of boost geen nette, complete set codecvt's heeft.

Hiermee los je echter maar een deel van het probleem op; het detecteren welk type unicode de file heeft wordt namelijk niet gedaan. Ik weet ook niet of hier standaard oplossingen voor zijn anders dan wat bytes inlezen en kijken naar een eventuele bom, 2 byte chars etc.

Compressie zou je evt met boost iostreams kunnen doen, deze bevat zlib compressie/decompressie die erg net te gebruiken is met standaard streams.

btw: "goede" unicode bestaat volgens mij niet iedere representatie heeft z'n eigen voor en nadelen. UCS2 is bv makkelijk als in memory representatie (ieder char heeft een vaste grootte), terwijl UTF8 weer handig is voor disk based dingen (lekker compact).

[The End]

In de standaard libraries zitten verschillende functies voor conversies:
wcstombs en mbstowcs bijvoorbeeld.

Hoe er gedecteerd wordt op wat voor een manier een bestand is ge encode weet ik niet, maar zelfs Notepad is in staat om dat te doen.

[madwizard]

Voor het verschil UTF-8 en Unicode: zie What is UTF-8, waar een lijstje met eigenschappen van UTF-8 staan die je kunt gebruiken om het onderscheid te maken. Zo komen de bytes 0xFE en 0xFF nooit voor in een UTF-8 bestand. De NULL byte (0x00) kan wel voorkomen als karakter, zodat het ook echt 0x00 betekent, maar nooit als deel van een gecodeerd speciaal karakter. Unicode zit meestal vol met 0x00 omdat elk normaal karakter zo'n byte erbij krijgt. UTF-8 kan dus wel een 0x00 bevatten maar alleen als dit ook echt in de tekst bedoeld is als 0x00 karakter, wat in de praktijk nagenoeg nooit voorkomt. Het onderscheid ASCII en UTF-8 is wat lastiger, omdat UTF-8 natuurlijk zo gemaakt is dat het als ASCII string opgeslagen kan worden (gewone karakters blijven zo, geen null bytes in encoding). Onder de link die ik net gaf staat wel de codering van UTF-8, zo valt de eerste byte van een gecodeerd karakter binnen 0xC0 en 0xFD, en de daarop volgende bytes binnen 0x80 en 0xBF. Een ASCII bestand met speciale tekens kan ook andere byte combinaties bevatten, als dat voorkomt heb je ASCII en geen UTF-8.
En als alle karakters onder de 0x80 zijn maakt het niet uit of je het als UTF-8 of ASCII leest, het stelt dezelfde tekst voor.