Jeśli jesteś właścicielem tej strony, możesz wyłączyć reklamę poniżej zmieniając pakiet na PRO lub VIP w panelu naszego hostingu już od 4zł!
Str. główna > Ogonki na stronach www
English
 

Ogonki (nie tylko polskie) na stronach www – tworzenie stron www z polskimi (i nie tylko) znakami, konwersja kodowań

Na tej stronie omówione jest tworzenie stron www w sposób zapewniający prawidłowe wyświetlanie polskich (i innych) liter, w tym metoda obejścia konfiguracji serwera www powodującej psucie polskich liter.

Spis treści:

  1. Wprowadzenie do kodowania i deklarowania polskich liter i innych znaków narodowych i specjalnych
    1. Kodowanie dokumentów (X)HTML
    2. Kodowanie w skryptach JavaScript
    3. Kodowanie w arkuszach stylów (CSS)
      1. Dodatek: deklaracja alternatywnych stylów dla różnych języków
    4. Kodowanie w kodzie źródłowym apletów Javy
    5. Uwagi na temat tworzenia plików pomocy CHM link prowadzi do podstrony
    6. Typowe błędy techniczne powodujące nieprawidłowe wyświetlanie znaków narodowych i specjalnych
    7. Czcionki osadzone (linkowane, ściągane z serwera)
  2. Programy przydatne przy tworzeniu stron www
    1. Edytory www Nvu i Kompozer
    2. Edytor www AceHTML
    3. Amaya – edytor i przeglądarka HTML konsorcjum W3C
    4. Edytor www Arachnophilia
    5. Open Office – zapis w formacie HTML
    6. Unikodowy edytor czystego tekstu i RTF Simredo (do wykorzystania jako konwerter kodowania)
    7. Unikodowy edytor czystego tekstu UniRed (do wykorzystania jako konwerter kodowania)
    8. Unikodowy edytor czystego tekstu BabelPad (do wykorzystania jako konwerter kodowania)
    9. Konwerter Gżegżółka
    10. Tidy – narzędzie do poprawiania kodu HTML
  3. Prawidłowe i błędne encje/ sekwencje reprezentujące polskie litery i najczęściej używane znaki specjalne
    1. Znacznie obszerniejsza lista encji i sekwencji link prowadzi do podstrony
  4. Usuwanie polskich liter z treści
  5. Gdzie nie stosować polskich liter i jak zapewnić poprawność techniczną odsyłaczy
  6. Linki

Taki znaczek: link do str. zewnętrznej przy odsyłaczu oznacza, że odsyłacz prowadzi do strony zewnętrznej.
A taki znaczek: link prowadzi do podstrony – że odsyłacz prowadzi do innej strony w tym serwisie.

Uwaga: w poniższym tekście jest dużo informacji na temat kodowania, wyboru kodowania czy zmiany kodowania. Nie każdy program pozwala na wybór kodowania, w takim wypadku można uznać, że program ten domyślnie koduje w kodowaniu używanym przez system. Na przykład w przypadku polskiego Windowsa Notatnik (i wiele innych programów pod Windows) zapisuje pliki w kodowaniu Windows-1250. Należy o tym pamiętać.

1. Wprowadzenie do kodowania i deklarowania polskich liter i innych znaków narodowych i specjalnych

Informacje tu przedstawione dotyczą współczesnych wersji standardów, czyli HTML 4 i wyższe oraz CSS 2 i wyższe.

Generalnie każdy dokument w internecie, który zawiera treść, musi mieć zadeklarowane kodowanie (charset, z ang. character set – zestaw znaków). Jedynie dokumenty zawierające następujące treści będą wyświetlane poprawnie mimo braku deklaracji:

Deklarować charset można na następujące sposoby, które zostały uszeregowane w kolejności priorytetu:

  1. Deklaracja wysyłana przez serwer. Jest to zalecana metoda deklaracji i jako jedyna możliwa do zastosowania dla niektórych typów dokumentów (np. tekstowych). Niestety, zazwyczaj użytkownik nie ma dostępu do konfiguracji serwera, co stwarza problemy, gdy strona użytkownika jest kodowana inaczej (domyślnie dla dokumentów HTML serwer Apache deklaruje ISO-8859-1; w wielu instalacjach, zwłaszcza tych, na których udostępniane są darmowe konta na stronę www, wysyłanie deklaracji charsetu jest wyłączone przez administratora). Wysyłaną deklarację można sprawdzić np. na stronie web-sniffer.net link do str. zewnętrznej, po wpisaniu URL-a do sprawdzanej strony wyświetli się nagłówek HTTP, w którym interesująca nas linia to
    Content-Type:
    Wybrane możliwe wartości tej linii to:
  2. deklaracja w nagłówku strony (X)HTML. Najpowszechniej stosowana. Istnieje również metoda deklarowania charsetu znaków pisarskich użytych w arkuszach stylów CSS (deklaracja @charsetBOM). W przypadku zewnętrznych plików JavaScript formą deklaracji charsetu jest BOM. Oczywiście BOM stosuje się tylko gdy plik jest kodowany w jednej z transformacji Unikodu, najczęściej będzie to UTF-8,
  3. atrybut charset elementu linkującego, wskazuje na charset dokumentu, do którego prowadzi odsyłacz. Przykłady: W przypadku plików umożliwiających zadeklarowanie charsetu poprzednią metodą mocno zaleca się użycie tej poprzedniej metody, a nie deklaracji w odsyłaczu.
    UWAGA: Obsługa deklaracji kodowania w <a href= jest marginalna (ze znanych mi przeglądarek: IE6, Konqueror 3.5.5, Firefox 1.5 i 2 oraz Opera 8 i 9 jedynie Opera to obsługuje). W specyfikacjach przyszłych wersji (X)HTML 5 (obecnie na etapie projektowania) brak tego atrybutu,
  4. charset domyślny dla danego typu dokumentu:

1.1. Kodowanie dokumentów (X)HTML
(o ile nie wspomniano inaczej, informacje dotyczą HTML 4 i 4.01 oraz XHTML 1.0 i 1.1)

W dzisiejszych czasach nie ma żadnych powodów, by na stronach www z zasady nie stosować polskich liter. Polskie litery mogą być kodowane na dwa sposoby: w postaci 8-bitowej (tak, jak wpisywane z klawiatury) lub w postaci encji (w ten sposób mogą zapisywać niektóre programy i konwertery). Encje z kolei mogą występować w trzech postaciach: numeryczne dziesiętne (najszerzej obsługiwane), symboliczne (większość występuje tylko HTML 4, w XHTML poprawna interpretacja zależy od podania odpowiedniego DTD, najstarsze przeglądarki mogą nie obsługiwać mimo obsługi encji numerycznych dziesiętnych) i numeryczne szesnastkowe (najstarsze przeglądarki mogą nie obsługiwać szesnastkowych mimo obsługi dziesiętnych). Wybór metody jest kwestią osobistych preferencji, strona używająca znaków w postaci 8-bitowej ma nieco mniejszą objętość i jest marginalnie bardziej dostępna (najstarsze przeglądarki sprzed drugiej połowy XX w. nie obsługują encji, ale ich udział jest pomijalny), może też być łatwiejsza w edycji. Tradycyjnie polskie litery w postaci 8-bitowej są kodowane w ISO-8859-2, ale w dzisiejszych czasach przeglądarki obsługują wiele różnych kodowań, w tym UTF-8. Przeglądarki nieobsługujące UTF-8 mają pomijalny udział na rynku, są to np. Internet Explorer 3 i wcześniejsze oraz Netscape Navigator 3 i wcześniejsze. Wybór kodowania jest więc sprawą otwartą, oto krótka dyskusja:

W przypadku postaci 8-bitowej w dokumentach HTML (nie XHTML) konieczne jest umieszczenie w nagłówku strony deklaracji charsetu w postaci:
<meta http-equiv="content-type" content="text/html; charset=iso-8859-2">
Linia ta powinna być obecna w nagłówku nawet wtedy, gdy serwer wysyła własną deklarację charsetu – dzięki temu nie będzie problemu z krzakami na stronie po zapisaniu jej na dysku (w wypadku strony otwieranej z dysku lokalnego nie ma serwera, który wysyłałby deklarację charsetu…). Oczywiście można też użyć innego legalnego kodowania w zależności od języka, w jakim tworzona jest strona, w tym UTF-8. Należy wówczas pamiętać, by deklaracja charsetu w powyższej linii była prawdziwa i poprawna – czyli deklarująca kodowanie, jakie rzeczywiście jest użyte na stronie! Dobrą i zalecaną praktyką jest umieszczenie linii deklarującej charset na początku nagłówka (jako pierwsza linia po znaczniku <head>) albo co najmniej przed pierwszą linią, w której użyte zostały znaki 8-bitowe. Typowo jedyne linie nagłówka, w których takie znaki mogą się znaleźć, to <title>tytuł strony</title>, <meta name="description" (…) > i <meta name="keywords" (…) >.
Uwaga: w HTML 5 planowane jest, że linia ta będzie musiała być umieszczona jako pierwsza po znaczniku <head>.

W przypadku dokumentów XHTML na samym początku dokumentu, jako pierwszą, umieszcza się następującą linię:
<?xml version="1.0" encoding="UTF-8"?>
(UTF-8 jest domyślnym kodowaniem dla dokumentów XHTML, choć można użyć i zadeklarować dowolne inne, legalne kodowanie, np. ISO-8859-2, jeżeli zajdzie taka potrzeba). Dla dokumentów XHTML przesyłanych jako application/xhtml+xml brak deklaracji jest równoznaczny z deklaracją UTF-8, a przesyłanych z deklaracją text/xml – US­-ASCII – używając domyślnego kodowania można pominąć charset w ogóle, ta linia wygląda wówczas <?xml version="1.0"?>. Domyślny charset US­-ASCII oznacza, że polskie litery i wszystkie inne znaki narodowe i specjalne muszą być zakodowane w postaci encji. Patrz RFC 3023 link do str. zewnętrznej. Deklarację w tej linii zaleca się stosować nawet wtedy, gdy serwer wysyła deklarację w nagłówku HTTP, gdyż pozwoli to uniknąć krzaków na stronie zapisanej lokalnie.

Jeżeli strona www jest napisana w XHTML, ale jest wysyłana jako HTML, należy użyć deklaracji jak dla strony HTML.

Poza tym, co oczywiste, nie wolno deklarować w arkuszach stylów (ani w inny sposób) nieunikodowych czcionek z nazwą czy oznaczeniem skryptu w nazwie (np. Times New Roman CE, Times New Roman Cyr) ani czcionkek systemowych systemu Windows, to jest Courier, MS Sans Serif, MS Serif, Small Fonts, Terminal.

Prawidłowe kodowanie znaków plus prawidłowa deklaracja to jedyne warunki, które musi spełniać strona www, by polskie i wszystkie inne zagraniczne litery pokazały się prawidłowo.

Gdy strona zostanie zamieszczona na przypadkowym serwerze www, który został skonfigurowany w specyficzny sposób, mimo poprawnego kodowania i poprawnej deklaracji zamiast polskich liter pokażą się krzaki. W takim wypadku można skontaktować się z administratorem serwera i poprosić go o zmianę deklaracji charsetu wysyłanej w nagłówku HTTP na taką, jakiej używa się na stronie www (np. ISO-8859-2), lub w ogóle wyłączenie wysyłania tej deklaracji (w zupełności wystarcza deklaracja zawarta w nagłówku META dokumentu HTML). Można administratora skierować na stronę o konfiguracji serwera www Apache link do str. zewnętrznej. Jeżeli kontakt z administratorem nie jest możliwy lub nie dał oczekiwanych rezultatów, a zmiana serwera nie wchodzi w grę, wszystkie znaki spoza US­-ASCII należy zakodować jako tzw. encje unikodu. W wyniku konwersji źródło strony będzie wyglądać w specyficzny sposób, np. każda litera „ó” będzie zastąpiona przez „&#243;” lub &oacute;. To są właśnie encje – ten pierwszy zapis to jest unikodowa encja numeryczna, drugi – encja symboliczna. To jest całkowicie normalne zjawisko, a wszelkie ogonki będą się prawidłowo pokazywać u wszystkich korzystających z w miarę nowoczesnych przeglądarek (IE od wersji 4 w górę, Opera od wersji 6 w górę, Netscape od wersji 6 w górę, Mozilla, Firefox i Konqueror: wszystkie wersje…) – na przykład to zdanie, które teraz czytasz, zostało zakodowane z użyciem encji. Spis prawidłowych encji/ sekwencji wszystkich polskich liter oraz najczęściej używanych znaków przestankowych i specjalnych wraz z encjami/ sekwencjami błędnymi znajdziesz w punkcie 3. – kody polskich liter, znacznie obszerniejsza lista mieści sie na własnej podstronie link prowadzi do podstrony. Niestety, nie każdy program do tworzenia stron www posiada funkcję konwersji znaków do encji lub zapisu ich w tej postaci, na przykład nie ma tej funkcji w edytorach HTML EdHTML, 1st Page 2000, Frontpage Express, Pajączek Light, Zajączek ani EZHTML. W dalszej części tego punktu przedstawiam garść programów obsługujących ten sposób kodowania i instrukcje ich konfiguracji do zapisu polskich liter i wszelkich innych znaków spoza US­-ASCII jako unikodowych encji numerycznych w dokumentach (X)HTML.

Należy pamiętać, że z uwagi na techniczną odmienność encji HTML, JavaScript i CSS, przekodowywanie dokumentów HTML zawierających w sobie skrypty JavaScript (lub ewentualnie style) zawierające znaki spoza US­-ASCII nie jest możliwe na raz. Ze znanych mi programów jedynie BabelPad pozwala na konwersję zaznaczonego tekstu, po konwersji fragmentów będących skryptami i wymagających użycia encji właściwych dla JavaScriptu można przekonwertować resztę dokumentu na encje właściwe dla HTML (albo w odwrotnej kolejności); analogicznie należy osobno przekonwertować definicje stylów w nagłówku i inline. W przypadku pozostałych programów z treści należy usunąć fragmenty skryptów (i ewentualnie definicji stylów) i przekonwertować je osobno. Z tego względu optymalne rozwiązanie to ścisłe trzymanie się wytycznych W3C i umieszczenie skryptów JavaScript w zewnętrznych plikach .js, tak samo stylów w arkuszu stylów .css.

Dodatkowa, drobna korzyść ze stosowania encji to poprawne wyświetlenie się strony nawet w przypadku ustawienia (nowoczesnej) przeglądarki przez użytkownika na sztywno na jakiś charset (ISO-8859-2 w Polsce, ISO-8859-1 na zachodzie itp.).

