windows - læser en Unicode-fil i C og sender indhold som ASCII via stikkontakter

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har forsøgt at finde ud af dette, men intet synes at fungere. Vi har en ansøgning
der læser tusindvis af transaktionsfiler ved hjælp af den normale 'fopen fgets etc', som vi analyserer ved hjælp af normale C-funktioner 'strstr, strchr, etc' og returnerer en normaliseret char *.


Men nu skal vi læse nogle filer, der findes i Unicode (fra Windows), og jeg har mange problemer. Fra hvad jeg arbejder på, modtager jeg kun en FP (filpeger) uden at vide, om FP peger på en normal ascii-fil eller Unicode, og jeg skal sende tilbage til programmet som char *.


Jeg kan heller ikke køre kommandolinjeværktøjer til manuelt at konvertere hele filen, fordi vi tailing det for nye poster.


Jeg forsøgte at bruge WideCharToMultiByte, mbsrtowcs, men det lader til, at efter at jeg har læst filen ved hjælp af fgets, og videregiver dem, er afkastet altid tomt (0 bytes). Nogen har noget eksempel på hvordan man gør det ordentligt? De online doks/manualer til disse funktioner har alle gode eksempler.


Tak!

Bedste reference


Jeg har ikke det fulde svar, men en del af problemet er at bestemme tegnkodningen. Normalt vil unicode-formatfiler, der oprettes i Windows, starte med et byte-ordmærke (BOM) - unicode-tegnet U + FEFF. Dette kan være bruges til at bestemme, hvad kodningen er, hvis man er fundet. [1]


Hvis du har en streng kodet ved hjælp af say UTF16, vil dette have et hvilket som helst antal indlejrede NULL bytes, du kan ikke bruge de normale ASCII versioner af strengfunktionerne (strlen osv.), Da de vil se NULL bytes som slutningen af ​​snoren markør. Dit standardbibliotek har unicodeaktiverede versioner, som du skal bruge.

Andre referencer 1


Det er et af problemerne med tegnkodninger - enten du skal antage at det er i nogle kodninger, skal du få den information indefra data eller fra metadata, eller du skal registrere det.


På Windows er det almindeligt at bruge byte-ordre mærke i starten af ​​filen, men dette krænker mange praksis og bryder en masse ting - så det er ikke almindeligt i Unix World.


Der er en masse biblioteker dedikeret netop for det - unicode og karakter kodninger. Mest populære er iconv og ICU. [2] [3]

Andre referencer 2


Et par punkter:


Hvis du kan være sikker på, at UNICODE-filerne har et byteordre (BOM), kan du passe på det. Men UNICODE-filer er ikke nødvendige for at have en BOM, så det afhænger af, hvor de kommer fra.


Hvis filen er UNICODE, kan du ikke læse den med fgets () du skal bruge fgetws () eller fread (). UNICODE-tegn kan have nulbyte (bytes med en værdi på nul), som vil forvirre fgets ().


Nul bytes kan være din ven. Hvis du læser i en klump af filen ved hjælp af fread (), og opdager indlejret nul bytes, er det sandsynligt, at du har UNICODE. Men det omvendte er ikke sandt - fraværet af nulbyte viser ikke, at du har ASCII. Engelske bogstaver i UNICODE vil have nul bytes, men mange andre sprog (fx kinesisk) vil ikke.


Hvis du ved, hvilket sprog teksten er i, kan du teste for tegn, der ikke er gyldige på det pågældende sprog - men det er lidt hit og savner.


I ovenstående bruger jeg 'UNICODE' i Windows-vejen - at henvise til UTF16 med Intel byte-bestilling. Men i den virkelige verden kan du få UTF8 eller UTF32, og du kan få ordre fra ikke-Intel byte. (Teoretisk kan du få UTF7, men det er ret sjældent).


Hvis du har kontrol over inputfilerne, kan du insistere på, at de har BOM'er, hvilket gør det nemt.


Hvis du undlader det, hvis du kender sproget i filerne, kan du prøve at gætte kodningen, men det er mindre end 100\% pålideligt. Ellers skal du muligvis spørge operatøren (hvis der er en) for at angive kodningen.