Windows - Hvorfor er ANSI Code-Page og Console Code-Page anderledes?

Indlæg af Hanne Mølgaard Plasc

Problem



Microsoft Windows giver flere funktioner til at søge den aktuelle kode-side:
GetACP, GetConsoleOutputCP, GetConsoleCP. [22] [23] [24]


De returnerer forskellige værdier. For eksempel returnerer GetACP på min maskine 1252 mens GetConsoleOutputCP og GetConsoleCP returnerer 437.


(Vi kan også køre chcp på kommandolinjen og få 437)



  • Hvorfor leverer Windows forskellige kode sider til konsol og ikke-konsol?

  • Hvordan bestemmes disse kode sider pr. maskine?

  • Hvad er forholdet mellem kode sider på samme maskine? Er der en sammenhæng mellem konsol- og ikke-konsolkodesiderne? Vil maskiner med codepage 1252 altid have en konsol codepage på 437?



Baggrunden for dette spørgsmål er en fejlmeddelelse fra Visual Studio C ++:


error C2855: command-line option '/source-charset' inconsistent with precompiled header
error C2855: command-line option '/execution-charset' inconsistent with precompiled header


Disse fejl opstod, da den forkompilerede hovedfil blev bygget med en anden standardkode-side end CPP-filen, der brugte dem (uanset årsagen).

Fra MSDN-dokumenterne: [25]



  Hvis der ikke findes et byte-ordmærke, antages det, at kildefilen er kodet
  bruger den aktuelle brugerkodeside, medmindre du angiver et tegnsæt
  navn eller kode side ved hjælp af/source-charset indstillingen.



Så jeg forsøger at finde ud af, hvilken kodeside de refererer til, den, der returneres af GetACP eller de andre ...

Bedste reference


ANSI- og OEM-kodepladerne bestemmes af den systemplacering, der er indlæst, når systemet starter. De bliver kortlagt i hver proces som PEB-felterne AnsiCodePageData og OemCodePageData. Rulerbiblioteket i ntdll.dll har mange funktioner, der arbejder med disse strengtyper, fx RtlAnsiStringToUnicodeString og RtlOemStringToUnicodeString.


Funktioner, der slutter med A i Windows API, er ANSI, undtagen filsystemfunktioner kan skiftes til OEM via SetFileApisToOEM. Konsol API'en er standard til OEM for kompatibilitet med gamle applikationer og kan ændres til en anden kodeks via SetConsoleCP og SetConsoleOutputCP. chcp.com (eller mode.com) kalder disse funktioner, men det tillader ikke at indstille inputbufferen og skærmbufferen til forskellige kodeord.


Hvis ANSI-kodesiden er 1252, er OEM-kodesiden ikke nødvendigvis 437. Det er kun i den amerikanske lokalitet. De fleste vestlige lokaliteter, der bruger 1252 som ANSI-kodeksen, bruger 850 som OEM-kodeksen.


En applikation, der siger, at den bruger brugerkodesiden, henviser muligvis ikke til systemets ANSI- eller OEM-kodeks. I stedet kan det være at ringe til GetLocaleInfoEx for at søge efter LOCALE\_NAME\_USER\_DEFAULT locale for LOCALE\_IDEFAULTANSICODEPAGE eller LOCALE\_IDEFAULTCODEPAGE.

Andre referencer 1


Kommandokonsollen bruger en anden kodeside af gamle årsager. Programmerne, der kører på konsollen, blev ofte skrevet til DOS, og tegnsættet indeholdt ting som linjetegningskarakterer, der ville være nyttige i denne sammenhæng. I et grafisk miljø med indbyggede Windows-apps var det mere vigtigt at udvide de tilgængelige tegn, da linjerne ville blive tegnet direkte i stedet for at blive simuleret i skrifttyper.


Standard kode sider bestemmes af det sprog, Windows bruger. Forskellige sprog kræver forskellige tegn, og en enkelt kode side var ikke nok til at passe til alle de tegn, der anvendes af europæiske sprog. Du finder kodeks 1250, der bruges på nogle central- og østeuropæiske steder. [26]

Andre referencer 2



  Hvordan bestemmes disse kode sider pr. Maskine?



Se på denne tabel National Language Support (NLS) API Reference [27]


Eller spørg din registreringsdatabase:


C:>reg query HKEY\_LOCAL\_MACHINESYSTEMCurrentControlSetControlNlsCodePage /v OEMCP

HKEY\_LOCAL\_MACHINESYSTEMCurrentControlSetControlNlsCodePage
    OEMCP    REG\_SZ    850


C:>reg query HKEY\_LOCAL\_MACHINESYSTEMCurrentControlSetControlNlsCodePage /v ACP

HKEY\_LOCAL\_MACHINESYSTEMCurrentControlSetControlNlsCodePage
    ACP    REG\_SZ    1252