Różne rodzaje encji mogą być używane na raz w jednym dokumencie, wspólnie ze znakami w postaci 8-bitowej. Na przykład jak ktoś chce, może zapisać zwrot „ósmy żółw” jako ósmy &#380;&oacute;&#x142;w (tak to słowo zostało tu zapisane, i jak widać zostało wyświetlone poprawnie).

Encje można również wykorzystać do zakodowania znaków, których nie ma w 8-bitowym charsecie używanym do kodowania danej strony. Na przykład na stronie kodowanej ISO-8859-2 jest możliwe użycie prawidłowych cudzysłowów, pauz, znaku €uro, ©opyrightu itp. właśnie dzięki zakodowaniu ich jako encji, podczas gdy polskie litery są kodowane 8-bitowo.

Należy przypomnieć, że w dokumentach (X)HTML z powodów technicznych w każdym wypadku (całkowicie niezależnie od wybranego sposobu reprezentacji znaków narodowych i specjalnych) trzy znaki występujące gdziekolwiek w treści, w tym w odsyłaczach, muszą być kodowane jako encje: > jako &gt; lub &#62; lub &x3E;, < jako &lt; lub &#60; lub &x3C;, & jako &amp; lub &#38; lub &x26;, dwa dalsze znaki muszą być kodowane, gdy występują jako wartości atrybutów znaczników (kodowanie ich w treści jest zalecane, choć nieobowiązkowe): " jako &quot; lub &#34; lub &x22;, a ' jako &#39; lub &x27; lub – tylko w dokumentach XHTML – &apos;, przy czym tej ostatniej encji nie rozumie IE. Edytory tekstowe z funkcją konwersji między postacią 8-bitową a encją zmienią również powyższe encje na znaki, co spowoduje, że strona (X)HTML nie będzie mogła być poprawnie wyświetlona.

Uwaga: przy wyborze edytorów nie kierowałem się jakością tworzonego kodu HTML, jedynie możliwością zapisu znaków spoza US­-ASCII jako encji numerycznych. Przykładowo kod pochodzący z Open OfficeFrontPage będzie dość kiepski (nawet przy optymalnych ustawieniach opcji obu programów i wykorzystaniu ich wyłącznie jako konwerterów już istniejących stron), kod z Nvu i AceHTML wygląda na dużo bardziej poprawny. Kod można poprawić narzędziem Tidy. Ani edytory Simredo, UniRed i BabelPad, ani konwerter Gżegżółka, nie ingerują w kod HTML jako taki.

1.2. Kodowanie w skryptach JavaScript

Zewnętrzny plik JS zawierający znaki spoza US­-ASCII (czyli polskie litery i ogólnie wszelkie znaki narodowe i specjalne) może być zakodowany w UTF-8 (a także w UTF-16 lub nawet UTF-32) i zawierać BOM (znacznik określający użycie danej transformacji Unikodu). Wiele edytorów obsługujących Unikod potrafi zapisać BOM do pliku, nawet windowsowy Notatnik (przy zapisie jako UTF-8). W przypadku braku obecności BOM do wyświetlenia znaków spoza US­-ASCII użyty zostanie charset strony www, z której skrypt został wywołany. Gdy skrypt jest częścią strony, do wyświetlenia znaków narodowydch i specjalnych użyty zostanie charset danej strony. Gdy jednak zdarzy się opisany w poprzednim punkcie problem z błędnym pokazywaniem znaków wskutek wspomnianej konfiguracji serwera (mającej priorytet nad BOM i deklaracją charsetu strony www w jej nagłówku), lub gdy tekst ze skryptu zawiera znaki niebędące częścią charsetu strony www, wyjściem jest zastosowanie sekwencji (Unicode escape sequence), analogicznie jak w przypadku HTML. Sekwencje JavaScriptu mają format odmienny od encji numerycznych HTML, choć zasada jest ta sama: sekwencje składają się ze znacznika \u (odwróconego ukośnika i małej litery u), po którym następuje czterocyfrowy kod pozycji unicode znaku w formacie szesnastkowym. W tabelce w punkcie 3. – kody polskich liter w rubryce „JavaScript” zamieszczone zostały sekwencje w formacie właściwym dla skryptów JavaScript.

Norma przewiduje też stosowanie sekwencji reprezentujących znaki ze zbioru ISO-8859-1, sekwencje te używają znacznika \x i dokładnie dwóch znaków (cyfr szesnastkowych) określających numer pozycji w kodowaniu ISO-8859-1, np. litera „ó” jest kodowana jako \xF3. Jedyna polska litera, jaką można zakodować w ten sposób, to o z kreską, inne znaki spotykane w języku polskim to znaki wewnętrznych cudzysłowów (» i «), poprawne z p-tu widzenia typografii, ale prawie niespotykane (jeszcze) w dokumentach (X)HTML. Zamieniać sekwencje ISO na unikodowe i z powrotem jest bardzo łatwo, wystarczy zapamiętać, że wszystkie sekwencje unikodowe z zakresu \u0000 – \u00FF (i tylko z tego zakresu) można zapisać również jako \x00 – \xFF bez zmiany ostatnich dwóch cyfr szesnastkowych.

Z przedstawionych niżej programów Simredo, UniRedBabelPad potrafą zapisać dokument z użyciem sekwencji JavaScript.

W przypadku, gdy efektem działania skryptu jest jakiś tekst wewnątrz strony www, możliwe też jest ewentualne użycie encji HTML – skrypt wówczas przekazuje encje w postaci takiej, jak są zapisane, do przeglądarki, która powinna te encje poprawnie zinterpretować i wyświetlić. W przypadku tekstów wyświetlanych w oknach dialogowych i na belce statusu przeglądarki sekwencje JavaScriptu są jedynymi działającymi kodami. Stosowanie sekwencji JavaScript jest ogólnie bezpieczniejszym rozwiązaniem.

