2009-11-02 14 views
12

Chcę utworzyć kilka przykładowych programów, które zajmują się kodowaniem, a konkretnie chcę używać szerokie ciągi jak:Specyfikacja kodowania źródło charset w MSVC++, jak gcc „-finput-charset = CharSet”

wstring a=L"grüßen"; 
wstring b=L"שלום עולם!"; 
wstring c=L"中文"; 

Ponieważ są to przykładowe programy.

To jest absolutnie banalne z gcc, który traktuje kod źródłowy jako tekst zakodowany w UTF-8. Ale prosta kompilacja nie działa pod MSVC. Wiem, że mogę je kodować używając sekwencji ucieczki, ale wolałbym zachować je jako czytelny tekst.

Czy jest jakaś opcja, którą mogę określić jako przełącznik wiersza poleceń dla "cl", aby sprawić, żeby to działało? Jest jakaś komenda linia przełącznik jak gcc'c -finput-charset

Dzięki,

Jeśli nie, jak proponujesz zrobić tekst naturalne dla użytkownika?

Uwaga: dodawania BOM do pliku UTF-8 nie jest opcją, ponieważ staje się non-compilable przez inne kompilatory.

Uwaga2: muszę go do pracy w MSVC wersja> = 9 == VS 2008

realna odpowiedź: nie ma rozwiązania

+3

To naprawdę zadziwiające MSVC++ nie ma takiej opcji kompilatora. Co za wstyd ... –

+0

Sądzę, że chodziło o * określenie zestawu znaków ** pliku ** podczas zadawania tego pytania. * Zestaw znaków źródłowych * jest terminem w standardzie używanym do implementacji zdefiniowanego zestawu znaków używanych wewnętrznie przez kompilator. –

+1

@PiotrDobrogost Przypuszczam, że Microsoft nie dogonił reszty świata, natywnie wspierając UTF-8 dla kompilacji i SDK, a także dodając tyle nieefektywności, kłopotów, zamieszania i nędzy w życiu programistów, którzy muszą umiędzynarodowić aplikacje Windows w świecie UTF-8. Ale zgaduję; nazywa się * biurokracją * i * motywem zysku * nad opieką lub troską o jakość. –

Odpowiedz

7

Dla tych, którzy podpisują się pod hasłem "lepiej późno niż nigdy", Visual Studio 2015 (wersja 19 kompilatora) obsługuje teraz to.

Nowy przełącznik wiersza polecenia z numerem /source-charset umożliwia określenie kodowania zestawu znaków używanego do interpretowania plików źródłowych. To trwa jeden parametr, który może być albo IANA lub ISO character set name:

/source-charset:utf-8 

lub identyfikator dziesiętny konkretnej strony kodowej (poprzedzone kropką):

/source-charset:.65001 

Oficjalna dokumentacja to here, a na Blogu zespołu Visual C++ znajduje się również a detailed article describing these new options.

Istnieje również komplementarna /execution-charset switch, która działa dokładnie w ten sam sposób, ale kontroluje, w jaki sposób wąskie znaki literowe i łańcuchowe są generowane w pliku wykonywalnym. Na koniec jest przełącznik skrótów, /utf-8, który ustawia zarówno /source-charset:utf-8 i /execution-charset:utf-8.

Te opcje wiersza polecenia są niezgodne ze starymi #pragma setlocale i #pragma execution-character-set dyrektyw, a one stosowane globalnie do wszystkich plików źródłowych.

Dla użytkowników, którzy utknęli na starszych wersjach kompilatora, najlepszą opcją jest nadal zapisywanie plików źródłowych jako UTF-8 z LM (jak sugerowały inne odpowiedzi, IDE może to zrobić podczas zapisywania). Kompilator automatycznie wykryje to i zachowa się odpowiednio. Tak samo będzie z GCC, który również akceptuje BOM na początku plików źródłowych bez zadławienia się na śmierć, czyniąc to podejście funkcjonalnie przenośnym.

5

Otwórz File->Advances Save Options... Wybierz Unicode(UTF-8 with signature) - Codepage 65001 w kodowaniu kombi. Kompilator automatycznie użyje wybranego kodowania.


Według Microsoft odpowiedź here:

