Windows 7 UTF-8 i Unicode

14

Czy ktoś mógłby wyjaśnić, co zmieniło się w systemie Windows 7 (Pro 64-bit)?

Szczegóły: Wcześniej miałem Windows XP i miałem kilka plików tłumaczeń (zakodowanych w UTF-8) w formacie CSV. Byłem w stanie wyświetlić czcionki zarówno w Notatniku, jak i Excelu. Po uaktualnieniu do systemu Windows 7, kiedy otwieram te pliki - widzę tylko kwadratowe pudełka (tylko wiesz, jeśli otworzę je w przeglądarce - byłem w stanie zobaczyć całe tłumaczenie). Jeśli zapiszę te pliki w Unicode, wszystko wydaje się w porządku.

Co się właściwie dzieje? Dlaczego system Windows 7 działa z Unicode, a nie z UTF-8?

Sha Le
źródło

Odpowiedzi:

30

Dlaczego system Windows 7 działa z Unicode, a nie z UTF-8?

Terminologia

Unicode i UTF-8 to nie to samo: Unicode to zestaw znaków, który definiuje zestaw znaków (repertuar) i przypisuje liczby (punkty kodowe) każdemu z tych znaków. UTF ‑ 8 jest jednym z kilku kodowań, które mogą być używane do reprezentowania strumienia znaków Unicode na dysku lub w transmisji. Ten sam strumień znaków Unicode można również zakodować na przykład jako UTF ‑ 16, UTF ‑ 32 lub UTF ‑ 7.

Jednak oferty Notatnika „kodowania” Opcje tym ANSI, Unicode, Unicode big-endiani UTF-8. Programiści Microsoft, którzy to napisali, użyli złych terminów. Kiedy mówią „Unicode”, najprawdopodobniej mają na myśli „ UTF-16 little-endian ”. Kiedy mówią „ANSI”, mają na myśli Kod Strony 1252 (CP-1252).

Microsoft Notepad

Wierzę, że Notatnik Microsoft zapisuje UTF-16 ze znakiem kolejności bajtów ( BOM ) i że Notatnik szuka BOM podczas czytania pliku tekstowego. LM informuje aplikację, że plik to UTF-16 i wskazuje, czy jest to big-endian czy little-endian.

Jeśli Notatnik nie znajdzie BOM, wywołuje funkcję biblioteki IsTextUnicode, która sprawdza dane i próbuje zgadnąć, jakie kodowanie zostało użyte. Czasami (nieuchronnie) zgaduje niepoprawnie. Czasami zgaduje, że plik „ANSI” to „Unicode”. Próba interpretacji pliku UTF-16 lub UTF-8 jako kodu strony 1252 spowodowałaby, że wyświetlałby on niewłaściwe glify i nie byłby w stanie znaleźć glifów wyświetlających niektóre wartości 8-bitowe - byłyby wówczas pokazane jako kwadraty.

Jak mówi harrymc w swojej odpowiedzi , istnieją lepsze alternatywy dla Notatnika. Ale Notatnik pozwala jawnie wybrać kodowanie podczas otwierania pliku (zamiast pozostawiać Notatnika, aby zgadnąć).

Bajtowe znaki porządkowe

Według konsorcjum Unicode znaki bajtowe (BOM) są opcjonalne. Jednak system Windows wykorzystuje BOM do rozróżnienia niektórych kodowań.

Krótko mówiąc, może twoje pliki nie miały BOM z jakiegoś powodu? Może BOM został utracony podczas procesu aktualizacji?

Jeśli nadal masz oryginalne pliki wyświetlane jako kwadraty, możesz zrobić ich zrzut heksadecymalny, aby sprawdzić, czy zawierają one BOM.


Zwykłe standardy plików tekstowych

Problem polega na tym, że nie ma żadnego - nie ma uniwersalnych standardów dla zwykłych plików tekstowych. Zamiast tego mamy wiele niekompatybilnych i nieznanych.

  • Jak zostały oznaczone zakończenia linii? Niektóre platformy używają znaków kontrolnych Carriage Return (CR), a następnie Line Feed (LF), niektóre używają tylko CR, a niektóre same LF.

  • Czy powyższe terminatory lub separatory? Ma to wpływ na koniec pliku i wiadomo, że powoduje problemy.

  • Traktowanie tabulatorów i innych znaków kontrolnych. Możemy założyć, że tabulator służy do wyrównania do wielokrotności 8 standardowych szerokości znaków od początku linii, ale tak naprawdę nie ma co do tego pewności. Wiele programów pozwala na zmianę pozycji tabulatorów.

  • Zestaw znaków i kodowanie? Nie ma uniwersalnego standardu określającego, które z nich zostały użyte dla tekstu w pliku. Najbliższe mamy poszukać BOM, który wskazuje, że kodowanie jest jednym z tych używanych w Unicode. Od wartości BOM program odczytujący plik może odróżnić UTF-8 i UTF-16 itp., A także warianty UTF-16 Little-Endian i Big-Endian itp. Nie ma uniwersalnego standardu wskazującego, że plik jest zakodowany w dowolnym innym popularnym kodowaniu, takim jak CP-1252 lub KOI-8.