Ponieważ odwrócony ukośnik oznacza początek sekwencji, a znaki prostego cudzysłowu i prostego apostrofu (chodzi o te dostępne bezpośrednio z klawiatury) służą do wyznaczania ciągów, nie wolno w skryptach stosować samotnego odwróconego ukośnika, a w treści nie wolno stosować prostych cudzysłowów ani apostrofów. Prawidłowy zapis to dwa odwrócone ukośniki, czyli \\, zaś prosty cudzysłów i prosty apostrof muszą zostać zakodowane jako sekwencje, czyli odpowiednio \u0022\u0027 lub odpowiednio \x22\x27 – w danym miejscu pokazany zostanie odpowiednio jeden odwrócony ukośnik, prosty cudzysłów lub prosty apostrof (jeżeli skrypt jest umieszczony w osobnym pliku, wystarczy poprzedzić prosty cudzysłów względnie prosty apostrof odwrotnym ukośnikiem, czyli odpowiednio \"\'). JavaScript definiuje też kilka sekwencji oznaczających znaki sterujące, składających się z ukośnika odwróconego i pojedynczej litery, praktyczne znaczenie mają trzy: \n to nowa linia, \r to powrót karetki, \t to tabulator (dodany w najnowszej wersji standardu, nieobsługiwany przez IE6), pozostałe to \b, \f, \v, oznaczające odpowiednio cofnięcie o jeden znak, wysuw papieru i pionowy tabulator.

Uwaga: w przeciwieństwie do encji HTML, sekwencje JavaScript nie mają znaku końca (w przypadku encji HTML końcem encji jest średnik), i z tego powodu mają stałą długość: w przypadku sekwencji unikodowych długość wynosi zawsze sześć znaków (dwuznakowy znacznik sekwencji unikodowej \u i czteroznakowy kod znaku), a w przypadku sekwencji ISO-8859-1 – cztery znaki (dwuznakowy znacznik sekwencji ISO-8859-1 \x i dwuznakowy kod znaku). Nigdy nie należy pomijać wiodących zer. Przykładowo zapis litery „ą” jako encji w postaci \u101 zamiast \u0101 zwykle nie da oczekiwanych rezultatów. W żadnym wypadku nie należy próbować stosowania sekwencji ISO-8859-1 do kodowania pozostałych polskich liter z użyciem np. kodów ISO-8859-2 – ta metoda nie zadziała niezależnie od kodowania strony www ani ustawień przeglądarki.

Oba powyższe rodzaje sekwencji istnieją również w projekcie czwartej wersji normy.

Uwaga: inny alternatywny zapis, obecny w wersjach 1 i 2 normy, ale od wersji 3 już nie będący częścią standardu, to ukośnik odwrotny plus trzycyfrowy kod ósemkowy znaku (np. litera „ó” to \363), standard nie przewiduje istnienia sekwencji ponad \377 (co odpowiada sekwencji \xFF), choć Opera jako jedyna znana mi przeglądarka www obsługuje wyższe sekwencje zapisane ósemkowo (do \777). Spośród polskich liter jedynie litera „ó” może być zakodowana w ten sposób. Podobnie jak w wypadku sekwencji szesnastkowych ISO-8859-1, w żadnym wypadku nie należy próbować stosowania tych sekwencji do kodowania pozostałych polskich liter z użyciem np. kodów ISO-8859-2 – ta metoda nie zadziała niezależnie od kodowania strony www ani ustawień przeglądarki. Nie wolno też pomijać wiodących zer (np. użycie sekwencji \47 zamiast \047 nie da oczekiwanych rezultatów). Z uwagi na niezgodność z normą i możliwe problemy z kompatybilnością, nie zaleca się stosowania sekwencji ósemkowych.

Podobnie jak w wypadku encji HTML, zakresy \u0000 – \u001F\u007F – \u009F (\x00 – \x1F\x7F – \x9F, \000 – \037\177 – \237) są zarezerwowane dla znaków sterujących i nie wolno ich stosować z nadzieją, że przeglądarka te znaki zinterpretuje (np. górny zakres jako pseudosekwencje oznaczające znaki z charsetu Windows-1252). Nawet Internet Explorer wyświetla w miejscu tych sekwencji puste klatki.

W kodzie JavaScriptu można użyć różnych rodzajów sekwencji na raz, wspólnie ze znakami w postaci 8-bitowej we właściwym kodowaniu. Na przykład jak ktoś chce, może zapisać zwrot „ósmy żółw” jako \363smy \u017C\xF3łw (tak to słowo zostało tu zapisane, kliknij, by się przekonać, że zostanie wyświetlone poprawnie).

Sekwencje można również wykorzystać do zakodowania znaków, których nie ma w 8-bitowym charsecie używanym do kodowania danej strony, na której ma działać skrypt. Na przykład na stronie kodowanej ISO-8859-2 jest możliwe wyświetlenie przez skrypt prawidłowych cudzysłowów, pauz, znaku €uro, ©opyrightu itp. właśnie dzięki zakodowaniu ich jako sekwencji, podczas gdy polskie litery są kodowane 8-bitowo w ISO-8859-2, w którym to charsecie tych znaków nie ma.

Literatura: Norma ECMA-262 link do str. zewnętrznej – definiuje obecną implementację JavaScriptu (patrz rozdz. 6, 7 i zał. B1)

1.3. Kodowanie w arkuszach stylów (CSS)
(o ile nie wspomniano inaczej, informacje dotyczą CSS 2 i 2.1)

Zazwyczaj w arkuszu stylu nie ma żadnego tekstu, który byłby wyświetlany na stronie www, ale niekiedy przydaje się możliwość zdefiniowania dekoracyjnych elementów branych z czcionek zamiast plików graficznych lub definicja stylu cudzysłowów zewnętrznych i wewnętrznych. Ta ostatnia możliwość byłaby bardzo przydatna – wystarczyłoby umieścić w arkuszu stylu jedną linię, a w tekście można byłoby wówczas stosować wyłącznie znaczniki <q> zamiast za każdym razem wpisywać odpowiedni znak cudzysłowu, a przeglądarki same pamiętałyby, gdzie umieścić jaki znak cudzysłowu: demonstracja link prowadzi do podstrony, ale niestety nie obsługuje jej IE 6 i 7 (ani, rzecz jasna, wcześniejsze), które to wersje wciąż mają znaczący udział w rynku (IE 8 już obsługuje, ale nie na wszystkich stronach). Definicje stylów mogą występować w dwóch wersjach: jako część strony (w nagłówku lub style inline lub jako zewnętrzny arkusz stylów. Znaki spoza US­-ASCII w stylach będących częścią strony zawsze muszą być w tym samym kodowaniu, co dana strona www, natomiast zewnętrzny arkusz stylów może używać dowolnego kodowania tych znaków, niezależnie od kodowania stron www, dla których jest używany. Charset arkusza stylu deklaruje się wpisując w pierwszej linii arkusza deklarację w postaci np.
@charset "ISO-8859-2"
Oczywiście w miejsce ISO-8859-2 należy wstawić faktycznie użyty charset, np. UTF-8. Alternatywnie, plik może zostać zapisany w jednej z transformacji Unikodu z użyciem BOM, optymalna transformacja to UTF-8. Alternatywną metodą zapisu znaków spoza US­-ASCII w arkuszu stylu są sekwencje (escaped sequences) w postaci odwrotnego ukośnika, po którym następuje kod szesnastkowy danego znaku. Kod ten może albo zawierać dokładnie sześć cyfr szesnastkowych (w razie potrzeby należy dodać odpowiednią ilość zer na początku), albo musi być zakończony białą spacją (spacja, tabulator…) lub znakiem innym niż cyfra lub litera z przedziału a ÷ f. Jak widać sekwencje CSS są bardzo podobne do sekwencji JavaScriptu, jedyną różnicą jest długość i brak literki u po odwrotnym ukośniku. W przeciwieństwie do sytuacji z JavaScriptem, w przypadku arkuszy CSS znaki zapisane jako encje HTML zwykle nie działają – jeżeli nie da się użyć znaku w postaci 8-bitowej, należy użyć sekwencji właściwej dla arkuszy CSS. Żaden ze znanych mi programów nie potrafi zapisywać od razu znaków w tej postaci, ale można do tego celu wykorzystać program Simredo, UniRed lub BabelPad zapisując tekst tak, jak w przypadku JavaScriptu, a następnie zamieniając w treści wszystkie ciągi \u na \00.

Przykładowy kod CSS odpowiedzialny za automatyczne wstawianie odpowiednich znaków cudzysłowów, użyty na stronie demonstracyjnej, wygląda następująco:
q {quotes: "\201E" "\201D" "\BB" "\AB"}
alternatywnie w zewnętrznym arkuszu CSS można byłoby użyć następującej składni:
@charset: "UTF-8"
q {quotes: "„" "”" "»" "«"}

(oczywiście druga wersja musiałaby być zapisana w UTF-8).

Dodatkowa, drobna korzyść ze stosowania kodów to poprawne wyświetlenie się strony nawet w przypadku ustawienia (nowoczesnej) przeglądarki przez użytkownika na sztywno na jakiś charset (ISO-8859-2 w Polsce, ISO-8859-1 na Zachodzie itp.) lub korzystania z jakiegoś serwera proxy, który ingeruje w deklarację charsetu.

Deklaracja charsetu arkusza stylu jest częścią CSS2, pobieżne testy wykazały, że na pewno obsługują ją Opera 8 i 9, Firefox 1.5 i 2 oraz IE 6 SP1. W wersji CSS1 nie istniał mechanizm deklarowania charsetu, a sekwencje składały się z maksymalnie czterech cyfr (a nie sześciu).

Literatura: FAQ: Deklaracje kodowania znaków CSS link do str. zewnętrznej na serwerze Konsorcjum W3C,
Opis kodowania znaków w arkuszach CSS link do str. zewnętrznej.

1.3.1. Dodatek: deklaracja alternatywnych stylów dla różnych języków

W standardzie HTML istnieje atrybut lang (w XHTML – xml:lang), który może być dodany do dowolnego znacznika. Standard CSS 2 i wyższe pozwala na uzależnie stylu od wartości tego argumentu, dzięki czemu możliwe jest zawarcie w jednym arkuszu stylów różnych stylów zgodnych z uzusem w różnych językach. Przykładem może być uzależnienie stylu cudzysłowów od języka:

JęzykCudzysłowy zewnętrzneCudzysłowy wewnętrzne
Polski„ ”» «
Angielski“ ”‘ ’
Angielski (alternatywna konwencja)‘ ’“ ”
Niemiecki„ “‚ ‘
Rosyjski« »„ “

Odpowiedni fragment kodu zamieszczony jest poniżej. Dla ułatwienia i przejrzystości przyjęto, że konwencja angielska stosowana jest w amerykańskim angielskim, zaś alternatywna – w każdej innej odmianie angielskiego (co było prawdą 20 lat temu, ale obecnie coraz szerzej stosowana jest pierwsza konwencja, również w brytyjskim angielskim):

q:lang(pl)    {quotes: "„" "”" "»" "«"}
q:lang(en)    {quotes: "‘" "’" "“" "”"}
q:lang(en-US) {quotes: "“" "”" "‘" "’"}
q:lang(de)    {quotes: "„" "“" "»" "«"}
q:lang(ru)    {quotes: "«" "»" "„" "“"}

Podobnie można definiować różne style dla akapitów itp. Wyżej opisany mechanizm nie jest obsługiwany przez IE 6 ani 7.

1.4. Kodowanie w kodzie źródłowym apletów Javy

W kodzie źródłowym apletów Javy znaki narodowe i specjalne mogą być wprowadzone w postaci 8-bitowej albo sekwencji.

W przypadku postaci 8-bitowej kompilator uznaje domyślnie, że są one kodowane w kodowaniu właściwym dla locale systemu, czyli np. w przypadku angielskiego Windowsa będzie to Windows-1252, w przypadku angielskiego Linuksa używającego ISO-8859-1 – ISO-8859-1 itd. Aby zapewnić prawidłowe wyświetlanie znaków spoza US­-ASCII, należy użyć przełącznika -encoding <encoding>. Na stronach Suna dostępna jest Lista kodowań obsługiwanych przez Javę 1.5 i ich oznaczeń rozumianych przez kompilator link do str. zewnętrznej (strona w języku angielskim).

Sekwencje Javy są identyczne z sekwencjami unikodowymi JavaScriptu: każdy znak może zostać oznaczony jako \uXXXX, gdzie XXXX to numer szesnastkowy pozycji znaku w unikodzie. Używanie sekwencji w kodzie źródłowym Javy nie różni się niczym od używania sekwencji w JavaScripcie – patrz punkt 1.2.

W przeciwieństwie do JavaScriptu, w Javie nie istnieją sekwencje ISO-8859-1 w postaci \xXX, ale wciąż legalne pozostają sekwencje ósemkowe w postaci \OOO (gdzie OOO to ósemkowy numer znaku w kodowaniu ISO-8859-1, liczba ta może zawierać się w przedziale 040 – 377 i również zawsze musi mieć dokładnie trzy cyfry, tj. cała sekwencja ma zawierać cztery znaki: odwrotny ukośnik plus dokładnie trzy cyfry; w przypadku liczb mniejszych od 100 należy użyć wiodącego zera).

Tworząc aplet należy pamiętać, że niektóre moduły Javy podczas wyświetlania tekstu konwertują znaki spoza US­-ASCII z unikodu do kodowania lokalnego komputera (a dokładnie – do kodowania właściwego dla ustawień regionalnych), podobnie znaki wpisywane w pola tekstowe są traktowane jako kodowane w kodowaniu lokalnym (a dokładnie – w kodowaniu właściwym dla ustawień regionalnych systemu). W przypaodku gdy system używa kodowania lokalnego odmiennego od typowego kodowania dla używanego ustawienia regionalnego (np. angielskie brytyjskie ustawienia regionalne, ale 8-bitowe kodowanie systemowe ustawione na Windows­-1250, tylko znaki zawarte w kodowaniu zwykle używanym dla brytyjskiego angielskiego, czyli Windows­-1252, zostaną wyświetlone). Ponieważ prawidłowe wyświetlenie znaków narodowych w takich wypadkach jest uzależnione od ustawień systemu, na którym dany aplet jest wykonywany, nigdy nie ma gwarancji, że zostaną one wyświetlone poprawnie. W miarę możliwości należy unikać stosowania tych modułów. Szczegóły wykraczają poza tematykę tej strony, polecam dobry kurs programowania w Javie lub np. grupę dyskusyjną pl.comp.lang.java link do str. zewnętrznej.

Literatura: Specyfikacja języka Java link do str. zewnętrznej (patrz rozdz. 3.10.4)

1.5. Uwagi na temat tworzenia plików pomocy CHM

Umieszczone na osobnej podstronie link prowadzi do podstrony

1.6. Typowe błędy techniczne powodujące nieprawidłowe wyświetlanie znaków narodowych i specjalnych

Oprócz braku deklaracji charsetu spotykane są też inne nieprawidłowości, z których każda potencjalnie prowadzi do powstania krzaków. Poniżej omówienie najczęściej występujących.

1.7 Czcionki osadzone (linkowane, ściągane z serwera)

Autor publikacji drukowanej ma do dyspozycji różne kroje czcionek i z góry wie, jakie litery i znaki specjalne może wydrukować. Pliki przesyłane drogą elektroniczną z reguły korzystają z czcionek zainstalowanych na komputerze, na którym dany plik jest otwierany. Autor publikacji elektronicznej nie może przewidzieć, jakie czcionki i w jakich wersjach będą mieli zainstalowane wszyscy jego odbiorcy. Jeżeli mimo tego zdecyduje się na użycie mniej popularnych czcionek ozdobnych lub znaków specjalnych, których brak w wielu czcionkach, może to doprowadzić to do problemów natury estetycznej (jeżeli czytelnik nie będzie miał u siebie zainstalowanej czcionki wybranej przez autora, dokument zostanie wyświetlony z użyciem innej, często przypadkowej czcionki) i , co gorsza, z czytelnością tekstu (jeżeli żadna z czcionek zainstalowanych u czytelnika nie będzie zawierała symboli użytych przez autora). Niektóre formaty plików elektronicznych (PDF, formaty natywne OpenOffice.org i MS Office oraz inne) umożliwiają dołączenie do dokumentu używanych w nim czcionek, dzięki czemu dokument może być wyświetlony prawidłowo niezależnie od tego, czy potrzebne czcionki są zainstalowane na komputerze czytelnika. Dołączanie czcionek do dokumentów (X)HTML (w formie kodu stanowiącego część strony) jest niecelowe zważywszy przyrost objętości, więc wymyślono, by plik czcionki traktować w sposób analogiczny do plików grafiki i animacji – zamieścić w dokumencie odpowiedni link, przez który przeglądarka ściągnie plik czcionki, który następnie będzie użyty do wyświetlenia strony.

Do linkowania czcionek służy instrukcja @font-face, obecna w CSS2 link do str. zewnętrznej (standard opracowany w 1997) i CSS3 link do str. zewnętrznej. Przeglądarka otwierając stronę internetową wykorzystującą ten mechanizm ściąga czcionkę i używa jej do wyświetlania strony zgodnie z zamysłem autora. Czcionki te nie są instalowane na komputerze czytelnika, przez co w pewnych wypadkach (np. otwarcie strony zapisanej na dysku twardym, gdy nie można nawiązać połączenia z internetem lub gdy do deklaracji użyto odsyłaczy względnych) nie będą widoczne. Ponieważ czcionki nie są fizycznie dołączane do dokumentu – dokument jedynie zawiera odsyłacz, skąd czcionkę ściągnąć – termin „czcionka osadzona” jest nieprawidłowy technicznie i mylący. W dalszej części paragrafu będzie używany termin „czcionka linkowana”. W języku angielskim używa się terminu „web font”.

Ciekawostka: IE dla Windows obsługuje linkowane czcionki od wersji 4 wypuszczonej w 1997 r.(!). Czcionka musi być we własnym formacie opracowanym przez MS i Monotype, którego nie obsługuje żadna inna przeglądarka, w tym również dawniej dostępne wersje IE dla Maca i Uniksa. Netscape Navigator i Communicator w wersji 4 również obsługiwał linkowane czcionki we własnym, zamkniętym formacie TrueDoc link do str. zewnętrznej (opracowanym wraz z firmą Bitstream). Do linkowania używany był niestandardowy kod HTML. Czcionki w tym formacie mogą być wyświetlone przez IE po instalacji kontrolki ActiveX. Przeszkodą w rozpowszechnieniu obu technologii był brak obsługi przez inne przeglądarki, konieczność wykupienia drogiej licencji za program do tworzenia czcionek w formacie używanym przez Netscape oraz fakt, że w momencie wprowadzania tych technologii typowy użytkownik łączył się z internetem powolnym połączeniem dodzwanianym i często płacił za transfer.

1.7.1 Formaty i obsługa czcionek linkowanych

Norma Konsorcjum W3 nie precyzuje formatu czcionek linkowanych. Najpopularniejsze przeglądarki obsługują format .woff, obsługa formatów .ttf i .otf jest mniej rozpowszechiona (brak obsługi przez IE).

Poniżej zamieszczona jest lista przeglądarek obsługujących czcionki linkowane i informacje o obsługiwanych formatach.

  1. Firefox: obsługa .ttf. i .otf od wersji 3.1 alfa i od wersji stabilnej 3.5 z 30 czerwca 2009, .woff od wersji 3.6 alfa oraz stabilnej 3.6 z 22 stycznia 2010. Należy oczekiwać, że inne przeglądarki wykorzystujące silnik Gecko 1.9.1 i późniejsze (Seamonkey, Flock, Camino, K-Meleon i in.) również je obsługują (ew. będą obsługiwać po przejściu na wspomnianą wersję silnika). Silnik Gecko został wyposażony w mechanizm podstawowej kontroli dostępu do czcionek linkowanych – plik czcionki musi być dostępny z tej samej domeny i przez ten sam port, co dokument linkujący do tej czcionki. Ma to zapobiegać podkradaniu czcionek z cudzych serwerów.
  2. Safari: obsługa .ttf, .otf i .svg od wersji 3.1 beta i od wersji stabilnej 4.0 z 8 czerwca 2009, .woff od wersji 5.1. Należy oczekiwać, że inne przeglądarki wykorzystujace silnik WebKit 530 i późniejsze (OmniWeb, iCab, Epiphany i in.) również je obsługują.
  3. Opera: obsługa .svg od wersji 9.0; obsługa .ttf i .otf od wersji 10 alfa i od wersji stabilnej 10.00 z 1 września 2009, obsługa .woff od wersji 11.10 z 12 kwietnia 2011.
  4. Internet Explorer: obsługa .eot (i .pfr z użyciem kontrolki ActiveX) od wersji 4 (1997), .woff od wersji 9. Identyczne cechy zapewniają wszystkie nakładki na IE (Maxthon, Avant Browser).
  5. Google Chrome: obsługa .ttf, .otf od wersji 4.0, .woff od wersji 6.0.

1.7.2 Użycie czcionek linkowanych

Kodowanie: po pierwsze, CSS3 pozwala na poinstruowanie przeglądarki, by przed ściągnięciem czcionki sprawdziła, czy czcionka nie jest zainstalowana na komputerze czytelnika, by nie ściągać czcionki bez potrzeby. Po drugie, wszystkie formaty czcionek linkowanych mogą być zadeklarowane na raz z użyciem komentarzy warunkowych i pewnych sztuczek, dzięki czemu dokument używający linkowanych czcionek będzie wyświetlony prawidłowo zarówno u czytelnika używającego nowoczesnej przeglądarki, jak i użytkownika IE, a obciążenie serwera nie wzrośnie: patrz obszerna dyskusja i przykłady link do str. zewnętrznej. Dla tych, którym nie chce się dużo czytać po angielsku, poniżej przestawiony został przykładowy kod zapewniający optymalne linkowanie czcionki o nazwie „moja wypasiona czcionka”, której pliki w różnych formatach mają nazwę mwcz i odpowiednie rozszerzenie:

@font-face {
  font-family: "moja wypasiona czcionka";
  src: url("mwcz.eot");
  src: local("moja wypasiona czcionka"),
    url("mwcz.woff") format("woff"),
    url("mwcz.ttf") format("truetype"),
    url("mwcz.svg#mwcz") format("svg");
}

Niektóre wersje krojów czcionek (kursywa, pogrubiony itp.) są osobnymi plikami. Każdy taki plik jest traktowany przez przeglądarkę jako osobna czcionka i wymaga osobnej definicji i osobnego odsyłacza.

Z uwagi na potencjalnie bardzo duże rozmiary czcionek należy usuwać z pliku czcionki symbole (glify), które nie są używane na stronach. Zmniejszy to rozmiar czcionki, przyspieszy transfer, a także zmniejszy atrakcyjność licencjonowanej czcionki dla innych, którzy mieliby ochotę skorzystać z czcionki bez pytania o zgodę. W przypadku użycia czcionki linkowanej na stronie tworzonej dynamicznie przewidzenie, jakie znaki będą użyte w przyszłości, może być niemożliwe i wybrany zestaw znaków z konieczności będzie bardzo duży.

Jeżeli tworzona jest własna czcionka, symbole należy umieszczać zgodnie z unikodem. Symbole nieistniejące w unikodzie (np. logo własnej firmy, piktogramy wykorzystywane w rozkładach jazdy itp.) należy umieścić w zakresie znaków prywatnych (Private Use Characters, 0xE000–0xF8FF). W żadnym wypadku nie należy umieszczać tych znaków w zakresie ASCII czy w miejscu liter z ogonkami, podobnie np. polskich liter w żadnym wypadku nie należy umieszczać na pozycjach w kodowaniu ISO­-8859-2 ani Windows­-1250 (w unikodzie na pozycjach zajmowanych przez litery używane w językach zachodnioeuropejskich).

Portal poświęcony linkowanym czcionkom w internecie link do str. zewnętrznej

1.7.3. Problemy wynikające z używania czcionek linkowanych wykorzystujących niestandardowe kodowanie

Niektórym może się wydawać, że użycie linkowanych czcionek zawierających litery jakiegoś języka w jakimś mniej lub bardziej niestandardowym kodowaniu (np. Windows­-1250 używanym w czcionkach znanych z Windows 3.x, ISO­-8859-2, „kodowaniu”, w którym litery lub ideogramy używane w tym języku i nieistniejące w unikodzie zostały umieszczone na miejscu liter łacińskich bądź w górnym zakresie w dowolnym porządku, ogólnie mówiąc każde kodowanie odmienne od unikodu), jest dobrym pomysłem na poprawne wyświetlenie strony w tym języku u wszystkich odwiedzających, również tych, którzy korzystają z systemów nieskonfigurowanych do wyświetlania tego języka. Innym marzy się użycie linkowanych czcionek, by wszyscy zobaczyli treść wyświetloną z użyciem czcionki, której krój jest częścią wizerunku danej firmy, albo użycie specjalnej czcionki zawierającej znaki specjalne, nieobecne w unikodzie, w miejscu cyfr i liter łacińskich na podobieństwo czcionek rodziny Wingdings (np. różne wersje logo firmy lub piktogramy i symbole wykorzystywane w rozkładach jazdy PKP). Niestety, niestandardowe kodowanie znaków zawartych w czcionce to proszenie się o kłopoty – nowoczesne przeglądarki nie lubią czcionek nieunikodowych i bardzo często odmawiają użycia zadeklarowanej czcionki, wyświetlając treść swoją czcionką domyślną (unikodową), wyszukiwanie w treści jest praktycznie niemożiwe, w większości wypadków nie uda się skopiować tekstu i wkleić go w inny program bez utraty czytelności (krzaków), połączenie z serwerem może nagle ulec przerwaniu zanim plik linkowanej czcionki został ściągnięty w całości, ściąganie linkowanych czcionek może zostać wyłączone przez użytkownika, użytkownicy innych przeglądarek w każdej sytuacji zobaczą przypadkowe znaki pozbawione sensu, zaś wyszukiwarki nie będą umiały poprawnie zaindeksować treści takiej strony.

1.7.4. Wybrane oprogramowanie

2. Programy przydatne przy tworzeniu stron www

Opisy konfiguracji generalnie dotyczą zapisywania wszystkich znaków narodowych i specjalnych jako encji (co jest związane z obejściem konfiguracji serwera ustawionego na wysyłanie jakiejś deklaracji charsetu bez możliwości zmiany tego przez użytkownika i gdy deklaracja ta nie pokrywa się z kodowaniem użytym dla stron www). Niektóre programy umożliwiają również stosowanie mieszanej konwencji – niektóre znaki zapisane są w postaci 8-bitowej, a inne, nie istniejące w wybranym charsecie – jako encje. Zostało to zaznaczone pod koniec opisu danego programu. Zaletą stosowania mieszanki znaków 8-bitowych i encji jest zwykle mniejsza objętość dokumentu i lepsza czytelność kodu w najprostszych edytorach (nieobsługujących encji), zaś wadą jest uzależnienie od konfiguracji serwera – aby uniknąć krzaków serwer musi być tak skonfigurowany, że albo wysyła poprawną deklarację charsetu, albo nie wysyła żadnej.

Należy tu pamiętać, że edytory czystego tekstu nie potrafią automatycznie zakodować użytych w treści (nie w znacznikach, encjach czy parametrach) nawiasów kątowych, znaku & ani prostego cudzysłowu, trzeba o tym pamiętać.

Edytory HTML nie zostały przetestowane pod względem jakości kodu HTML ani jego zgodności ze standardem. Kod stworzony przez jeden z programów lub ręcznie można poddać automatycznej korekcji przy użyciu programu Tidy (opisanego poniżej).

UWAGA: Konwertery konwertując encje na znaki w postaci 8-bitowej zwykle konwertują też znaki specjalne ASCII używane w HTML do specjalnych celów: < & > " ', co w przypadku pierwszego z wymienionych znaków zawsze powoduje nieczytelność wielu części lub nawet całości dokumentu, w przypadku pozostałych znaków może spowodować nieczytelność, dodatkowo skutkuje w sygnalizacji licznych błędów przez kontroler poprawności składni W3C. Po użyciu konwertera w ten sposób należy koniecznie przejrzeć treść dokumentu i poprawić te znaki z powrotem na encje.

2.1. Edytory www Nvu i Kompozer

Edytor www Nvu link do str. zewnętrznej (międzyplatformowy – dla Windows, Linuksa i Mac OS X, bezpłatne na licencji Open Source) został stworzony przez Mozillę – producenta przeglądarki Firefox i klienta poczty i grup dyskusyjnych Thunderbird. Rozwój Nvu został wstrzymany, ale wydanych zostało kilka nieoficjalnych wersji pod nazwą Kompozer link do str. zewnętrznej, w których poprawiono różne błędy. Opcje konfiguracyjne i zachowanie Kompozera i Nvu są identyczne. Ustawienie należy zmienić przed utworzeniem nowego pliku lub otwarciem pliku przeznaczonego do konwersji:
Po wejściu w Narzędzia ⇒ Opcje (ang. Tools ⇒ Options), na zakładce Zaawansowane (ang. Advanced) należy wybrać opcję zapisywania wszystkich znaków spoza US­-ASCII jako encji (czerwona strzałka nr 1). Należy również upewnić się, że dwie klatki na samym dole (dwie strzałki, nr 2) nie są zaznaczone (tłumaczenie jest nie do końca prawidłowe, gdyż program będzie tak traktował nie tylko znaki specjalne, czyli różne znaczki typu ®, €, „cudzysłowy takie i »takie«” itp, ale również wszystkie litery ze znakami diakrytycznymi i litery z alfabetów innych niż łaciński, a to w żadnym wypadku nie są znaki specjalne, chyba że z punktu widzenia Amerykanów, a my nie jesteśmy Amerykanami):

Sam charset wybiera się na pozycji Ustawienia nowej strony. Można tu wybrać m.in. ISO-8859-2 albo UTF-8 (albo wiele innych charsetów, które nie są jednak używane dla stron w języku polskim). Należy w tym miejscu pamiętać, że program zawsze zapisuje znaki istniejące w danym charsecie w postaci 8-bitowej, a jedynie znaki spoza charsetu w postaci encji. Aby wszystkie znaki spoza US­-ASCII zapisać w postaci encji, należy wybrać jakiś bardzo egzotyczny charset. W przypadku tekstu polskiego nie może to być ani UTF-8, ani ISO-8859-2, ani Windows-1250, ani nawet ISO-8859-1 (zawiera ó):

Można też nie zmieniać domyślnego charsetu w opcjach, tylko skorzystać z opcji zapisu pliku ze zmianą kodowania: z menu Plik wybrać Zapisz i zmień kodowanie znaków:

i w oknie wyboru charsetu wybrać jakiś wyjątkowo egzotyczny charset:

Po ostatecznym zapisaniu strony ze znakami kodowanymi w postaci encji numerycznych warto ją otworzyć w notatniku i usunąć linię <meta content="text/html; charset=x-euc-tw" http-equiv="content-type"> (niektórzy odwiedzający mogą mieć problem z uciążliwym komunikatem, że przeglądarka nie obsługuje deklarowanego charsetu). Brak tej linii w niczym nie zaszkodzi, strona będzie doskonale się wyświetlać. Najprawdopodobniej podobne cechy i zasady działania wykazuje edytor HTML pakietu Mozilla Suite i przeglądarki Netscape.

OBSŁUGA KODOWANIA MIESZANEGO: Ponieważ Nvu zapisuje wszystkie znaki spoza wybranego charsetu jako encje, możliwe jest utworzenie strony www w kodowaniu mieszanym – wybranie charsetu ISO-8859-2 dla nowo tworzonej czy zapisywanej strony www spowoduje, że wszystkie znaki obecne w ISO-8859-2 zostaną zapisane w postaci 8-bitowej, a pozostałe jako encje.

Wybranie charsetu UTF-8 spowoduje zapisanie wszystkich znaków w postaci 8-bitowej (z wyjątkiem nawiasów kątowych i znaku & w treści).

Do obu programów istnieją różne rozszerzenia dodające wiele przydatnych funkcji, jedno z nich to AboutConfig link do str. zewnętrznej, które daje dostęp do opcji konfiguracyjnych tak, jak about:config w Firefoksie (wbrew opisowi rozszerzenie działa również z Nvu i Kompozerem).

2.2. Edytor www AceHTML

Ace HTML freeware link do str. zewnętrznej (tylko dla Windows) według producenta program ma licencję freeware, ale instaluje obowiązkowo spyware w postaci toolbara dla IE (VMN toolbar), na szczęście toolbar można natychmiast odinstalować, AdAware i Spybot Search & Destroy usuwają wszystkie pozostałości, a sam program po usunięciu toolbara działa normalnie. Aby program prawidłowo obsługiwał znaki narodowe i specjalne, należy sprawdzić (i ewentualnie zmienić) kilka ustawień (Tools ⇒ General preferences):

należy zaznaczyć, by program stosował kodowanie („Activate encoding”; środkowa strzałka) i nie konwertował specjalnych znaków ISO-8859-1 (górna strzałka) – to bardzo ważne, by nie zaznaczać tej opcji! Wbrew swej nazwie spowoduje ona, że niektóre znaki specjalne (pauzy i półpauzy, cudzysłowy…) zostaną zapisane w postaci pseudoencji numerycznych wskazujących na kody znaków w charsecie Windows-1252 (pozycje między 128 a 159), które w unikodzie (ani żadnym kodowaniu ISO) nie zawierają znaków pisarskich i przez to nie będą czytelne dla użytkowników bardzo wielu przeglądarek, zwłaszcza tych działających pod systemami innymi niż Windows! Zalecam tu też wybranie domyślnego charsetu nowo tworzonych stron jako unikod (dolna strzałka) – jest to motywowane tym, że program nie tylko zapisuje, ale i wyświetla wszystkie znaki spoza wybranego kodowania jako encje, przez co dokument taki jest mniej czytelny (np. wybranie tam kodowania 7-bitowego spowoduje, że w edytowanym dokumencie słowo „żółw” będzie pokazane jako „&#380;&oacute;&#322;w”). Zaznaczenie drugiej klatki od góry (opcji „Special characters in decimal”) spowoduje, że program będzie stosował do zapisania znaków spoza charsetu wyłącznie encje numeryczne (klatka niezaznaczona oznacza stosowanie mieszanki: encje symboliczne plus numeryczne). Współczesne przeglądarki obsługują oba rodzaje encji , więc wybór tej opcji jest kwestią osobistych preferencji.

Aby wszystkie znaki narodowe i specjalne w treści zapisać w postaci encji, należy przed zapisaniem ostatecznej wersji w głównym oknie programu wybrać kodowanie 7bit:

Program posiada wbudowaną tablicę znaków pozwalającą na łatwe wstawianie dowolnego znaku przez dwukliknięcie na nim.

OBSŁUGA KODOWANIA MIESZANEGO: Ace HTML freeware zapisuje wszystkie znaki, które nie istnieją w wybranym kodowaniu, jako encje unikodu. Dzięki temu możliwe jest otrzymanie dokumentu, w którym np. znaki obecne w charsecie ISO-8859-2 będą zapisane w postaci 8-bitowej, zaś znaki spoza tego charsetu – jako encje unikodowe. Ten sposób kodowania otrzymuje się wybierając dla zapisywanego dokumentu w oknie głównym programu ISO-8859-2 zamiast 7bit (lub innego charsetu odpowiedniego dla dokumentów w innych językach).

Wybór UTF-8 spowoduje zapisanie wszystkich znaków w postaci 8-bitowej (z wyjątkiem nawiasów kątowych i znaku & w treści).

Bezpośredni link do ściągnięcia programu Ace HTML freeware link do str. zewnętrznej.

2.3. Amaya – edytor i przeglądarka HTML konsorcjum W3C

Amaya link do str. zewnętrznej to wieloplatformowy edytor www o dużych możliwościach (HTML, XHTML, CSS, MathML i częściowo SVG) udostępniany na licencji Open Source link do str. zewnętrznej. Edytor ma możliwość zapisania nowo tworzonych dokumentów w trzech kodowaniach: US­-ASCII, ISO-8859-1UTF-8. W przypadku wyboru kodowania zapisywanego dokumentu jako US­-ASCII wszystkie znaki narodowe i specjalne zostaną zapisane jako encje symboliczne (tylko jeżeli dokument zawiera odpowiednią deklarację DOCTYPE) lub szesnastkowe encje numeryczne:

podobnie już przy tworzeniu nowego dokumentu można wybrać odpowiednie kodowanie:

Wyboru domyślnego kodowania tworzonych dokumentów dokonuje się w opcjach: File ⇒ Preferences ⇒ Publishing.

Jeżeli w Amayi edytowany jest już istniejący dokument używający charsetu odmiennego od jednego z trzech powyższych, Amaya zapisze dokument w tym charsecie (np. dokumenty w ISO-8859-2 otwarte w Amayi zachowają ISO-8859-2). Pozwala to obejść niemożność wyboru charsetu ISO-8859-2 dla nowo tworzonych dokumentów: można utworzyć pusty plik jako szablon HTML, zapisać go, ręcznie zmienić w nim deklarację charsetu na ISO-8859-2 i następnie używać tego szablonu do tworzenia nowych stron www, które będą używać kodowania ISO-8859-2 (znaki spoza ISO-8859-2 zostaną zakodowane jako encje).

OBSŁUGA KODOWANIA MIESZANEGO: Gdy przy zapisie wybrany zostanie charset ISO-8859-1, w zapisanym dokumencie znaki obecne w tym charsecie będą zapisane w postaci 8-bitowej, zaś znaki spoza tego charsetu – jako encje unikodowe. W przypadku polskich liter jedynie małe i wielkie o z kreską są obecne w ISO-8859-1, więc rozwiązanie to w przypadku stron www w języku polskim wydaje się mało przydatne, ale będzie użyteczne dla stron zawierających wiele znaków używanych w językach zachodnioeuropejskich. Zmiana UTF-8 na kodowanie mieszane ISO-8859-2 plus encje dla znaków nieistniejących w ISO możliwe jest drogą nieco okrężną: zapisać dany dokument jako US­-ASCII, co spowoduje użycie wyłącznie encji, a następnie ręcznie zmienić deklarację charsetu na ISO-8859-2 i odświeżyć stronę w Amayi. Dokument ten zostanie w efekcie zapisany w tym charsecie (encje określające znaki z tego charsetu zostaną przekodowane do postaci 8-bitowej).

Wybór UTF-8 spowoduje zapisanie wszystkich znaków w postaci 8-bitowej (z wyjątkiem nawiasów kątowych i znaku & w treści).

2.4. Arachnophilia

Arachnophilia link do str. zewnętrznej to darmowy, bardzo prosty edytor dokumentów tekstowych i HTML (niektórzy powiedzieliby: prymitywny), który daje prawie nieograniczone możliwości dostosowania, w tym edycji znaczników HTML wstawianych przez program i dodania wiekszej ilości znaczników, możliwa też jest zmiana szablonu wykorzystywanego dla nowo tworzonych dokumentów HTML. Domyślne ustawienia są zgodne jedynie z wersjami Transitional standardów (X)HTML. Obecnie dostępna jest wersja 5.4 build2411 z 26.10.2009 r. Jest międzyplatformową aplikacją w Javie i wymaga środowiska uruchomieniowego Javy w wersji co najmniej 1.4 link do str. zewnętrznej (chodzi o Javę Sun, nie pseudo-Javę MS, która zresztą jest zbyt stara i tak). Ciekawostką jest, że można doprowadzić kod produkowany przez program do pełnej zgodności nawet z HTML 4.01 Strict lub XHTML 1.1, ale wymaga to stosunkowo dobrej znajomości (X)HTML i spędzenia nieco czasu nad poprawkami szablonów kodu tworzonego przez program. Program obsługuje encje unikodowe numeryczne dziesiętne i niektóre symboliczne, potrafi je konwertować na odpowiednie znaki i vice versa. Lista encji symbolicznych obsługiwanych przez program jest ograniczona do zestawu ISO-8859-1 (HTML 3.2), choć można dodać inne legalne encje symboliczne do listy (plik ExtendedChars.txt w katalogu ustawień. Program nie obsługuje encji szesnastkowych, obecność w kodzie tych encji powoduje, że konwersja nie działa. Program nie obsługuje deklaracji charsetu obecnego w nagłówku.

Przed otwarciem dokumentu należy wybrać jego charset:

Jest to szczególnie ważne, gdyż nie ma możliwości zmiany kodowania użytego do wyświetlenia pliku po jego otwarciu, przez co praca z plikiem będzie uciążliwa, a przeprowadzenie konwersji znaków narodowych na encje lub na inne kodowanie niemożliwa; ewentualny wybór innego charsetu w ww. menu, gdy plik został już otwarty, ma wpływ na kodowanie otwartego pliku podczas jego ponownego zapisywania. Program zapamiętuje ostatni wybrany charset.

W menu brak jest charsetów Windows-1250 i ISO-8859-2, ale można je wybrać wpisując ręcznie w okienko pojawiające się po wybraniu opcji „User Entry”, można też wyedytować menu i dodać te charsety na stałe.

Aby zapisać wszystkie znaki spoza US­-ASCII w postaci encji, z menu HTML należy wybrać „More functions”, gdzie należy wybrać pozycję „Char to entity

Zostanie skonwertowany zaznaczony fragment, a jeżeli żaden fragment nie jest zaznaczony, zostanie skonwertowany cały tekst. Nie należy zaznaczać pojedynczych nawiasów kątowych znaczników HTML, bo nawiasy też mogą zostać skonwertowane do encji (< → &lt; i > → &gt;); zaznaczenie całego znacznika (obu nawiasów kątowych) nie sprawia problemów. Jeżeli dokument zawiera mieszankę encji i znaków narodowych w postaci 8-bitowej, z tego samego menu najpierw należy go przekonwertować z encji do znaków („Entity to char”), w przeciwnym razie encje zostaną popsute.

Program nie obsługuje kodowania mieszanego, próba zapisania dokumentu z użyciem charsetu, w którym nie można zakodować znaków zawartych w treści, skutkuje wyświetleniem komunikatu błędu:
.

2.5. Open Office – zapis w formacie HTML

Edytor pakietu aplikacji biurowych Open Office link do str. zewnętrznej (międzyplatformowy – dla Windows, Linuksa i Mac OS X, bezpłatny na licencji LGPL link do str. zewnętrznej) ma opcję zapisu dokumentu w formacie HTML. Przed zapisem należy otworzyć menu Narzędzia ⇒ Opcje (ang. Tools ⇒ Options) i na pozycji Kompatybilność HTML jako zestaw znaków wybrać zachodnioeuropejski (ASCII/US):

Dzięki temu ustawieniu w zapisanym dokumencie HTML wszystkie znaki spoza US­-ASCII będą zapisane jako encje symboliczne lub numeryczne unikodu.

OBSŁUGA KODOWANIA MIESZANEGO: Open Office zapisuje znaki spoza US­-ASCII jako encje symboliczne, a znaki, które nie posiadają zdefiniowanych encji symbolicznych, albo w postaci 8-bitowej (jeżeli istnieją w wybranym kodowaniu), albo jako encje numeryczne unikodu (jeżeli nie istnieją w tym wybranym kodowaniu). Po wybraniu charsetu 8-bitowego (np. ISO-8859-2) zamiast zachodnioeuropejskiego/ASCII/US otrzymuje się stronę www, w której wszystkie mieszczące się w charsecie zapisywane są w postaci 8-bitowej (z wyjątkiem znaków specjalnych HTML i spacji niełamiacej oraz dywizu warunkowego, któ®e zapisywane są jako encje symboliczne), pozostałe znaki spoza US­-ASCII zapisywane są w postaci encji symbolicznych lub numerycznych dziesiętnych.

Wybór UTF-8 spowoduje zapisanie wszystkich znaków w postaci 8-bitowej (z wyjątkiem nawiasów kątowych i znaku & w treści).

2.6. Unikodowy edytor czystego tekstu i RTF Simredo

Ci, którzy znają tajniki kodu (X)HTML i potrafią pisać skrypty JavaScript, mogą skorzystać z tego programu i od razu zapisywać plik z użyciem właściwych encji numerycznych/ sekwencji. Posiadacze już gotowej strony (lub korzystający z innego programu wspomagającego tworzenie stron www, który nie posiada opcji zapisu znaków spoza US­-ASCII), osoby wykorzystujące gotowe skrypty JavaScript itp., mogą swoje strony i skrypty poddać odpowiedniej konwersji w programie Simredo link do str. zewnętrznej. Jest to program napisany w Javie i jako taki może być uruchomiony na dowolnym systemie operacyjnym (Windows, Linux, MacOS…), na którym jest zainstalowane środowisko uruchomieniowe Javy w wersji co najmniej 1.4 link do str. zewnętrznej. Program jest darmowy i dostępne są źródła (również za darmo i z pozwoleniem na grzebanie w nich). Niestety, nie ma polskiego interfejsu, jedynie angielski, esperanto, francuski, grecki i hinduski. Program działa stosunkowo wolno, co daje się we znaki szczególnie posiadaczom starych komputerów, z procesorem 1 GHz i poniżej, i z małą ilością pamięci.

Otwieraniu pliku typu tekstowego (a więc i pliku typu HTML) towarzyszy wyświetlenie okna dialogowego wyboru kodowania pliku:

Wybór kodowania jest o tyle istotny, że po otwarciu pliku nie ma możliwości jego zmiany, praca na pliku z krzakami będzie niewygodna, a przeprowadzenie konwersji znaków narodowych do encji lub innego kodowania (np. z Windows-1250 do ISO-8859-2 czy ISO-8859-2 do UTF-8 ) niemożliwe. Program obsługuje wiele charsetów, w tym charsety Windows i różne egzotyczne (np. EBCDIC), ale tylko niektóre kodowania rodziny ISO-8859, od 1 do 9 włącznie.

Teraz z menu Other Functions należy wybrać pozycję Conversion:

i w nowo otwartym oknie wybrać rodzaj konwersji: jako tablicę konwersji z górnej listy rozwijanej wybrać EscCodes, jako kodowanie źródła – Unicode (>127), a jako kodowanie docelowe:

Kliknięcie na przycisk Convert spowoduje przekonwertowanie dokumentu w wybrany sposób. Po konwersji należy zamknąć to okno przyciskiem Close.

W wyniku konwersji znaki spoza US­-ASCII zostaną zamienione na właściwe encje/ sekwencje. Nie ma możliwości konwersji części dokumentu (np. osobno skryptów zawartych w dokumencie HTML, a osobno kodu HTML w tym dokumencie).

Podczas zapisu skonwertowanego dokumentu pojawi się okno dialogowe wyboru kodowania, w jakim chce się zapisać dany dokument, ale jest ono bez znaczenia, gdyż w treści nie będzie żadnych znaków spoza US­-ASCII, a domyślnie proponowane jest w nim kodowanie, z jakiego użyciem dany dokument został otwarty. Najbezpieczniej nie zmieniać w nim kodowania (niektóre charsety nie są kompatybilne z US­-ASCII). Nie należy wybierać formatu RTF ani szyfrowania, plik HTML zapisany jako RTF nie będzie wyświetlany przez żadną przeglądarkę www, podobnie zaszyfrowany plik (opcja Encrypted), który dodatkowo będzie mógł być otwarty wyłącznie przez posiadacza hasła.

Wybór UTF-8 spowoduje zapisanie wszystkich znaków w postaci 8-bitowej. Program nie obsługuje kodowania mieszanego, znaki spoza kodowania 8-bitowego wybranego przy zapisywaniu (np. ISO-8859-2) zostaną bez ostrzeżenia zamienione na znaki zapytania.

2.7. Unikodowy edytor czystego tekstu UniRed

Kolejny program pozwalający na przekodowanie dokumentów (X)HTML i skryptów to UniRed (tylko dla Windows, bezpłatny na licencji GNU GPL link do str. zewnętrznej – licencja GNU GPL przetłumaczona na język polski link do str. zewnętrznej): jeżeli konwertuje się plik już istniejącej strony lub plik ze skryptem, należy go otworzyć ustawiając jednocześnie jego kodowanie (w przypadku stron www i plików js w języku polskim będzie to zwykle ISO-8859-2, choć nowo pisane strony względnie skrypty tworzone pod Windowsem, np. w jakimś programie nie obsługującym kodowań lub ewentualnie systemowym Notatniku, równie dobrze mogą być jeszcze nieprzekonwertowane i należy wówczas wybrać kodowanie Windows-1250):

Program umożliwia zmianę charsetu wyświetlanego dokumentu już po jego otwarciu: z menu Plik należy wybrać Właściwości, a następnie z listy rozwijanej „Zestaw znaków” wybrać właściwe kodowanie:

Wybór właściwego kodowania jest niezbędny do tego, by znaki spoza US­-ASCII mogły być prawidłowo zakodowane jako encje.

Po upewnieniu się, że zostało wybrane prawidłowe kodowanie:

UniRed ma wbudowany interpreter encji/ sekwencji, dzięki czemu potrafi wyświetlić te kody jako znaki przez nie reprezentowane, ale potrafi na raz użyć tylko jednego interpretera (nie potrafi wyświetlić jednocześnie znaków reprezentowanych przez encje HTML i sekwencje JavaScript). Można wybrać interpretację unikodu w oknie Właściwości (z menu Plik), z listy rozwijanej „Reprezentacja unikodu”:

W tym samym oknie można zmienić kodowanie dokumentu, jeżeli przy otwarciu wybrało się nieprawidłowy charset (z listy rozwijanej „Zestaw znaków”).

Ponieważ konwersja na encje/ sekwencje odbywa się podczas zapisywania dokumentu, nie ma możliwości przeprowadzenia osobno konwersji skryptów osadzonych w dokumencie HTMl do sekwencji JavaScript i osobno treści dokumentu HTML do encji HTML.

Ściągnij UniRed link do str. zewnętrznej, polecam również poprawiony przeze mnie polski plik językowy (instrukcja instalacji znajduje się w archiwum, w pliku readme.txt). Program może również służyć jako uniwersalny, wszechstronny konwerter między różnymi kodowaniami. Oryginalnie program nie obsługuje charsetów Mazovia ani ISO-8859-16, przygotowałem więc odpowiednie tablice konwersji (instrukcja instalacji znajduje się w archiwum, w pliku readme.txt). Program ma możliwość sprawdzania pisowni w różnych językach, w tym języka polskiego – korzysta ze słowników Ispella. Niestety nie znam podobnego narzędzia pod Linuksa ani pod Mac OS X (choć z pewnością istnieje).

UniRed bezpośrednio po instalacji nie obsługuje encji symbolicznych (np. &oacute;) – ani ich nie zapisuje, ani ich nie interpretuje w otwieranym dokumencie (X)HTML. Przygotowany został plik, który należy rozpakować do podkatalogu INI katalogu instalacyjnego programu (zastępując już tam istniejący plik o tej samej nazwie). Po tym możliwa będzie konwersja encji symbolicznych do postaci 8-bitowej (wybierając HTML z listy rozwijanej surogatów w oknie Otwórz plik oraz Właściwości), a także zapisanie znaków spoza US­-ASCII jako mieszanki encji symbolicznych i dziesiętnych (również wybierając HTML z listy rozwijanej surogatów w oknie Zapisz jako – należy tu pamiętać, że przy zapisie w kodowaniu 8-bitowym należy koniecznie również wybrać &#DDDD; z listy rozwijanej Reprezentacja unikodu, inaczej znaki spoza wybranego kodowania, dla których nie istnieją encje symboliczne, zostaną bez ostrzeżenia zamienione na znaki zapytania). Plik przekodowań encji symbolicznych celowo nie zawiera encji reprezentujących znaki specjalne (X)HTML & < > " oraz ' – w otwieranych dokumentach encje te nie zostaną zamienione na reprezentowane przez nie znaki (jeżeli jednak do zakodowania ich użyto encji numerycznych dziesiętnych, zostaną one w dalszym ciągu zamienione na znaki).

OBSŁUGA KODOWANIA MIESZANEGO: UniRed posiada możliwość zapisu dokumentów z kodowaniem mieszanym: znaki z danego charsetu 8-bitowego zapisywane są w postaci 8-bitowej, znaki spoza charsetu jako encje numeryczne (lub encje symboliczne plus numeryczne). Aby osiągnąć ten efekt należy w oknie dialogowym zapisu pliku wybrać żądany zestaw znaków (np. ISO-8859-2) oraz reprezentację unikodu jako &#DDDD; (plus ewentualnie surogat jako HTML). Dzięki temu możliwe jest otrzymanie dokumentu, w którym znaki obecne w wybranym charsecie (np. ISO-8859-2) będą zapisane w postaci 8-bitowej, zaś znaki spoza tego charsetu – jako encje numeryczne (względnie jako encje symboliczne dla znaków, dla których istnieją, plus encje numeryczne dziesiętne dla pozostałych znaków spoza charsetu).

Wybór UTF-8 wraz z brakiem reprezentacji unikodu (-) spowoduje zapisanie wszystkich znaków w postaci 8-bitowej. Wybranie kodowania 8-bitowego w połączeniu z brakiem reprezentacji unikodu spowoduje, że znaki spoza tego kodowania 8-bitowego zostaną bez ostrzeżenia zamienione na znaki zapytania.

2.8. Unikodowy edytor czystego tekstu BabelPad

Podobnie do dwóch poprzednich programów działa BabelPad link do str. zewnętrznej (tylko dla Windows, licencja freeware), którego można użyć albo jako edytora czystego tekstu do ręcznego kodowania strony www i skryptów, albo jako uniwersalnego konwertera kodowań. Podczas otwarcia już istniejącego pliku HTML należy wybrać właściwe kodowanie otwieranego dokumentu:

Wybór kodowania jest o tyle istotny, że po otwarciu pliku nie ma możliwości jego zmiany, praca na pliku z krzakami będzie niewygodna, a przeprowadzenie konwersji znaków narodowych do encji/ sekwencji lub UTF-8 niemożliwe.

Następnie dokument należy zapisać, znów wybierając odpowiednie kodowanie:

Po zaznaczeniu fragmentu tekstu dostęp do wyboru formatu konwersji jest też z menu kontekstowego:

BabelPad potrafi otwierać dokumenty w bardzo wielu kodowaniach, w tym wszystkie kodowania ISO-8859 i Windows, liczne kodowania DOS i dalekowschodnie, ale zapisuje tylko w unikodzie jako UTF-16, UTF-8, z lub bez BOM, oraz US­-ASCII plus encje w jednej z kilku wersji. Stąd nie ma możliwości zapisania dokumentu w kodowaniu mieszanym.

Edytor BabelPad zawiera wbudowaną tablicę znaków dostępną m.in. z klawiatury CTRL+M, która pozwala na wygodne wstawienie dowolnego znaku.

2.9. Konwerter Gżegżółka

Gżegżółka link do str. zewnętrznej (tylko na Windows, licencja shareware) pozwala na zmianę sposobu kodowania m.in. plików HTML wraz ze zmianą deklaracji charsetu w nagłówku. Obsługuje wszystkie kodowania oficjalne – całych stron kodowych, nie tylko polskich liter – i wiele archaicznych (Mazovia i inne…). Od wersji 7.1.1.1 Gżegżółka posiada również konwerter na sekwencje JavaScriptu. Konwerter ten instaluje się pod warunkiem wybrania instalacji wszystkich plików obsługi standardów. Korzystanie polega na wybraniu z lewej listy rozwijanej kodowania pliku źródłowego (program ma niespotykaną w innych programach opcję wyboru kodowania mieszanego polskich liter: ISO+Windows, to jest kodowanie Windows-1250, w którym 3 małe i 3 wielkie polskie litery ą, ś i ź znajdują się na pozycjach właściwych dla Windows-1250ISO-8859-2, czyli zadziała z polskim tekstem w jednym i drugim kodowaniu, a nawet pomieszanym, czyli część w ISO, część w Windows; nie należy stosować tej opcji, gdy tekst zawiera litery innych języków środkowoeuropejskich, np. czeskiego, słowackiego), a z prawej listy rozwijanej kodowania docelowego – w przypadku plików (X)HTML interesująca nas opcja nazywa się Unicode – encje:

W przypadku konwersji plików JavaScript z prawej listy rozwijanej należy wybrać opcję o nazwie Unicode – sekwencje escape:

Prawidłowy wybór kodowania pliku wyjściowego ma decydujące znaczenie dla poprawności konwersji i jest warunkiem, by plik wynikowy był wyświetlany poprawnie. Autor nie dodał rozszerzenia .js do listy obsługiwanych plików, można to uczynić za niego z menu Narzędzia ⇒ Opcje ⇒ zakładka Typy plików, dopisując js do listy rozszerzeń obsługiwanych (np. HTML albo tekst).

OBSŁUGA KODOWANIA MIESZANEGO: Gżegżółka posiada możliwość zapisu dokumentów z kodowaniem mieszanym: znaki z danego charsetu 8-bitowego zapisywane są w postaci 8-bitowej, znaki spoza charsetu jako encje numeryczne. Aby osiągnąć ten efekt należy w opcjach zaznaczyć „Podstawiaj encje (np. &oacute;) za nieobsługiwane znaki”:

Dzięki temu możliwe jest otrzymanie dokumentu, w którym np. znaki obecne w charsecie ISO-8859-2 będą zapisane w postaci 8-bitowej, zaś znaki spoza tego charsetu – jako encje unikodowe.

Programy Simredo, UniRed, BabelPad i Gżegżółka można również wykorzystać do konwertowania treści maili i postów, jeżeli używany czytnik nie obsługuje jakiegoś kodowania i wyświetla w treści krzaki (ale nie można wykorzystać, gdy czytnik konwertuje nieobsługiwane znaki na znaki zapytania lub puste miejsca). W program UniRed można wkleić taki tekst, a następnie w oknie właściwości (dostępnym z menu Plik) próbować zmienić kodowanie na takie, w którym litery ze znakami diakrytycznymi w treści będą wyglądać prawidłowo:

2.10. Tidy – narzędzie do poprawiania kodu HTML

Opis dotyczy wersji z 11 lutego 2007 i późniejszych.

Tidy link do str. zewnętrznej służy do automatycznego poprawiania kodu HTML. Więcej informacji można znaleźć na stronie w języku polskim link do str. zewnętrznej i na stronie programu (w języku angielskim). Uruchomienie programu z przełącznikiem  -?  spowoduje pokazanie skróconej listy przełączników, które rozumie program, i ich opisy (w języku angielskim), pełną listę opcji można uzyskać uruchamiając program z przełącznikiem  -help-config . Program ingeruje w kodowanie znaków i nie rozpoznaje deklaracji charsetu w nagłówku, przez co konieczne jest staranne dobranie przełączników programu (lub opcji w pliku konfiguracyjnym) w zależności od sposobu kodowania znaków narodowych i specjalnych w dokumencie. Można by wykorzystać Tidy do konwersji kodowania, ale niestety program nie obsługuje bezpośrednio ISO-8859-2 – ani większości charsetów poza zachodnioeuropejskimi, azjatyckimi i unikodem – co w niewielkim stopniu ogranicza jego użyteczność dla polskiego języka, głównie uniemożliwiając uzyskanie kodowania mieszanego ISO-8859-2 plus encje i konwertowanie ISO-8859-2 do encji lub UTF-8. Na początek w skrócie zostaną przedstawione najczęstsze przypadki i przełączniki gwarantujące, że polskie litery (ani inne znaki narodowe) nie zostaną zepsute; pełna lista przełączników w dalszej części paragrafu.

Dobór przełączników w zależności od zawartości znaków i sposobu ich kodowania w dokumencie oryginalnym oraz od zamierzonego sposobu kodowania ich w dokumencie wynikowym przedstawia poniższa tabela (więcej o przełącznikach w dalszej części tekstu poniżej tabeli):

Zawartość znaków i ich kodowaniePrzełączniki
Plik źródłowyPlik wynikowy
ISO-8859-2 8-bit plus encje dla znaków spoza ISO 1)ISO-8859-2 8-bit plus encje dla znaków spoza ISO  -raw --preserve-entities yes 
ISO-8859-2 8-bit bez encji 2)ISO-8859-2 8-bit  -raw 
encjeencje przełącznik nie jest wymagany
encje, UTF-8 8-bit lub mieszanka UTF-8 8-bit plus encjiUTF-8 8-bit  -utf8 
UTF-8 8-bit (lub mieszanka UTF-8 8-bit plus encji)wyłącznie encje  --input-encoding utf8 
Inne kombinacje, raczej niespotykane w polskich warunkach (wybór)
ISO-8859-1 8-bit lub mieszanka ISO-8859-1 8-bit plus encjiISO-8859-1 8-bit plus ewentualne encje  -latin1 
ISO-8859-1 8-bit lub mieszanka ISO-8859-1 8-bit plus encjiUTF-8 8-bit  --output-encoding utf8 
ISO-8859-1 8-bit lub mieszanka ISO-8859-1 8-bit plus encjiencje  -ascii 
Kombinacje niemożliwe do uzyskania (wybór)
encje lub UTF-8 8-bit (lub UTF-8 8-bit plus encje)ISO-8859-2 8-bit plus ewentualne encje
ISO-8859-2 8-bit (lub mieszanka ISO-8859-2 8-bit plus encji)cokolwiek odmiennego, np. UTF-8 8-bit lub tylko encje

___________________________

1) Również dla mieszanki każdego innego charsetu 8-bitowego nieobsługiwanego przez Tidy plus encji
2) Dopuszczalne jedynie encje symbolizujące znaki z pozycji unikodu 255 i poniżej, np. &amp; &#38; &nbsp; &#160;

Poniżej podana jest lista przełączników związanych z obsługą znaków narodowych i specjalnych. Logiczne w  linii możliwe wartości oznacza, że przełącznik może przyjąć jedną z dwóch wartości logicznych. Logiczna prawda to yes, y, true, t, 1. Logiczny fałsz to no, n, false, f, 0.

Działanie wybranych przełączników definiujących charset pliku źródłowego i wynikowego zostało przedstawione w poniższej tabeli:

WartośćPlik źródłowy
 --input-encoding 
Plik wynikowy
 --output-encoding 
 ascii  Znaki 8-bitowe są traktowane jako należące do charsetu ISO-8859-1 (znaki o numerach 128 – 159 spowodują wygenerowanie ostrzeżenia, ale zostaną faktycznie zinterpretowane jako należące do Windows-1252 i wewnętrznie przekonwertowane do odpowiednich znaków unikodu)Wszystkie znaki spoza US­-ASCII zapisane jako encje
 latin1  Znaki należące do ISO-8859-1 zapisane w postaci 8-bitowej, znaki spoza ISO-8859-1 (w tym znaki z zakresu 128 – 159 obecne w pliku źródłowym) zapisane jako encje
 raw  Program nie interpretuje zawartości dokumentu, ale gdy musi przekonwertować zawartość do innego charsetu, zakłada, że użyty charset to Windows-1252Program nie ingeruje w kody znaków 8-bitowych, ale zmienia encje reprezentujące znaki spoza ISO-8859-1 na niezrozumiałe znaki 8-bitowe (młodszy bajt kodu UTF-16 znaku)
 utf8  Znaki 8-bitowe są traktowane jako zakodowane w UTF-8. Nielegalne sekwencje (np. znaki zakodowane w rzeczywistości w ISO) będą zmienione na znaki zastępcze (&#65533; zwykle negatywowy pytajnik: �)Dokument będzie zapisany w kodowaniu UTF-8
 latin0  Znaki 8-bitowe są traktowane jako należące do charsetu ISO-8859-15 (znaki o numerach 128 – 159 spowodują wygenerowanie ostrzeżenia, ale zostaną faktycznie zinterpretowane jako należące do Windows-1252 i wewnętrznie przekonwertowane do odpowiednich znaków ISO-8859-15 lub unikodu)Znaki należące do ISO-8859-15 zapisane w postaci 8-bitowej (w tym 8 znaków reprezentowanych w pliku źródłowym kodami z zakresu 128 – 159), znaki spoza ISO-8859-15 (w tym 19 znaków z zakresu 128 – 159 obecnych w pliku źródłowym, które nie istnieją w ISO-8859-15) powinny być zapisane jako encje, ale z powodu buga są psute jak w przypadku raw
 win1252  Znaki 8-bitowe są traktowane jako należące do charsetu Windows-1252Znaki należące do Windows-1252 zapisane w postaci 8-bitowej, znaki spoza Windows-1252 powinny być zapisane jako encje, ale z powodu buga są psute jak w przypadku raw

Domyślnie program zakłada ISO-8859-1 (latin1) dla pliku źródłowego, US­-ASCII (ascii) dla pliku wynikowego. Praktycznie zadziała poprawnie również gdy plik źródłowy jest kodowany Windows-1252 (zawiera znaki o numerach 128 – 159), jedynie wygeneruje odpowiednią ilość komunikatów o błędach (jeden znak z tego zakresu – jeden błąd), ale znaki te prawidłowo zinterpretuje i przekonwertuje do innego charsetu lub prawidłowych encji. Znaki w pliku źródłowym, których nie można zapisać w charsecie pliku docelowego, zostaną zapisane jako encje. Oznacza, że zbędne jest stosowanie przełączników  -ascii ,  --input-encoding ascii ,  --input-encoding latin1  --output-encoding ascii . Pomyłkowe pominięcie  --input-encoding win1252  również nie powoduje większych problemów.

Jeżeli obie definicje są jednakowe, istnieje możliwość użycia skróconej formy definicji w linii poleceń. Np. zamiast pisać  --input-encoding raw --output-encoding raw  można wpisać krótko  -raw . Działa to dla powyższych charsetów z wyjątkiem Windows-1252ISO-8859-15 – wpisanie  -win1252  każe programowi zapisać plik wynikowy w kodowaniu US­-ASCII plus encje, czyli odpowiednik  --input-encoding win1252 --output-encoding ascii , analogicznie wpisanie  -latin0  każe programowi zapisać plik wynikowy w kodowaniu US­-ASCII plus encje, czyli odpowiednik  --input-encoding latin0 --output-encoding ascii .

W przypadku dokumentów zawierających znaki spoza ISO-8859-1 (np. polskie znaki) użycie wartości  raw  tylko jako charset pliku wynikowego w większości przypadków skutkuje zepsuciem tych znaków. Użycie wartości  raw  jako kodowania pliku źródłowego w połączeniu z wyborem innego kodowania pliku wynikowego (np. UTF-8) spowoduje potraktowanie wszystkich znaków spoza US­-ASCII jako należących do Windows-1252.

W przypadku użycia opcji  -raw  do sprawdzenia dokumentu zawierającego encje w miejsce encji symbolizujących znaki z pozycji unikodu powyżej 255 Tidy wstawia mniej znaczący bajt kodu danego znaku w UTF-16 (np. encja &euro;, symbolizująca znak € o numerze U+20AC, zostanie zastąpiona znakiem 8-bitowym U+AC). Od wersji z 17.02.2007 można temu zapobiec używając dodatkowego przełącznika  --preserve-entities yes . Należy pamiętać, że tylko prawidłowe encje HTML są zachowywane, niepoprawne technicznie wynalazki MS – pseudoencje typu &#128;, &endash; czy &#150; (numer encji między 128 a 159) będą potraktowane tak, jakby ten przełącznik nie został użyty.

Algorytm programu dotyczący wyboru rodzaju encji (symboliczne czy numeryczne) nie jest mi do końca znany, generalnie zależy od typu dokumentu. Można wymusić używanie wyłącznie encji numerycznych przełącznikiem  -n . Jedynie znaki mające specjalne znaczenie w HTML: &, <, > i " będą zapisane jako encje symboliczne (&amp;, &lt;, &gt; i &quot;).

Program może również brać ustawienia z pliku konfiguracyjnego. Jest to zwykły plik tekstowy, w którym w osobnych liniach wpisuje się przełączniki (bez poprzedzających minusów) i po dwukropku odpowiednie wartości tych przełączników. Można dzięki temu ułatwić sobie życie wywołując plik konfiguracyjny zamiast wpisywania wszystkich przełączników z palca w linii poleceń. Przykładowa zawartość pliku zawierającego zalecane przeze mnie ustawienia, zapewniająca poprawne traktowanie polskich liter i innych znaków narodowych i specjalnych niezależnie od kodowania, jest zamieszczona poniżej:
Powyższe można zapisać w pliku tekstowym o nazwie np. konf.txt, po czym można prosto użyć Tidy z odpowiednimi parametrami uruchamiając z następującymi atrybutami:  tidy -o <plik wynikowy> -config konf.txt <plik źródłowy> .

Program nie rozumie encji SGML typu &aogon; niebędących częścią standardu (X)HTML ani błędnych encji MS dla pauzy i półpauzy (&emdash;, &endash;). O ile nie wyłączono opcji poprawiania samotnie występującej etki (znaku &), występujące w nich te znaki zostaną prawidłowo zastąpione encjami &amp; (&amp;aogon;, &amp;emdash;, &amp;endash;).

Osoby piszące swoje strony w kiepskich edytorach HTML mogą spróbować użyć przełącznika  -c  oraz  --fix-backslash yes , używające MS Worda do tego celu – dodatkowo  --word-2000 yes . Dzięki temu kod będzie bardziej przypominał HTML i będzie strawny dla większej ilości przeglądarek.

Problemy opisane powyżej zostały zgłoszone: bug z raw, bug z kodowaniem, obsługa ISO-8859-2.

2.11. Internet Explorer i Notatnik Windows – funkcja „Zapisz jako…”

Internet Explorer może zmienić kodowanie strony zapisywanej lokalnie:

Można wybrać dowolne kodowanie docelowe obsługiwane przez IE. Znaki nieistniejące w kodowaniu docelowym zostaną zastąpione encjami. Ponieważ kodowanie US­-ASCII nie jest dostępne, aby zastąpić polskie litery encjami, należy wybrać jakieś kodowanie, w którym nie ma żadnych znaków spoza ASCII użytych na stronie (KOI8-R wydaje się dawać dobre rezultaty). Jednocześnie przestrzegam tu przed użyciem tej funkcji z następujących powodów:

Można również użyć tej funkcji do konwertowania kodowania plików tekstowych – należy tylko pamiętać, że mimo wybrania ISO-8859-1 (czyli „Western European (ISO)”) plik zostanie zapisany w kodowaniu Windows-1252 („Western European (Windows)”), a także że znaki nieistniejące w kodowaniu docelowym zostaną zapisane jako encje. Dodatkowo należy pamiętać, by po otwarciu pliku tekstowego w IE sprawdzić poprawność wyświetlania polskich liter i ewentualnie zmienić kodowanie na właściwe. Pliki tekstowe w języku polskim najczęściej są kodowane w Windows-1250.

Konwertując na unikod, należy koniecznie pamiętać o wybraniu UTF-8 jako kodowania docelowego. Unikod jako taki w slangu MS oznacza UTF-16LE bez BOM i generalnie należy unikać tego kodowania.

Systemowy Notatnik w Windows 2000, XP i nowszych również umożliwia wybór kodowania, ale jego możliwości są jeszcze bardziej ograniczone, a problemy większe: nie ma możliwości wyboru kodowania otwieranego pliku, obsługiwane kodowania ograniczają się tylko do systemowego kodowania Windows i UTF-8 (oraz dwóch odmian UTF-16), do tego Notatnik zapisując plik w kodowaniu UTF-8 dodaje BOM, czyli znacznik użytego kodowania. Znacznik ten jest niewidoczny w Notatniku, ale jest widoczny w innych programach i może zakłócać wyświetlanie stron internetowych. W przypadku konwertowania z unikodu na Windows-1250 („ANSI” w slangu MS) znaki nieobecne w kodowaniu Windows zostaną zastąpione albo jakimiś lepiej lub gorzej (głównie gorzej…) dobranymi odpowiednikami (np. £ ⇒ L) lub znakami zapytania, przy czym konwertowanie do tych żałosnych odpowiedników odbywa się bez ostrzeżenia.

3. Kody polskich liter i znaków specjalnych

Li­te­ra(X)HTMLJava­ScriptCSS ²)
encja dzie­siętnaencja hexencja sym­bo­licznaencje błędnesekwen­cje po­praw­nesekwen­cje błędne
ISO/IEC 8879inne błędne
ą&#261;&#x105;&aogon;&#177; &#185; &#xB1; &#xB9; &plusmn; &sup1;\u0105\xB1 \u00B1 \xB9 \u00B9\000105
ć&#263;&#x107;&cacute;&#230; &#xE6; &aelig;\u0107\xE6 \u00E6\000107
ę&#281;&#x119;&eogon;&#234; &#xEA; &ecirc;\u0119\xEA \u00EA\000119
ł&#322;&#x142;&lstrok;&#179; &#xB3; &sup3;\u0142\xB3 \u00B3\000142
ń&#324;&#x144;&nacute;&#241; &#xF1; &ntilde;\u0144\xF1 \u00F1\000144
ó&#243;&#xF3;&oacute;\u00F3 \xF3\0000F3
ś&#347;&#x15B;&sacute;&#182; &#156; &#xB6; &#x9C; &pilcrow; &oelig;\u015B\xB6 \u00B6 \x9C \u009C\00015B
ź&#378;&#x17A;&zacute;&#159; &#182; &#xBC; &#x9F; &Yuml; &frac14;\u017A\xBC \u00BC \x9F \u009F\00017A
ż&#380;&#x17C;&zdot;&#191; &#xBF; &iquest;\u017C\xBF \u00BF\00017C
Ą&#260;&#x104;&Aogon;&#161; &#165; &#xA1; &#xA5; &iexcl; &yen;\u0104\xA1 \u00A1 \xA5 \u00A5\000104
Ć&#262;&#x106;&Cacute;&#198; &#xC6; &AElig;\u0106\xC6 \u00C6\000106
Ę&#280;&#x118;&Eogon;&#202; &#xCA; &Ecirc;\u0118\xCA \u00CA\000118
Ł&#321;&#x141;&Lstrok;&#163; &#xA4; &pound;\u0141\xA4 \u00A4\000141
Ń&#323;&#x143;&Nacute;&#209; &#xD1; &Ntilde;\u0143\xD1 \u00D1\000143
Ó&#242;&#xF2;&Oacute;\u00F2 \xF2\0000F2
Ś&#346;&#x15A;&Sacute;&#140; &#166; &#xA6; &#x8C; &brvbar; &OElig;\u015A\xA6 \u00A6 \x8C \u008C\00015A
Ź&#377;&#x179;&Zacute;&#143; &#172; &#xAC; &#x8F; &not;\u0179\xAC \u00AC \x8F \u008F\000179
Ż&#379;&#x17B;&Zdot;&#175; &#xAF; &macr;\u017B\xAF \u00AF\00017B
Znak(X)HTMLJava­ScriptCSS
encja dzie­siętnaencja hexencja sym­bo­licznaencje błędnesekwen­cje po­praw­nesekwen­cje błędne
&#8211;&#x2013;&ndash;&#150; &#x96; &endash;\u2013\x96 \u0096\002013
&#8212;&#x2014;&mdash;&#151; &#x97; &emdash;\u2014\x97 \u0097\002014
&#8222;&#x201E;&bdquo;&#132; &#x84;\u201E\x84 \u0084\00201E
&#8221;&#x201D;&rdquo;&#148; &#x94;\u201D\x94 \u0094\00201D
&#8217;&#x2019;&rsquo;&#146; &#x92;\u2019\x92 \u0092\002019
&#8230;&#x2026;&hellip;&#133; &#x85;\u2026\x85 \u0085\002026
&#8240;&#x2030;&permil;&#137; &#x89;\u2030\x89 \u0089\002030
&#8226;&#x2022;&bull;&#149; &#x95;\u2022\x95 \u0095\002022
&#8249;&#x2039;&lsaquo;&#139; &#x8B;\u2039\x8B \u008B\002039
&#8250;&#x203A;&rsquo;&#154; &#x9B;\u203A\x9B \u009B\00203A
&#8224;&#x2020;&dagger;&#134; &#x86;\u2020\x86 \u0086\002020
&#8225;&#x2021;&Dagger;&#135; &#x87;\u2021\x87 \u0087\002021
&#8482;&#x2122;&trade;&#153; &#x99;\u2122\x99 \u0099\002122
&#8364;&#x20AC;&euro;&#128; &#x80;\u20AC\x80 \u0080\0020AC
¢&#162;&#xA2;&cent;\u00A2 \xA2\0000A2
£&#163;&#xA3;&pound;\u00A3 \xA3\0000A3
<&#60;&#x3C;&lt;\u003C \x3C\00003C
>&#62;&#x3E;&gt;\u003E \x3E\00003E
«&#171;&#xAB;&laquo;\u00AB \xAB\0000AB
»&#187;&#xBB;&raquo;\u00BB \xBB\0000BB
"&#34;&#x22;&quot;\" \u0022 \x22\" \000022
'&#39;&#x27;(&apos;)¹)(&apos;) ¹)\' \u0027 \x27\' \000027
&&#38;&#x26;&amp;²)²)

_________
¹) Encja symboliczna „&apos;” dla apostrofu prostego zdefiniowana i poprawna jest wyłącznie w XHTML, nie jest obsługiwana przez Internet Explorer (który nie obsługuje XHTML nawet w najnowszej wersji 7). Nie należy jej stosować w dokumentach HTML 4, gdzie jest niepoprawna.

