znaki specjalne w treści

Znaki specjalne w treści wymagają kodowania UTF-8, by wyświetlić się prawidłowo u wszystkich odbiorców.

Znaki specjalne a kodowanie znaków w UTF-8

Znaki specjalne w treści to znaki, które nie należą wyłącznie do podstawowego zestawu liter alfabetu łacińskiego. W polskich tekstach należą do nich między innymi ą, ć, ę, ł, ń, ó, ś, ź i ż, a także cudzysłowy typograficzne, półpauzy, symbole walut, znaki matematyczne oraz emoji. Aby taki tekst był odczytywany prawidłowo na różnych komputerach i w różnych programach, dane muszą mieć określone kodowanie znaków. UTF-8 jest kodowaniem Unicode o zmiennej długości: pojedynczy znak zajmuje od jednego do czterech bajtów. Znaki ASCII, takie jak podstawowe litery angielskie, cyfry i część znaków interpunkcyjnych, zajmują jeden bajt, natomiast wiele znaków używanych w języku polskim zajmuje dwa bajty.

Samo zapisanie tekstu w UTF-8 nie wystarcza, jeśli program odbierający dane interpretuje bajty jako inne kodowanie. Wtedy zamiast polskich liter mogą pojawić się ciągi takie jak „ó” zamiast „ó” albo znaki zastępcze wyświetlane jako kwadrat. W dokumencie HTML kodowanie powinno być jednoznacznie zadeklarowane, na przykład przez element <meta charset="UTF-8"> umieszczony w sekcji <head>. Serwer powinien dodatkowo przekazywać nagłówek HTTP Content-Type z parametrem charset=UTF-8, aby przeglądarka nie musiała zgadywać sposobu interpretacji odpowiedzi.

Znaki zarezerwowane w kodzie HTML

Niektóre znaki specjalne mają w HTML znaczenie składniowe i nie mogą być wpisywane w treści bezpośrednio w każdej sytuacji. Znak mniejszości rozpoczyna znacznik, dlatego w zwykłym tekście zapisuje się go jako encję <, a znak większości jako >. Ampersand rozpoczyna encję znakową, więc jego literalną postać zapisuje się jako &. Cudzysłów może wymagać kodowania, gdy występuje w wartości atrybutu ujętej w cudzysłowy; stosuje się wtedy między innymi ". W treści HTML można używać również zapisu numerycznego, na przykład © dla znaku praw autorskich.

Rozróżnienie między tekstem a kodem ma znaczenie także przy generowaniu strony przez aplikację. Dane wprowadzone przez użytkownika nie powinny być składane w HTML przez proste łączenie ciągów znaków. Wartość przeznaczona do wyświetlenia w treści elementu trzeba kodować zgodnie z kontekstem HTML, a wartość przeznaczona do atrybutu musi być bezpiecznie osadzona w tym atrybucie. W aplikacjach korzystających z bibliotek szablonów należy rozumieć, kiedy automatyczne escapowanie jest aktywne, a kiedy zostało wyłączone. Błędne potraktowanie znaków takich jak <, > i & może zmienić strukturę dokumentu, a w nieprawidłowo zabezpieczonym formularzu doprowadzić do wykonania niepożądanego kodu JavaScript.

Przepływ znaków między formularzem, plikiem i bazą danych

Problemy ze znakami specjalnymi często powstają na granicy kilku elementów systemu. Przeglądarka wysyła dane formularza w określonym kodowaniu, serwer odczytuje bajty i tworzy ciąg znaków, a następnie aplikacja może zapisać go w bazie danych, pliku albo przesłać do zewnętrznego interfejsu API. Każdy etap powinien zachować tę samą, jasno określoną interpretację tekstu. W HTML formularza można wskazać accept-charset="UTF-8", natomiast po stronie serwera trzeba prawidłowo odczytać nagłówek lub sposób kodowania żądania. Przy zapisie pliku ważne jest użycie trybu tekstowego z UTF-8 zamiast domyślnego kodowania systemu operacyjnego.

Odrębną kwestią jest kodowanie adresów URL. Znaki takie jak spacja, znak zapytania, ampersand czy polskie litery muszą być przekazane zgodnie z regułami kodowania procentowego, na przykład spacja może zostać przedstawiona jako %20, a znak ą jako odpowiednia sekwencja bajtów UTF-8 zapisana szesnastkowo. Nie należy ręcznie zastępować wszystkich znaków w adresie jedną funkcją bez uwzględnienia tego, czy kodowany jest cały URL, jego ścieżka, parametr zapytania czy fragment. Podobnie przy eksporcie danych do CSV trzeba poprawnie obsłużyć separator, cudzysłowy i znaki końca wiersza, ponieważ treść zawierająca przecinek lub cudzysłów może zostać błędnie podzielona na kolumny.

Rozpoznawanie i usuwanie błędów wyświetlania

Diagnostykę warto rozpocząć od sprawdzenia rzeczywistych bajtów oraz informacji o kodowaniu, a nie od samego wyglądu tekstu na ekranie. W systemie Windows polecenie chcp pokazuje aktywną stronę kodową konsoli, lecz nie zmienia automatycznie kodowania wszystkich programów. W PowerShell można jawnie określić kodowanie przy odczycie i zapisie pliku, używając odpowiednich parametrów poleceń, zamiast polegać na ustawieniach domyślnych. W edytorze tekstu należy sprawdzić, czy plik został otwarty jako UTF-8, UTF-8 z BOM czy w innym kodowaniu. BOM, czyli znacznik kolejności bajtów, może pomóc niektórym programom rozpoznać kodowanie, ale nie jest wymagany przez UTF-8 i w wybranych formatach może powodować dodatkowe problemy na początku pliku.

Trzeba również odróżnić błąd kodowania od problemu z fontem lub normalizacją Unicode. Jeśli bajty są prawidłowe, ale krój pisma nie zawiera danego glifu, znak może zostać pokazany jako prostokąt, mimo że tekst jest zapisany poprawnie. Ten sam widoczny znak może być zapisany jako pojedynczy znak Unicode albo jako sekwencja znaku podstawowego i znaku łączącego. Przy porównywaniu, wyszukiwaniu i walidacji danych aplikacja może więc potrzebować normalizacji, na przykład do postaci NFC. Podczas naprawy strony lub komputera należy prześledzić cały łańcuch: źródłowy plik, deklarację HTML, nagłówki HTTP, sposób odczytu formularza, zapis danych oraz użyty font. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, w tym diagnostyką problemów z wyświetlaniem oraz obsługą polskich znaków w używanym oprogramowaniu.