API Windows: ANSI et chaînes de caractères larges-est-ce UTF8 ou ASCII? UTF-16 ou UCS-2 LE?

Sont-ils avant tout corrects?

Oui, si vous ne supposez pas l'existence de caractères non codés en Unicode (pour la plupart des applications pratiques, cette hypothèse est correcte).

Les fonctions Windows " A " (comme SetWindowTextA) prennent-elles des chaînes ASCII? Ou " chaînes multi-octets "(plus de questions à ce sujet ci-dessous)?

Ils prennent des chaînes d'octets (c'est-à-dire des chaînes dont l'Unité de code est un octet, qui est toujours un octet sous Windows) codées dans le courant "ANSI" /MBCS / encodage hérité. "ANSI" est les Termes historiques pour ces encodages, mais pas correct. Pour les systèmes Windows occidentaux, cet encodage est généralement Windows-1252.

Les fonctions Windows "W" prennent-elles des chaînes UTF-16 ou des chaînes UCS-2? Je pensais qu'ils prenaient en UCS-2, mais les noms me confondent.

Depuis Windows 2000, la plupart d'entre eux prennent en charge UTF-16. Le nom "wide" et le reste de la terminologie Microsoft (par exemple, "Unicode" signifiant "UTF-16" ou "UCS") ont été choisis avant la norme Unicode moderne a unifié la terminologie.

Dans WideCharToMultiByte, Microsoft utilise le mot "chaîne de caractères larges" pour signifier UTF-16. Dans ce contexte, qu'est-ce qui est considéré comme une "chaîne multi-octets"? UTF-8?

Tous les autres encodages pris en charge par WideCharToMultiByte sont un "encodage multi-octets" dans ce contexte, y compris Windows-1251 et UTF-8.

LPWSTR est-il une "chaîne de caractères larges"? Je dirais que c'est le cas, mais alors, cela ne voudrait-il pas dire que C'est UTF-16? Et ne le ferait pas cela signifie qu'il pourrait être utilisé pour afficher, disons, des caractères de 4 octets? Si non, alors... affiche de 4 octets caractères impossible? (Windows ne semble pas avoir D'API pour ceux-ci.)

LPWSTR est un pointeur vers wchar_t, qui est toujours un entier non signé 16 bits sur Windows. Les caractères qui peuvent être affichés ne sont pas liés à l'encodage tant que cet encodage peut encoder tous les caractères Unicode. Windows est généralement capable d'Afficher des caractères non-BMP, mais pas partout (par exemple, la console ne peut pas).

La fonctionnalité de WideCharToMultiByte est-elle un surensemble de celle de wcstombs, et travaillent-elles toutes les deux sur le même type de chaîne? Ou est-ce que l'un, disons, fonctionne sur UTF-16 tandis que l'autre fonctionne sur UCS-2?

Ne sais pas vraiment, mais je ne pense pas qu'ils diffèrent trop. Je suppose que vous essayez juste de convertir un caractère non-BMP en UTF-8 et de regarder si le résultat est correct.

Les chemins de fichiers sont-ils en UTF-16 ou UCS-2? Je sais que Windows le traite comme un " opaque tableau de caractères " de la documentation de Microsoft, mais selon la norme C pour des fonctions comme fwprintf, y a-t-il un encodage standardisé?

Les chemins de fichiers sont en effet des tableaux opaques de caractères UTF-16, ce qui signifie que Windows n'effectue aucune traduction lors du stockage ou de la lecture de noms de fichiers (comme Linux et contrairement à Mac OS X). Mais Windows a toujours son étrange comportement insensible à la casse, qui cause beaucoup de problèmes car les noms de fichiers traités de manière équivalente ne sont pas nécessairement égaux. Cela casse de nombreux invariants; par exemple, sous Linux sans interférence des autres threads, si vous créez avec succès deux fichiers A et a dans un répertoire, vous vous retrouverez avec deux fichiers distincts, tandis que sous Windows vous n'obtenez qu'un seul fichier (et en général, un nombre imprévisible de fichiers).

Qu'est-ce que le codage" ANSI"? Est-ce même un terme correct? Et comment cela se rapporte-t-il à ASCII?

ANSI est l'organisation américaine de normalisation. L'utilisation de ce mot en se référant à des encodages est un terme impropre, mais fréquent, vous devez donc en être conscient. Je préfère le terme legacy 8-bit encoding , parce que je pense que c'est essentiellement ce que c'est: un encodage non Unicode qui est conservé uniquement pour la compatibilité avec les applications héritées (Windows 9x). Sur les systèmes occidentaux, il S'agit généralement de Windows-1252, qui est un sur-ensemble approprié D'ASCII.