Unicode w systemie Microsoft Windows

Microsoft był jedną z pierwszych firm, które zaimplementowały Unicode w swoich produktach. Windows NT był pierwszym systemem operacyjnym, który używał „szerokich znaków” w wywołaniach systemowych . Korzystając początkowo z (obecnie przestarzałego) schematu kodowania UCS-2 , został on uaktualniony do kodowania o zmiennej szerokości UTF-16, począwszy od systemu Windows 2000 , umożliwiając reprezentację dodatkowych płaszczyzn z parami zastępczymi. Jednak Microsoft nie obsługiwał UTF-8 w swoim interfejsie API do maja 2019 r.

Przed 2019 rokiem Microsoft kładł nacisk na UTF-16 (tj. -W API), ale od tego czasu zaleca używanie UTF-8 (przynajmniej w niektórych przypadkach) w systemach Windows i Xbox (oraz w innych swoich produktach), stwierdza nawet „UTF- 8 to uniwersalna strona kodowa do internacjonalizacji [i] UTF-16 [...] wyjątkowe obciążenie, jakie system Windows nakłada na kod przeznaczony dla wielu platform. […] obciążenie [powodujące] mniej problemów z internacjonalizacją w aplikacjach i grach”.

W dużej ilości dokumentacji firmy Microsoft słowo „Unicode” odnosi się bezpośrednio do kodowania UTF-16. Wszystko inne, w tym UTF-8, nie jest „Unicode” w przestarzałym języku Microsoftu (podczas gdy UTF-8 i UTF-16 są Unicode zgodnie ze standardem Unicode lub kodowaniem/„formatami transformacji”).

W różnych rodzinach Windows

Systemy oparte na Windows NT

Bieżące wersje systemu Windows i wszystkie z powrotem do systemu Windows XP i wcześniejszego systemu Windows NT (3.x, 4.0) są dostarczane z bibliotekami systemowymi obsługującymi kodowanie ciągów dwóch typów: 16-bitowy „Unicode” ( UTF-16 od Windows 2000 ) i ( czasami wielobajtowe) kodowanie zwane „ stroną kodową ” (lub błędnie określane jako strona kodowa ANSI ). Funkcje 16-bitowe mają nazwy z przyrostkiem „W” (od „wide” ), takie jak SetWindowTextW . Funkcje zorientowane na stronę kodową używają sufiksu "A" dla "ANSI", takiego jak SetWindowTextA (niektóre inne konwencje były używane dla interfejsów API, które zostały skopiowane z innych systemów, takich jak _wfopen/fopen lub wcslen/strlen ). Ten podział był konieczny, ponieważ wiele języków, w tym C , nie zapewniało czystego sposobu przekazywania zarówno 8-bitowych, jak i 16-bitowych łańcuchów do tej samej funkcji.

Microsoft próbował „przenośnie” obsługiwać Unicode, dostarczając przełącznik „UNICODE” do kompilatora, który przełącza wywołania „ogólne” bez sufiksów z interfejsu „A” na interfejs „W” i konwertuje wszystkie stałe łańcuchowe na „szerokie” wersje UTF-16 . W rzeczywistości to nie działa, ponieważ nie tłumaczy UTF-8 poza stałymi łańcuchowymi, co powoduje, że kod, który próbuje otworzyć pliki, po prostu się nie kompiluje.

Wcześniej i niezależnie od przełącznika „UNICODE”, system Windows udostępniał również przełącznik interfejsu API zestawów znaków wielobajtowych (MBCS). Zmienia to niektóre funkcje, które nie działają w MBCS, takie jak strrev , na funkcje obsługujące MBCS, takie jak _mbsrev .

WindowsCE

W (obecnie wycofanym) systemie Windows CE UTF-16 był używany prawie wyłącznie, przy czym w większości brakowało interfejsu API „A”. W systemie Windows CE 5.0 dostępny jest ograniczony zestaw interfejsów API ANSI do użytku w ograniczonym zestawie ustawień regionalnych, które mogą być selektywnie wbudowane w obraz środowiska wykonawczego.

Windowsa 9x

Główny artykuł: Microsoft Layer dla Unicode

W 2001 roku Microsoft wydał specjalny dodatek do starych systemów Microsoft Windows 9x . Zawiera bibliotekę dołączaną dynamicznie „unicows.dll” (tylko 240 KB) zawierającą 16-bitowy smak (te z literą W na końcu) wszystkich podstawowych funkcji Windows API. Jest to jedynie warstwa tłumaczenia: SetWindowTextW po prostu przekonwertuje swoje dane wejściowe przy użyciu bieżącej strony kodowej i wywoła SetWindowTextA .

UTF-8