²) Etka nie wymaga eskejpowania w JS ani CSS.

³) Pominięty został zapis alternatywny sekwencji bez wiodących zer, ale z dodaną spacją na końcu, np. \0000AB może być zapisane jako \AB . Z powrotem.

Uwaga do rubryki „ISO/IEC 8879” w części poświęconej polskim literom: co prawda norma ISO/IEC 8879 definiuje encje symboliczne dla ogromnej ilości znaków, w tym znaków języka polskiego (i z tego powodu teoretycznie encje symboliczne w rubryce ISO/IEC 8879 są technicznie prawidłowe pod pewnym względem), nie są one jednak częścią żadnego standardu (X)HTML oraz nie są obsługiwane przez prawie żadne przegladarki www (ze znanych mi jedynie tekstowe przeglądarki Lynx i Links oraz przeglądarka-część edytora WWW autorstwa W3C Amaya je obsługują) i nie należy ich stosować w dokumentach (X)HTML.

Uwaga do rubryk „inne błędne” (w części poświęconej polskim literom), „encje błędne” (w części poświęconej znakom specjalnym) i „sekwencje błędne” (w rubryce JavaScriptu): zaprezentowane tam kody mogą być wstawiane przez oprogramowanie: źle skonfigurowane, ustawione na sztywno na traktowanie wszystkich znaków narodowych jako należących do charsetu ISO-8859-1 albo Windows-1252 lub źle napisane. Obecność tych znaków na stronie względnie w skrypcie JS w miejscu, w którym oczekiwane są polskie litery lub znaki specjalne, spowoduje, że widoczne będą krzaki. Błędne kody znaków specjalnych to są pseudoencje Windows-1252 wynalezione przez MS, nigdzie nie unormowane i nieobsługiwane przez dużą ilość przeglądarek (zwłaszcza pracujących pod systemami innymi niż Windows). Z jakiegoś powodu (najprawdopodobniej ignorancji) niektórzy producenci oprogramowania upierają się przy stosowaniu tych kodów, często myląc użytkowników przez nazywanie tego pseudokodowania terminami typu „ISO kompatybilne z Windows” lub wręcz fałszywie deklarując, że to jest ISO-8859-1. Użycie tych pseudoencji spowoduje, że użytkownicy wielu przeglądarek zobaczą znaki zapytania albo wręcz strona będzie dla nich nieczytelna. To samo dotyczy zresztą też błędnych encji numerycznych dla niektórych polskich liter z kodowania Windows-1250, z zakresu 128 – 159 włącznie. W przypadku JavaScriptu błędne pseudosekwencje znaków specjalnych nie są pokazywane nawet przez IE. Błędne kody są wyłącznie przykładami i nie wyczerpują wszystkich możliwości, w szczególności pominięte zostały kody niekompletne (np. encje HTML bez kończącego średnika albo sekwencje JavaScriptu, w których pominięto wiodące zera). Brak też przykładów błędnych sekwencji CSS, gdyż zarówno pole zastosowań sekwencji CSS jest bardzo wąskie i przeciętny autor stron www najprawdopodobniej nigdy ich nie użyje, jak również są one analogiczne do błędnych sekwencji unikodowych JavaScriptu.