jeśli chcesz znaków spoza ASCII następnie "oficjalnej" i przenośny sposób, aby ich jest użycie \ u (lub \ U) kodowanie szesnastkowe (co jest, zgadzam się, po prostu brzydkie i podatne na błędy).

Kompilator, gdy napotyka plik źródłowy, który nie ma LM, kompilator odczytuje z wyprzedzeniem określoną odległość w pliku, aby sprawdzić, czy potrafi wykryć znaki Unicode - w szczególności szuka UTF-16 i UTF-16BE - jeśli nie znajdzie, wówczas zakłada, że ​​ma MBCS. Podejrzewam, że w tym przypadku wraca on do MBCS i właśnie to powoduje problem.

Bycie wyraźnym jest naprawdę najlepsze i tak, choć wiem, że nie jest to idealne rozwiązanie. Sugerowałbym użycie BOM.

Jonathan Caves
Zespół kompilatorów Visual C++.


Dobrym rozwiązaniem będzie umieszczenie ciągów tekstowych w plikach zasobów. Jest to wygodny i przenośny sposób. Do zarządzania tłumaczeniami można używać bibliotek lokalizacji, takich jak gettext.

+0

Plik jest już zakodowany w UTF-8 – Artyom

+0

Kompilator automatycznie konwertuje stałe ciągów znaków w pliku, więc ciąg będzie przechowywany w EXE przy użyciu kodowania UCS2 w wyniku. –

+0

OK, widzę, że sugeruje się ręczne dodanie znacznika "BOM" do UTF-8 i rzeczywiście działa, ale problem nie działa z gcc i innymi kompilatorami, które nie oczekują bezsensownego BOM. – Artyom

1

dla VS można użyć:

#pragma setlocale("[locale-string]") 

Domyślny kod ANSI strona lokalizacji zostaną wykorzystane jako kodowania pliku.

Ale generalnie nie jest dobrym pomysłem, aby zakodować na sztywno wszystkie widoczne przez użytkownika ciągi znaków w kodzie. Przechowuj je w zasobach. Dobry do lokalizacji, łatwego sprawdzania pisowni i aktualizacji, itp.

+0

"Ale ogólnie rzecz biorąc, nie jest dobrym pomysłem, aby zakodować na sztywno wszystkie widoczne przez użytkownika ciągi znaków w kodzie" Wiem, ale to głównie na przykładach, gdzie takie rzeczy są ważne dla użytkownika, aby zobaczyć, co jest naprawdę dzieje się. Ale jak określić zestaw znaków UTF-8 w ciągu znaków narodowych? O ile mi wiadomo, system Windows nie obsługuje ustawień kodowanych w UTF-8. – Artyom

+0

Po krótkim teście, MSVC 2005 nie akceptuje 'setlocale (" .65001 ")' tj. Strony kodowej UTF-8. – Artyom

+0

65001 jest stroną kodową, pragma przyjmuje ustawienia regionalne. Brak lokalizacji z UTF-8 jako stroną kodową. Jeśli potrzebujesz go tylko do pracy w VS, możesz zapisać go jako UTF-16 (z Notatnika "Zapisz jako" i wybierz kodowanie "Unicode") Jedynym przenośnym sposobem, aby to zrobić inaczej, jest uciec z niego jako - zasugerował Sherwood Hu. Podoba, czy nie, to jedyny sposób. I właściwym sposobem jest, aby nie zakodować w nim twardego pliku c :-) –

2

IMHO wszystkie pliki źródłowe C++ powinny być w ścisłym ASCII. Komentarze mogą być w UTF-8, jeśli edytor je obsługuje.
Umożliwia to przenoszenie kodu między platformami, edytorami i systemami kontroli źródła.

Można użyć \u wstawić znaki Unicode do szerokiej wyrażenie:

std::wstring str = L"\u20AC123,00"; //€123,00 
+5

Rzeczy, których dokładnie ** nie chcę ** – Artyom

2

Przepływ użyliśmy: zapisać pliki jako UTF8-z BOM, podziel się z tego samego źródła między Linux i Windows, Linux: przetwórz pliki źródłowe w komendzie kompilacji w celu usunięcia LM, uruchom g ++ na pośrednim pliku innym niż BOM.

Powiązane problemy