Microsoft Windows ( Windows XP i nowsze) ma stronę kodową wyznaczoną dla UTF-8 , stronę kodową 65001 lub CP_UTF8 . Przez długi czas niemożliwe było ustawienie strony kodowej ustawień regionalnych na 65001, pozostawiając tę ​​stronę kodową dostępną tylko dla (a) wyraźnych funkcji konwersji, takich jak MultiByteToWideChar i/lub (b) polecenia konsoli Win32 chcp 65001 do tłumaczenia stdin / out między UTF-8 a UTF-16. Oznaczało to, że „wąskie” funkcje, w szczególności fopen (który otwiera pliki), nie można go było wywołać z ciągami znaków UTF-8 i tak naprawdę nie było sposobu na otwarcie wszystkich możliwych plików przy użyciu fopen bez względu na ustawienia regionalne i/lub jakie bajty zostały umieszczone w łańcuchu, ponieważ żadne z dostępnych ustawień regionalnych nie mogło wygenerować wszystkich możliwych znaków UTF-16. Ten problem dotyczył również wszystkich innych interfejsów API, które pobierają lub zwracają ciągi 8-bitowe, w tym interfejsów systemu Windows, takich jak SetWindowText .

Programy, które chciały używać UTF-8, w szczególności kod przeznaczony do przenoszenia na inne systemy operacyjne, potrzebowały obejścia tego problemu. Zwykłym obejściem było dodanie nowych funkcji do otwartych plików, które konwertują UTF-8 na UTF-16 przy użyciu MultiByteToWideChar i wywołują funkcję „wide” zamiast fopen . Dziesiątki wieloplatformowych bibliotek dodały funkcje opakowujące, aby wykonać tę konwersję w systemie Windows (i przekazać UTF-8 bez zmian w innych), przykładem jest proponowany dodatek do Boost , Boost.Nowide . Innym popularnym obejściem było przekonwertowanie nazwy na 8.3 odpowiednik nazwy pliku, jest to konieczne, jeśli fopen znajduje się w bibliotece. Żadnego z tych obejść nie uważa się za dobre, ponieważ wymagają one zmian w kodzie, który działa w systemach innych niż Windows.

W kwietniu 2018 r. (Lub prawdopodobnie w listopadzie 2017 r.), W przypadku kompilacji poufnych informacji poufnych 17035 (kompilacja nominalna 17134) dla systemu Windows 10, pojawiło się pole wyboru „Beta: Użyj Unicode UTF-8 do obsługi języków na całym świecie”, aby ustawić stronę kodową ustawień regionalnych na UTF-8. Pozwala to na wywoływanie „wąskich” funkcji, w tym fopen i SetWindowTextA , z łańcuchami UTF-8. Jest to jednak ustawienie ogólnosystemowe i program nie może zakładać, że jest ustawione.

W maju 2019 r. Microsoft dodał możliwość ustawienia przez program strony kodowej na UTF-8, umożliwiając uruchamianie programów napisanych w formacie UTF-8 przez użytkowników niebędących ekspertami.

Od 2019 roku Microsoft zaleca programistom używanie UTF-8 (np. Zamiast jakiegokolwiek innego kodowania 8-bitowego) w systemach Windows i Xbox i może zalecać jego użycie zamiast UTF-16, nawet stwierdzając, że „UTF-8 to uniwersalny kod strona do internacjonalizacji [i] UTF-16 [..] to wyjątkowe obciążenie, jakie system Windows nakłada na kod przeznaczony dla wielu platform”. Wygląda na to, że Microsoft przechodzi na UTF-8, twierdząc, że wcześniej podkreślał swoją alternatywę, oraz w systemie Windows 11 niektóre pliki systemowe muszą używać kodowania UTF-8 i nie wymagają znacznika kolejności bajtów. Notatnik może teraz rozpoznawać kodowanie UTF-8 bez znacznika kolejności bajtów i można mu nakazać zapisywanie UTF-8 bez znacznika kolejności bajtów. Niektóre inne produkty Microsoft używają wewnętrznie UTF-8, w tym Visual Studio i ich SQL Server 2019 , przy czym Microsoft twierdzi, że 35% wzrost prędkości dzięki użyciu UTF-8 i „prawie 50% redukcja pamięci wymagania."

Platformy programistyczne

Kompilatory firmy Microsoft często zawodzą przy tworzeniu stałych ciągów UTF-8 z plików źródłowych UTF-8. Najbardziej niezawodną metodą jest wyłączenie UNICODE , nie oznaczanie pliku wejściowego jako UTF-8 (tj. nie używanie BOM ) i ustawienie stałych łańcuchowych tak, aby miały bajty UTF-8. Jeśli dodano BOM, kompilator firmy Microsoft zinterpretuje ciągi jako UTF-8, przekonwertuje je na UTF-16, a następnie przekonwertuje z powrotem do bieżącej lokalizacji, niszcząc w ten sposób UTF-8. Bez BOM i przy użyciu jednobajtowych ustawień narodowych kompilatory firmy Microsoft pozostawią niezmienione bajty w cudzysłowie. W nowoczesnych systemach ustawienie strony kodowej na UTF-8 znacznie pomaga, ale nieprawidłowe sekwencje bajtów nadal nie są zachowywane (przy użyciu \x można to obejść).

Zobacz też

• Bush ukrył fakty , tekst kodujący mojibake

Linki zewnętrzne

• „Unicode” . MSDN . Microsoftu . Źródło 10 listopada 2016 r .