Kody innych liter można sprawdzić w bazie danych liter link do str. zewnętrznej, choć należy pamiętać, że na tej stronie kody podawane są w formacie dziesiętnym, co wymaga przeliczenia w przypadku chęci użycia danego znaku w kodzie JavaScriptu lub w arkuszu stylów. Inne źródło to zbiór znaków, dla których istnieją encje symboliczne link do str. zewnętrznej.

Inny typowy błąd: brak średnika kończącego encję, np. &euro zamiast &euro; (typowy błąd pewnego oprogramowania autorstwa MS). Mimo że niektóre przeglądarki radzą sobie z wyświetleniem encji niezakończonych średnikiem, gdy po takiej niedokończonej encji jest spacja, znak tabulacji lub jakiś znak przestankowy, nie jest to bynajmniej regułą i należy zwracać uwagę na ten błąd.

Z szeroko dostępnych raportów i mojego doświadczenia wynika, że współczesne przeglądarki z ostatnich kilku lat, wypuszczone powiedzmy w okolicach 2000 lub później, radzą sobie z każdym z ww. rodzajów kodowania (na białym tle). Niektóre starsze wersje (sprzed być może 1998 roku) często nie obsługują encji hex. Jeszcze starsze przeglądarki albo w ogóle nie obsługują encji (Internet Explorer 3, Netscape Navigator 3 i wcześniejsze), albo obsługują z błędami lub problemami (np. Netscape Navigator 4 obsługuje pod warunkiem zadeklarowania dla strony charsetu UTF-8). Wśród polskich internautów udział tych najstarszych przeglądarek jest praktycznie zerowy.