I tak dalej. Żadna z powyższych metadanych nie jest zapisana w pliku tekstowym - więc użytkownik końcowy musi poinformować program podczas czytania pliku. Użytkownik końcowy musi znać wartości metadanych dla dowolnego określonego pliku lub ryzykować, że jego program użyje niewłaściwych wartości metadanych.

Bush ukrył fakty

Wypróbuj to w systemie Windows XP.

  • Otwórz Notatnik.
  • Ustaw czcionkę na Arial Unicode MS. (Być może trzeba go najpierw zainstalować; jeśli nie widzisz go w menu, kliknij „Pokaż więcej czcionek”).
  • Wpisz tekst „Bush ukrył fakty”.
  • Wybierz Save As. Z Encodingmenu wybierz ANSI.
  • Zamknij Notatnik.
  • Ponownie otwórz dokument (np. Za pomocą Start, My Recent Documents).
  • Zamiast „Bush ukrył fakty” zobaczysz 畂 桳 栠 摩 琠 敨 映 捡 獴.

To pokazuje, że IsTextUnicodefunkcja używana przez Notatnik niepoprawnie zgaduje, że tekst ANSI (naprawdę Code Page 1252) to Unicode UTF-16LE bez BOM. W pliku zapisanym jako nie ma BOM ANSI.

System Windows 7

W systemie Windows 7 Microsoft dostosował się IsTextUnicodetak, aby powyższe nie miało miejsca. W przypadku braku BOM, bardziej prawdopodobne jest odgadnięcie ANSI (CP 1252) niż Unicode (UTF-16LE). W systemie Windows-7 spodziewam się, że problem odwrotności jest większy : plik zawierający znaki Unicode o punktach kodowych większych niż 255, ale bez BOM, jest bardziej prawdopodobne, że zostanie odgadnięty jako ANSI - i dlatego jest wyświetlany niepoprawnie.

Zapobieganie problemom z kodowaniem

Obecnie najlepszym podejściem wydaje się być używanie UTF-8 wszędzie. Idealnie byłoby ponownie zakodować wszystkie stare pliki tekstowe do UTF-8 i zapisywać tylko pliki tekstowe jako UTF-8. Istnieją narzędzia, takie jak przekoduj i iconv, które mogą w tym pomóc.

RedGrittyBrick
źródło
3
Według Wikipedii : w systemie Windows Vista i Windows 7 [..] IsTextUnicode został zmieniony, aby znacznie bardziej prawdopodobne było odgadnięcie kodowania bajtowego niż UTF-16LE.
Arjan
Tak, na pewno my te pliki mamy BOM, ponieważ generujemy je za pomocą BOM. Interesujące jest to, że Windows 7 nie odczytuje BOM utworzonych przez starszy system operacyjny.
Sha Le,
LM nie uległo zmianie. Możliwe, że w twoich plikach brakuje BOM, ale wcześniej domyślnym formatem był wariant Unicode, w którym jest teraz ASCII. Zobacz moją odpowiedź.
harrymc
@Sha Le: Jeśli plik ma BOM, Notatnik Windows 7 powinien otworzyć go poprawnie, więc opisany problem nie pasuje do znanych problemów isTextUnicode. Czy możesz utworzyć mały przykładowy plik, który ilustruje problem z plikiem zawierającym BOM?
RedGrittyBrick,
Istnieje również this app can breakten sam efekt, coBush hid the facts
Regent
3

Uwaga: Za pomocą Notepad ++ można przeglądać tezy przy użyciu menu Kodowanie.

Po prawidłowym wyświetleniu plików ich zapisanie spowoduje dodanie prawidłowego zestawienia komponentów.

harrymc
źródło
Wiem, że ten post jest trochę stary, ale obecnie mam problem z Win 7 i Notatnikiem ++, które nie wyświetlają UTF 8 bez BOM, gdy pliki zostały początkowo utworzone za pomocą samego notatnika ++ v5.9.6.2.
Jake
@Jake: Upewnij się, że menu Kodowanie wyświetla „Zakoduj w UTF8”, a nie „Zakoduj w UTF8 bez BOM”.
harrymc
1

W Windows 10 jest możliwy (test na kompilacji 1903)

  1. Skopiuj plik z dobrym kodowaniem TXTUTF-8.txtdo C:\WINDOWS\SHELLNEW.
  2. W HKEY_CLASSES_ROOT\.txt\ShellNewzłożyć nowy łańcuch z nazwą „ FileName
  3. Zmień wartość „ FileName” na „ TXTUTF-8.txt

Teraz, gdy utworzysz nowy plik txt za pomocą menu Windows, zajmie on twój TXTUTF-8.txtszablon

Źródło: https://answers.microsoft.com/fr-fr/windows/forum/all/configurer-lencodage-par-d%C3%A9faut-en-utf-8-dans/9c0358ca-a2b3-43e8-a154- d10c1fe94317

e2dy Dev
źródło