tegnkodning - UTF-8 på Windows med Ada

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forstår, at Character er som standard Latin\_1, Wide\_Character er UCS-2 og Wide\_Wide\_Character er UCS-4, men GNAT kan have angivet pragma Wide\_Character\_Encoding(UTF8); eller [[-gnatW8 og at disse tegn og deres strenge bliver UTF-8 kodet i stedet.


I hvert fald på Linux og FreeBSD passer resultaterne med mine forventninger. Men i Windows er resultaterne ulige.


For enten Wide eller Wide\_Wide varianter, når et tegn bevæger sig ud over ASCII-sæt, får jeg et forstyrret rod. Jeg tror det hedder emojibake af nogle. Så jeg regnede med, at det var et kodeksproblem. Trods alt er standardkodesiden i Windows, og derfor, hvad konsolværten skal indlæse, 437, som ikke er den UTF-8 kodeside. chcp 65001 og nu i stedet for rodet af ekstra tegn er der en øjeblikkelig undtagelse raised ADA.IO\_EXCEPTIONS.DEVICE\_ERROR : a-ztexio.adb:1295. Når man ser på, hvor undtagelsen opstod, synes den at være i putc bindingen af ​​fputc(). Men dette er Standard\_Output, bør det ikke ske, at en EOF aldrig sker?


Er der nogen form for særlig overvejelse Windows behov? Hvordan kan jeg få UTF-8 output?


rediger :

Jeg forsøgte at pipere udgangen i en tekstfil. Det angivne UTF-8-kodede program genererer stadig emojibake i filen. Ikke sikker på hvorfor dette straks ville kaste en undtagelse i konsollen.


Så så forsøgte jeg direkte at åbne og skrive til en fil i stedet for konsollen/røret. Det er mærkeligt, at det virker præcis som det skal. Teksten er helt korrekt.


Jeg har aldrig set denne form for adfærd med noget andet sprog, så det skal stadig være muligt at få ordentlig UTF-8 på konsollen, ikke?

Bedste reference


Baseret på andre kommentarer og yderligere undersøgelser for at bekræfte, er jeg ganske sikker på, at dette er en mangel på Windows Console Host.


rediger : Lyt ikke til dette

Andre referencer 1


Manglen på så mange andre, ikke kun her, beskriver i Windows Console Hosten er enten blevet rettet eller aldrig eksisteret i første omgang. På baggrund af dette dokument mener jeg, at det sandsynligvis altid var meget misforstået. Windows behandler ikke konsollen som filer, og det er nemt at falde ind i den fælde. [14]


Brug denne meget ligefrem kode, sammen med hvad Windows har brug for og forventer bag kulisserne ...


Indtast billedbeskrivelse her [15]


Det producerer korrekt følgende, så længe enten pragma Wide\_Character\_Encoding(UTF8); eller -gnatW8 anvendes.


Indtast billedbeskrivelse her [16]


Rør udgangen af ​​dette testprogram til en fil fungerer som det skal. På samme måde fungerer piping output af dette testprogram til et andet program som det skal. Og også på samme måde tager filen fra piped output og piping det ind i et andet program, som det skal.


Fuld UTF-8-adfærd som man ville forvente under Linux, på Windows.


Hvad der skal gøres er to gange. I pakke initialisatoren skal Console Host fortælle, hvad den arbejder med, hvilket kan gøres som dette.


Indtast billedbeskrivelse her [17]


Karakterudgangen udføres derefter gennem fputwc. Ifølge MS Docs fputc bør aldrig bruges til UNICODE på Windows, hvilket er en del af problemet GNAT har. String output og character/string input er alle ens. [18]


Indtast billedbeskrivelse her [19]