3.1. Znacznie obszerniejsza lista encji i sekwencji

Lista znajduje się na osobnej stronie link prowadzi do podstrony

4. Usuwanie polskich liter z treści

W pewnych warunkach, na przykład gdy wśród docelowych odbiorców sporą grupę stanowią osoby zamieszkałe za granicą i nie mogące dokonać zmian w konfiguracji swoich systemów ani przeglądarek (korzystający ze służbowych komputerów, z kafejek lub z czyjejś uprzejmości) lub będące wyjątkowymi antytalentami technicznymi, można zaoferować alternatywne wersje stron pozbawione polskich liter. Niestety, w przeciwieństwie do np. języka niemieckiego, w polskim nie przyjął się żaden sposób transliteracji znaków spoza US­-ASCII na znaki łacińskie. Zwykłe zastępowanie polskich liter ich łacińskimi formami bazowymi czasem prowadzi do nieporozumień (słynne robienie komuś łaski…).

W sieci dostępnych jest kilka narzędzi, przy pomocy których można z treści automatycznie usunąć polskie litery. Dla Windows są to: Notesik link do str. zewnętrznej, Notatnik+ link do str. zewnętrznej, Anty-ogon link do str. zewnętrznej (wersja nie wymagająca .NET Framework jest na stronie „Wszystkie programy”) i Ogonki 97 link do str. zewnętrznej, wszystkie wymienione programy są freeware. Shareware’owy konwerter Gżegżółka link do str. zewnętrznej również posiada tę umiejętność. Notesik i Notatnik+ konwertują tylko polskie litery, Gżegżółka i Ogonki 97 konwertują również inne litery łacińskie ze znakami diakrytycznymi (w przypadku Ogonków konieczne jest zaznaczenie używania pełnych tablic konwersji).

