2009-02-15 6 views
1

En utilisant la dernière version du compilateur Microsoft (inclus avec le SDK Win7), j'essaie de compiler un fichier source codé en UTF-8 avec des séparateurs de ligne Unicode.Compilation de la source codée UTF-8 avec des séparateurs de ligne Unicode

Malheureusement, le code ne sera pas compilé - même si j'inclue la signature UTF-8 au début du fichier. Par exemple, si je tente de compiler ceci:

#include <stdio.h> 

int main (void) 
{ 
    printf("Hello!"); 
    return 0; 
} 

Je vais voir l'erreur suivante:


rapide> cl test.c

Microsoft (R) 32 bits C/C++ Optimisation du compilateur Version 15.00.30729.01 pour 80 x 86 Copyright (C) Microsoft Corporation. Tous les droits sont réservés.

test.c test.c (1): avertissement C4067: jetons inattendus suivant la directive de préprocesseur - attend une nouvelle ligne Microsoft (R) Version incrémentale Linker 9.00.30729.01 Copyright (C) Microsoft Corporation. Tous les droits sont réservés.

/out:test.exe test.obj LINK: LNK1561 d'erreur fatale: point d'entrée doit être définie


Quelqu'un at-il rencontré ce problème avant? Des solutions?

Merci! Andrew

Répondre

2

Quand vous parlez de "séparateurs de ligne unicode", voulez-vous dire UTF-16/UCS-2 (c'est-à-dire des caractères de 16 bits)? Si c'est le cas (le fichier est un mélange d'encodages différents), je dirais que la seule solution raisonnable est de réparer les fichiers. Si vous voulez dire que les fins de ligne sont un autre point de code Unicode (toujours codé en UTF-8), vous devrez toujours corriger les fichiers. La norme dit ceci au sujet de la première phase de la traduction:

Physical source file characters are mapped, in an implementation-defined manner, to the basic source character set (introducing newline characters for end-of-line indicators) if necessary.

Apparemment, MS ne fonctionne pas cette traduction pour les « séparateurs de ligne unicode », de sorte que vous aurez besoin.

+0

En utilisant la boîte de dialogue "Options d'enregistrement avancées" de Visual Studio, je spécifie un codage UTF-8 utilisant des séparateurs de ligne Unicode. Le séparateur de ligne est codé comme UTF-8 comme il se doit. J'ai utilisé un éditeur hexadécimal pour vérifier que la nouvelle valeur de ligne est '0xE2 0x80 0xA8', qui est en effet utf8. –

+0

Mais VS ne cherche pas 0xE2 0x80 0xA8. Il veut 0x0d 0x0a. Ce n'est pas grave si vous êtes moralement dans le droit, il veut que 0x0a, qui est toujours parfaitement utf8 valuid de toute façon. –

+0

Intéressant. C'est une option que je n'ai jamais utilisée. Malheureusement, il semble que MSVC ne supporte pas les fichiers source dans ce format, même si l'éditeur le fait (je suppose que vous voudrez peut-être que vos programmes puissent traiter de tels fichiers de données). Juste curieux - savez-vous si un autre compilateur (GCC?) Le fait? –

0

Cela semble assez évident pour moi, il doit y avoir un retour à la ligne après #include.

Les nouvelles lignes sont toujours unicode, il ne devrait donc pas être si important d'en ajouter un.

+1

Eh bien, les fenêtres encode une nouvelle ligne comme CRLF, où Unix les code comme LF. La définition Unicode tente de corriger ces nouvelles implémentations de lignes conflictuelles en définissant une "nouvelle ligne Unicode". Peut être lu ici: http://en.wikipedia.org/wiki/Unicode#New_lines –

2

Faites-vous référence à this character, par opposition aux caractères CR LF traditionnels.

Je suppose que le compilateur attend une combinaison de CR et LF seulement.

+0

Oui, c'est le personnage dont je parle. J'espérais vraiment que cela serait supporté par le MS Compiler. C'est étrange, puisque Visual Studio offre la possibilité d'enregistrer le fichier en utilisant cet encodage mais ne peut pas le compiler. –

+0

Ne pas oublier que l'éditeur est indépendant du compilateur, et il est destiné à être utile pour les fichiers autres que les fichiers source. Pourtant, je peux comprendre pourquoi on pourrait vouloir ou s'attendre à ce que le compilateur supporte ces fins de ligne. Ce n'est pas une attente déraisonnable - mais je ne suis pas surpris que ce ne soit pas le cas. –

+0

Les différentes fins de ligne ne sont pas un "codage différent". C'est en fait un * caractère différent *. –

2

Envoyé un rapport de bogue à Microsoft avec l'ID 414985. Meh. Nous verrons ce qu'il en adviendra.

Questions connexes