Dawno temu proponowano m.in., by polskie litery zastępować podwojonymi łacińskimi (np. łabędź → llabeedzz, żółw → zzoollw). Inne proponowane kiedyś systemy transliteracji polskich liter, a także formalną normę, prezentuje poniższa tabelka:

LiteraKonwencja ciachowaKonwencja symbolicznaRFC 1345 link do str. zewnętrznej
ą\aa,a;
ć\cc'c'
ę\ee,e;
ł\ll/l/
ń\nn'n'
ó\oo'o'
ś\ss's'
ź\\zz'z'
ż\zz*z.

5. Gdzie nie stosować polskich liter i jak zapewnić poprawność techniczną odsyłaczy

Należy bezwzględnie unikać stosowania polskich liter (i innych znaków narodowych i specjalnych spoza US­-ASCII) w nazwach plików i katalogów będących częścią witryny www lub do których podaje się innym odsyłacze. Najbezpieczniej w dzisiejszych czasach ograniczyć się do liter łacińskich (oraz cyfr i paru znaków innych, wymienionych na dole). Ograniczenie to oparte jest na dwóch potencjalnych problemach:

  1. Konieczność zapewnienia prawidłowości technicznej odsyłacza oraz brak możliwości zapewnienia ze 100% pewnością tego samego kodowania polskich liter w nazwie pliku, w odsyłaczu i w programie osoby pobierajacej ten plik.
  2. Brak możliwości otwarcia pliku, w którego nazwie występują znaki narodowe i specjalne, których nie ma w stronie kodowej systemu używanego przez osobę, która ten plik pobrała.

Znaki w nazwie pliku udostępnianego w internecie muszą być dozwolone do użycia w linkach internetowych. RFC 2396  link do str. zewnętrznej w p-cie 2 wymienia znaki, które są zakazane w linkach, które można stosować w szczególnym kontekście, i które nie są dozwolone. Znaki niedozwolone, a w określonych kontekstach znaki o specjalnym znaczeniu, muszą zostać w specjalny sposób zakodowane:

W przypadku nazw katalogów i plików rozróżnia się małe i duze litery! Plik.Html, PLIK.HTMLplik.html to trzy różne pliki (co stoi w sprzeczności z przyzwyczajeniami wyniesionymi z DOS-a i Windows.

Znaki zarezerwowane do specjalnych celów są wykorzystywane w linkach w celu przekazania serwerowi specjalnych informacji. Generalnie stosowanie tych znaków w odsyłaczach nie jest zalecane, gdyż nie wiadomo, czy przez serwer zostaną potraktowane jako część nazwy pliku czy ścieżki, czy też zinterpretowane jako znacznik jakiegoś polecenia.

Znaki niedozwolone i zarezerwowane (jeżeli nie są używane zgodnie ze swoim specjalnym przeznaczeniem) mogą być użyte w nazwach plików i katalogów, ale w linku dany znak musi zostać zastąpiony przez sekwencję znaku procenta i kodu szesnastkowego danego znaku (sekwencje procentowe):

znak   sekwencja     znak   sekwencja     znak   sekwencja
  <     %3C            \     %5C            @     %40
  >     %3E            ^     %5E            &     %26
  #     %23            [     %5B            =     %3D
  %     %25            ]     %5D            +     %2B
  "     %22            `     %60            $     %24
[spacja]%20            ;     %3B            ,     %2C
  {     %7B            /     %2F          [nowa
  }     %7D            ?     %3F          linia]  %0D%0A
  |     %7C            :     %3A          [tab]   %09

Jak widać, powyższa norma zabrania stosowania spacji w ogóle, choć ktoś mógłby z doświadczenia stwierdzić, że linki zawierające pojedyncze spacje działają w znanych im przypadkach. Nie jest to jednak regułą. Lepiej jest zastąpić spację w odsyłaczu sekwencją %20, a jeszcze lepiej zastąpić w nazwie pliku lub ścieżce znakiem podkreślenia – efekt jest prawie identyczny, a ma się pewność, że nikt nie będzie miał kłopotów z dostępem do pliku.

Stosowanie polskich liter (i innych znaków narodowych) w linkach niesie ze sobą tę trudność, że użytkownik nie ma wpływu na kodowanie użyte w nazwie swojego pliku ani na kodowanie, jakie zostanie użyte przez przeglądarkę do zakodowania tego znaku. Sam protokół również nie przewiduje żadnej możliwości przesłania informacji o użytym kodowaniu (czy np. polskie litery zostały zakodowane w UTF-8, czy w ISO-8859-2, czy może w Windows-1250). Teoretycznie znaki spoza US­-ASCII powinny być najpierw skonwertowane do postaci UTF-8, a następnie zastąpione sekwencjami procentowymi, ale nie zawsze, nie na każdym serwerze i nie w każdym programie użytkownika tak to działa. Może się zdarzyć, że w nazwie pliku zostanie użyte kodowanie właściwe dla systemu operacyjnego, na którym dany plik został utworzony, zaś przeglądarka napotykając w linku znak narodowy zakoduje go albo w unikodzie, albo w charsecie strony www, na której umieszczony jest ten link. Rezultatem będzie komunikat o niemożności znalezienia danego pliku. W wielu wypadkach niemożliwe jest otwarcie pliku, w którego nazwie znajdują się znaki nieistniejące w 8-bitowej stronie kodowej używanego systemu operacyjnego. Poniżej pokazane zostały procentowe sekwencje polskich liter zakodowane zgodnie z UTF-8 (prawidłowe) i 8-bitowo (zgodnie ISO-8859-2; w nawiasie sekwencje Windows-1250 – tylko różniące się od sekwencji ISO; sekwencje te są gdzieniegdzie spotykane i błędne, jednak mogą być wykorzystane do uzyskania dostępu do pliku o błędnie zakodowanej nazwie):

znak   sekwencja   sekwencja     znak   sekwencja   sekwencja
        UTF-8        ISO                 UTF-8        ISO
  ą     %C4%85       %B1 (%B9)     Ą     %C4%84       %A1 (%A5)
  ć     %C4%87       %E6           Ć     %C4%86       %C6
  ę     %C4%99       %EA           Ę     %C4%98       %CA
  ł     %C5%82       %B3           Ł     %C5%81       %A3
  ń     %C5%84       %F1           Ń     %C5%83       %D1
  ó     %C3%B3       %F3           Ó     %C3%93       %D3
  ś     %C5%9B       %B6 (%9C)     Ś     %C5%9A       %A6 (%8C)
  ź     %C5%BA       %BC (%9F)     Ź     %C5%B9       %AC (%8F)
  ż     %C5%BC       %BF           Ż     %C5%BB       %AF

Z opisanych wyżej powodów również stosowanie polskich liter (i innych znaków spoza US­-ASCII) w linkach typu mailto:, które automatycznie wypełniają temat i (czasem) treść maila, jest niewskazane. W zależności od kombinacji przeglądarka www – klient pocztowy polskie litery mogą być przekazane i odczytane poprawnie, jako znaki z innego kodowania, albo nawet jako kody szesnastkowe bez ich odkodowania. Może też wystąpić pomieszanie stron kodowych. Na przykład link mailowy wypełniający automatycznie temat i treść w postaci:
<a href="mailto:login@domena?subject=Błąd na stronie www.przyklad.com.pl&amp;body=Znalazłem następujący błąd:">
w zamierzeniu autora dający następujący rezultat u klikającego:

Temat:

może być u odwiedzającego stronę zinterpretowany albo tak, jak powyżej, albo (niestety) na jeden z poniższych sposobów:

Temat:

Temat:

Temat:

a nawet wszystko począwszy od pierwszej spacji może zostać zignorowane (w temacie zostanie jedynie wpisane słowo „Błąd”, potencjalnie w jeden z powyższych trzech sposobów). Należy pamiętać, by w takim linku nie stosować żadnych znaków spoza US­-ASCII, spację oraz znaki niedozwolone w URL-ach zamieniać na postać %HH (gdzie HH to kod szesnastkowy znaku, np. spacja to %20) i nie sugerować się tym, że u autora akurat działa. Polskie znaki w takich odsyłaczach najczęściej działają, gdy zarówno przeglądarka, jak i mailer, są z jednej stajni, np. Firefox+Thunderbird, Opera+M2 albo IE+OE. Działanie nie jest jednak regułą. Jeżeli ktoś chce, może zastąpić polskie litery sekwencjami procentowymi UTF-8 (patrz wyżej, nad przykładami), prawdopodobieństwo poprawnego zadziałania będzie wówczas większe.

Zalecana postać przykładowego linku mailto: przedstawia się następująco:
<a href="mailto:login@domena?subject=Blad%20na%20stronie%20​www.przyklad.com.pl&amp;​body=Znalazlem%20​nastepujacy%20blad:">,
albo z polskimi literami
<a href="mailto:login@domena?subject=B%C5%82%C4%85d%20na%20stronie%20​www.przyklad.com.pl&amp;​body=Znalaz%C5%82em%20​nast%C4%99puj%C4%85cy%20b%C5%82%C4%85d:">,
co daje następujący efekt: mailto 1 (bez polskich liter) albo mailto 1 (z polskimi literami) (kliknij, aby zobaczyć).

Ciekawostką, być może przydatną komuś, jest możliwość wstawienia znaku końca linii w postaci ciągu %0D%0A, co można wykorzystać w przypadku tekstu przeznaczonego do automatycznego wpisania w treści.

Inną ciekawostką, wartą rozpropagowania, jest możliwość umieszczenia w odsyłaczu własnego imienia czy nicka, dzięki czemu mail nie będzie tak anonimowy. Należy tak skonstruować odsyłacz, by imię czy nick był wpisywany normalnie (pamiętać o zamianie spacji na %20), a adres w nawiasach trójkątnych, jak w poniższym przykładzie:
<a href="mailto:Autor%20serwisu%20&lt;login@domena&gt;​?subject=Blad%20​na%20stronie%20​www.przyklad.com.pl&amp;​body=Znalazlem%20nastepujacy%20blad:">,
albo z polskimi literami
<a href="mailto:Autor%20serwisu%20&lt;login@domena&gt;​?subject=B%C5%82%C4%85d%20​na%20stronie%20​www.przyklad.com.pl&amp;​body=Znalaz%C5%82em%20nast%C4%99puj%C4%85cy%20b%C5%82%C4%85d:">,
a gotowy link wygląda tak: mailto 2 (bez polskich liter) albo mailto 2 (z polskimi literami) (kliknij, aby zobaczyć).

Jako ciekawostkę dodam, że domeny mają bardziej restrykcyjne zasady: zestaw znaków ograniczony jest wyłącznie do małych i wielkich liter, cyfr i minusa. Za to nie rozróżnia się małych i dużych liter, np. www.onet.pl, www.Onet.plwww.ONET.Pl to ta sama domena. Kodowanie znaków narodowych i specjalnych w domenach przebiega inaczej i zostało opisane na osobnej stronie link prowadzi do podstrony.

6. Linki

Rozwiązania przetestowane na następujących programach pracujących pod Windows 2000 SP4 English: Nvu w wersji 1.0, AceHTML w wersji 6.0.5.8, Open Office w wersji 2.0.4, Amaya w wersji 9.52, Arachnophilia w wersji 5.3 build2132 (Java VM 1.5.0_10 – 1.5.0_11), Simredo w wersji 4.1 (Java VM 1.5.0_07 – 1.5.0_11), UniRed w wersji 2.04 i 2.05, BabelPad w wersji 1.9.3, Gżegżółka w wersji 7.1.1.0 – 7.1.2.0, Tidy w wersji z 11.02.2007.

licznik