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 i mapa serwisu

Konfiguracja Agenta

Forté Agent jest jednym z dłużej istniejących czytników grup dyskusyjnych, oferowany był już w czasach Windows 3.x (wersja 0.99 z 1994 r.). Przez wiele lat cieszył się on znaczną popularnością i miał liczne grono wiernych użytkowników przekonanych, że jest to najlepszy klient newsów pod Windows. Niestety, mimo upływu czasu i wypuszczania coraz to nowych wersji programu, producent do tej pory nie przepisał kodu programu tak, by obsługiwał on unikod. Agent działa w oparciu o czcionki 8-bitowe, jedynie w oknach podglądu treści posta oraz w panelu treści i polu tematu okna kompozycji Agent pozwala na wyświetlenie znaków z różnych kodowań wykorzystując odpowiednie strony kodowe w czcionkach. Wynika z tego fakt, że Agent obecnie nie obsługuje w pełni unikodu – w postach używających unikodu Agent wyświetli tylko te znaki, które istnieją w ustawionej w programie domyślnej stronie kodowej. Forté Free Agent obsługuje MIME (i co za tym idzie kodowania) począwszy od wersji 1.92.

Począwszy od wersji 4.0 Agent nie jest już oferowany w wersji darmowej (w rzeczywistości od wersji 1.92 Free Agent to była wersja tzw. „crippleware”, czyli faktycznie pełna wersja z zablokowaną obsługą pewnych funkcji, dostępnych w wersji zarejestrowanej). Ostatnia darmowa wersja to 3.3 z 9.03.2006 (patrz komunikat link do str. zewnętrznej). A dokładnie to niezarejestrowany Agent w wersji 4 to też „crippleware” – po upływie 30 dni od zainstalowania ogranicza swoją funkcjonalność. W przeciwieństwie do poprzednich wersji tu wyłączona zostaje możliwość łączenia się z serwerami, przez co staje się bezużyteczny.

Do wczesnych wersji istniały polskie nakładki językowe. Wersje 3.x i 4.x dostępne są tylko w wersji angielskiej.

Strona nie będzie już uaktualniana, chyba że producent ponownie zdecyduje się na udostępnienie Agenta w wersji darmowej.

Spis treści:

  1. Konfiguracja Agenta do pracy w języku polskim i prawidłowego stosowania unikodu:
    1. Dodanie obsługi języków środkowoeuropejskich,
      1. Dodanie obsługi polskich liter w alternatywnych kodowaniach,
    2. Ustawienie charsetu i kodowania transportowego – czyli jak pisać w ISO-8859-2, prawidłowo kodować nagłówki w Quoted-Printable, jak ustawić kodowanie treści (8-bit lub Quoted-Printable, jak wybrać domyślny charset do wyświetlania dla postów, które nie zawierają deklaracji charsetu,
    3. Konfiguracja czcionek dla każdego kodowania,
    4. Ustawienie czcionki o stałej szerokości dla treści,
    5. Zmiana charsetu w trakcie pisania,
  2. Konfiguracja Agenta do pracy wielojęzycznej,
    1. Dyskusja ograniczeń obsługi wielu języków przez program,
    2. Dodanie obsługi żądanych języków,
    3. Ustawienie charsetu i kodowania transportowego dla każdego kodowania,
    4. Konfiguracja czcionek dla każdego kodowania,
    5. Przypisanie ustawień językowych dla każdej z grup,
    6. Wrotka i wielojęzyczne podpisy,
    7. Zmiana strony kodowej używanej do wyświetlenia treści listu,
  3. Własne nagłówki w postach,
  4. Dodatek: Bugi i niedoróbki powodujące kłopoty z ogonkami (nie tylko polskimi),
  5. Dodatek: struktura plików .COD (zapewniających obsługę różnych charsetów),
  6. Gdzie i kiedy nie używać polskich liter (ani innych znaków narodowych lub specjalnych),
  7. Odsyłacze.

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.

1. Konfiguracja Agenta do pracy w języku polskim i prawidłowego stosowania unikodu

W związku z dopuszczeniem unikodu (w transformacji UTF-8) jako równorzędnego z ISO-8859-2 na grupach hierarchii pl.* (patrz strona poświecona usenetowi w Polsce link do str. zewnętrznej oraz posty: qvdjwrm4esfu.dlg@falcon.sloth.hell.pl link do str. zewnętrznej i dlptqd$csg$1@news.pse.pl link do str. zewnętrznej, oraz wcześniejsze: wątek cmrv87$ltf$3@debi.pekin.net.pl link do str. zewnętrznej, podwątek zaczynający się od 3dT2dac3kIpn6N34%chopin@akson.sgh.waw.pl link do str. zewnętrznej i post 5kT2kao5eI1s9N34.chopin@akson.sgh.waw.pl link do str. zewnętrznej) przygotowane zostały instrukcje dostosowania Agenta tak, by w miarę swych możliwości prawidłowo wyświetlał i wysyłał posty uwzględniające tę zmianę. Niestety, wskutek wewnętrznych ograniczeń architektury programu, nie jest możliwa pełna obsługa unikodu w Agencie, a że unikod w pierwszym rzędzie jest używany do wysyłania listów zawierających w treści znaki, które nie istnieją w żadnej pojedynczej stronie kodowej (np. cytaty w obcym języku, wyrażenia matematyczne), ta niepełna obsługa unikodu z czasem zmusi użytkowników do zmiany czytnika (lub do skutecznego naciskania na producenta programu, by dokonał w nim odpowiednich zmian).

Uwaga: Unikod jest w pełni legalny i dopuszczony do stosowania, ale nie należy słać w UTF-8 postów, które nie zawierają znaków spoza ISO-8859-2. Zgodnie z RFC2046 link do str. zewnętrznej p. 4.1.2 (ostatni akapit) i z opinią wyrażoną w poście qvdjwrm4esfu.dlg@falcon.sloth.hell.pl link do str. zewnętrznej

[...] należy się stosować do zasady najmniejszego
niezbędnego charsetu - pisząc czysto po angielsku należy używać US-ASCII,
pisząc po polsku (czesku, słowacku itd.) - 8859-2, pisząc w języku nie
mającym odpowiedniego ISO 8859-N (albo naraz w kilku językach używających
różnych N) należy używać UTF-8.

Poniżej opisana konfiguracja zapewnia automatyczne stosowanie tej zasady przez program.

Wyżej wymienione posty zostały napisane przez administratorów najważniejszych serwerów news w Polsce.

1.1 Dodanie obsługi jezyków środkowoeuropejskich

Agent domyślnie instaluje się wyłącznie z obsługą języków zachodnioeuropejskich (ISO-8859-1, ISO-8859-15, Windows-1252). Obsługę języków Środkowej Europy najłatwiej dodać na etapie instalacji klikając na przycisk „Choose Additional…”:

a następnie zaznaczając instalację charsetu Europy Środkowej i Wschodniej:

Jeżeli zastaniemy już zainstalowanego Agenta bez zainstalowanej obsługi języków środkoweuropejskich, nie trzeba go przeinstalowywać – po zamknięciu programu wystarczy skopiować z katalogu All_COD do katalogu głównego, w którym zainstalowany jest program, następujące pliki:
cp1250.cod
8859-2.cod

Po ponownym uruchomieniu Agenta w opcjach będą dostępne charsety języków środkowoeuropejskich.

Jeżeli we wspomnianym katalogu nie ma odpowiednich plików *.COD lub katalog ten nie istnieje, można ściagnąć komplet plików *.COD ze strony producenta link do str. zewnętrznej (na samym dole, nazywa się „Code Pages”).

Do poprawnej obsługi języka polskiego Agent wymaga również zainstalowanej obsługi języków środkowoeuropejskich w systemie operacyjnym (uwaga ta przeznaczona jest dla osób mieszkających za granicą).

1.1.1 Dodanie obsługi polskich liter w alternatywnych kodowaniach

Okazjonalnie zdarza się, że ktoś wyśle post używając kodowania ISO-8859-16 lub ISO-8859-13. Zdarza się to bardzo rzadko, ale by nie psuć tak zakodowanych polskich liter, zalecam również analogicznie jak w przypadku dwóch ww. plików skopiowanie pliku 8859-13.cod i dodanie pliku 8859-16.cod.

UWAGA: Zabieg ten nie dodaje pełnej obsługi tych kodowań, jedynie tych znaków, które istnieją w stronie kodowej Windows-1250.

1.2 Ustawienie charsetu i kodowania transportowego

Najpierw należy wejść w Tools ⇒ Options:

W otwartym oknie konfiguracyjnym należy wybrać pozycję „Languages” i ustawić odpowiednie parametry:

1 – kodowanie czcionki użytej do wyświetlania postów w tym języku. Najłatwiej jest użyć standardowej czcionki unikodowej i wybrać skrypt środkowoeuropejski, ale nic nie stoi na przeszkodzie, by wybrać czcionkę ISO (o wyborze czcionek czyt. w następnym kroku) – należy pamietać, że wybierając czcionkę ISO trzeba również używać klawiatury ISO do pisania. Gdy wybierze się czcionkę ISO, należy w tym miejscu wybrać kodowanie ISO, nie Windows.
2 – charset, w jakim chcemy wysyłać posty. Normalnie dla języka polskiego będzie to ISO-8859-2. Właściwa opcja to „us-ascii, ISO-8859-2”. Można też wybrać opcję „us-ascii, ISO-8859-2, UTF-8”, jeżeli chcemy mieć możliwość wysyłania postów w unikodzie bez zbędnego potwierdzania zmiany charsetu. Należy pamiętać, aby pod żadnym pozorem nie wybierać ani Windows-1250 (CeP jest fuj!), ani us-ascii, nawet gdy samemu pisze się po polskawemu (bez polskich liter) – wysyłanie postów zawierających polskie litery (i inne znaki z górnego zakresu) w cytowanych fragmentach będzie uciążliwe albo co gorsza prawidłowo zakodowane polskie litery obecne w cytatach będą psute, co jest niedopuszczalne!
3 – domyślny charset do wyświetlenia listu, który nie zawiera deklaracji charsetu. Posty z nieskonfigurowanego OE nie zawierają deklaracji charsetu, co powoduje zwykle problemy dla innych z wyjątkiem samych opslukowców. Tu oczywiście możesz wybrać co chcesz, nawet us-ascii będzie technicznie poprawne (i do tego w 100% zgodne z RFC 2046 link do str. zewnętrznej p. 4.1.2), ale ja osobiście jednak bym wybrał ISO-8859-2.
4 – a to już jest kodowanie transportowe. Koniecznie zaznacz opcję wysyłania nagłówków zgodnych z MIME, czyli wstaw ptaszek obok „MIME headers” (inaczej znaki spoza US-ASCII będą wysyłane w postaci 8-bitowej, przez co inni zwykle zobaczą krzaki, poza tym wysyłanie w nagłówkach znaków 8-bitowych jest zabronione przez RFC 2822 link do str. zewnętrznej p. 2.2), a przy wysyłaniu na grupy z hierarchii pl.* treść zaleca się wysyłać jako 8-bit (ustawia się to wybierając z listy rozwijanej obok „Usenet text:” opcję „7bit/8bit”), gdyż OE nie wstawia znaków cytowania, gdy odpowiada na list z treścią kodowaną inaczej niż 8-bit, choć nie jest to obowiązkowe. Patrz oficjalne stanowisko właściciela hierarchii link do str. zewnętrznej.

Należy również otworzyć „Posting Messages”, tam zaznaczyć „Composition Window” i koniecznie zaznaczyć opcję „Warn if message…” (strzałka nr 1) – dzięki temu będziesz ostrzeżony przed wysłaniem, że w poście znajdują się znaki, których nie można zakodować w wybranym charsecie (gdy nie zaznaczysz tego pola, a w swoim poście będziesz miał znaki spoza ISO-8859-2, zostaną one zamienione bez pytania na znaki zapytania):

Zaznaczone strzałkami zostały również inne ustawienia, ważne dla technicznej poprawności wysyłanych postów.
Tak skonfigurowany program będzie prawidłowo kodował i deklarował użyte kodowanie:

  1. US-ASCII dla postów zawierających tylko łacińskie litery i cyfry,
  2. ISO-8859-2 dla postów, których treść da się zakodować w ISO-8859-2 (większość postów pisanych po polsku),
  3. ewentualnie UTF-8 dla postów zawierających znaki spoza ISO, jeżeli tak zostało ustawione powyżej (strzałka nr 2), a Agent jest w stanie te znaki zakodować.

Agent zastosuje te zasady również przy odpowiedziach – odpowiadając na post kodowany UTF-8 Agent sprawdzi treść pisanego postu i jeżeli okaże się, że treść można zakodować w ISO-8859-2 (gdy zostaną usunięte fragmenty cytatu zawierające znaki spoza ISO-8859-2 lub post był zbędnie kodowany w UTF-8, choć ISO-8859-2 wystarczyłoby), to post taki zostanie wysłany w ISO. Analogicznie zachowa się w przypadku, gdy treść będzie mogła zostać wysłana w US-ASCII (czyli gdy nie zawiera żadnych znaków poza literami łacińskimi, cyframi i kilkoma znakami interpunkcyjnymi). Jest to zachowanie zgodne z zaleceniem stosowania najwęższego możliwego charsetu, zawartym w RFC 2046 link do str. zewnętrznej.

Jeżeli zamierzasz używać Agenta do odpowiadania komuś na jego adres e-mail, nie na grupę, to musisz też skonfigurować ustawienia poczty. Proponuję ustawienia analogiczne, jak dla newsów.

Nie istnieje polski słownik dla Agenta, poza tym Free Agent nie udostępnia tej funkcji – jest ona obecna wyłącznie w pełnym, płatnym Agencie.

Uwaga: W hierarchii pl.* została dopuszczona możliwość stosowania UTF-8 w listach zawierających znaki, które nie mogą być zakodowane w ISO-8859-2. Dotyczy to przede wszystkim tekstów wielojęzycznych mieszających różne grupy językowe. Agent z uwagi na swoje ograniczenia nie ma możliwości wysyłania ani wyświetlania przeważającej większości takich postów i stąd używanie unikodu do wysyłania w większości przypadków mija się z celem, gdyż (w przypadku języka polskiego) unikod może być użyty jedynie do przekazania kilku znaków specjalnych typu dywiz (długa kreseczka, —), znak €uro, znak ©opyrightu, „cudzysłowy i »cudzysłowy drugiego stopnia«”, znak µ. W Agencie nie ma możliwości zobaczenia, w jakim charsecie zostanie wysłany dany post – Agent dobierze najlepiej pasujący charset spośród dozwolonych w oknie konfiguracji charsetów. Jeżeli nie chcesz wysłać listu w UTF-8, powinieneś w oknie konfiguracji języków wybrać opcję nie zezwalającą na (automatyczne) wysyłanie w UTF-8. Wówczas, jeżeli zaznaczyłeś zalecaną opcję pokazaną na ilustracji powyżej, przy próbie wysłania postu zawierajacego znaki, których nie ma w ISO-8859-2, zobaczysz komunikat o niemożności wysłania postu w wybranym kodowaniu:

Możesz podjąć wówczas decyzję, czy chcesz wysłać w proponowanym charsecie (klikając na górny przycisk, czyli „Yes, send…”), albo wybrać „Cancel sending”, przejrzeć treść posta i usunąć z niej znaki spoza ISO-8859-2. Wybranie środkowej opcji spowoduje zamianę wszystkich znaków spoza charsetu na znaki zapytania – zdecydowanie nie zalecam używania tej opcji. Pamiętaj, żeby w tym oknie nie wybrać kodowania UTF-7, gdyż jest to kodowanie przestarzałe i niezalecane do stosowania. Unikod należy wysyłać w UTF-8.

1.3 Konfiguracja czcionek

Po kliknięciu na „Display”, a następnie zaznaczeniu „Fonts”, otworzy się okno konfiguracji czcionek. Należy pamiętać, by w przypadku konfiguracji czcionek dla elementów zaznaczonych strzałką nr 1 oprócz wyboru samych czcionek wybrać też właściwy skrypt (Środkoweuropejski). Jeżeli używamy Agenta na komputerze, na którym ustawienia regionalne są inne niż środkoweuropejskie, należy również zaznaczyć opcję używania przez program czcionki proporcjonalnej używanej do wyświetlania treści dla wyświetlania nagłówków – bez tego Agent użyje czcionki systemowej i zamiast polskich liter pokażą się krzaki (strzałka nr 2):

1.4 Ustawienie czcionki o stałej szerokości dla treści

Aby poprawnie zobaczyć podkreślenia czy ascii-arty, należy czytać posty przy użyciu czcionki o stałej szerokości (nieproporcjonalnej). Wyboru dokonuje się z menu

Wyboru należy dokonać osobno dla normalnego widoku i dla podglądu źródła (Raw Message).

1.5 Zmiana charsetu w trakcie pisania

W trakcie pisania posta możemy wiedzieć, że użyte w treści znaki nie dadzą się zakodować w wybranym, domyślnym charsecie danej grupy. Zmiana charsetu jest możliwa w oknie właściwości pisanego posta, które otwiera się kombinacją Alt+Enter, na zakładce Language:

Z dostępnych charsetów nie należy stosować UTF-7, gdyż jest to charset przestarzały – unikod koduje się w UTF-8.

2. Konfiguracja Agenta do pracy wielojęzycznej

2.1 Dyskusja ograniczeń obsługi wielu języków przez program

Agent, mimo (lepszej lub gorszej) obsługi względnie licznych charsetów, jest bardzo niewdzięcznym programem do używania w środowisku wielojęzycznym. Wewnętrznie oparty jest o strony kodowe i o ile potrafi wybierać odpowiedni skrypt (inaczej stronę kodową) czcionki używanej do wyświetlania treści w zależności od charsetu czytanego lub pisanego posta, to wybór tego skryptu jest globalny dla danego panelu. Z tego powodu nie jest możliwe poprawne wyświetlenie treści postów kodowanych w unikodzie i zawierających znaki mapowane na różne skrypty albo wręcz nieistniejące w żadnym skrypcie (a to często się zdarza, bo właśnie do tego służy unikod, by móc w treści umieścić znaki używane różnych językach i znaki specjalne, matematyczne itp.), zaś gdy w jednym, katalogu (skrzynce odbiorczej, folderze grupy news) znajdą się listy, w których pola Nadawca i Temat zawierają znaki narodowe, które nie istnieją w żadnej pojedynczej stronie kodowej Windows, w przypadku niektórych listów będzie widać krzaki. Agenta najłatwiej skonfigurować do obsługi tych charsetów 8-bitowych, w których wszystkie zawarte znaki istnieją w jakimś kodowaniu Windows. Obsługa tych charsetów 8-bitowych, które zawierają znaki z różnych stron kodowych Windows (lub zawierają znaki nieistniejące w żadnej stronie kodowej) jest możliwa pod warunkiem posiadania czcionki ekranowej i układu klawiatury w danym kodowaniu. W celu dodania możliwości użycia specjalnej czcionki może być niezbędna prosta edycja odpowiedniego pliku .COD. Niestety, nie znam żadnych źródeł czcionek ISO oprócz ISO-8859-2 (a to kodowanie może być obsłużone metodą przekodowania na i z Windows-1250) i KOI8-R (w tym kodowaniu jedynie znaki semigrafiki nie mogą być zamapowane na kodowanie Windows-1251, ale nie zetknąłem się z użyciem tych znaków w poczcie i na newsach). Oprócz pełnej obsługi wszystkich charsetów Windows (co oczywiste) są to przykładowo następujące charsety:

Charsetmożliwość zamapowania na
ISO-8859-1Windows-1252
ISO-8859-15
ISO-8859-2Windows-1250
ISO-8859-5Windows-1251
ISO-8859-9Windows-1254
ISO-8859-13Windows-1257

Wymienione poniżej charsety nie dają się w 100% zamapować na jedną stronę kodową Windows, gdyż zawierają znaki z więcej niż jednego skryptu Windows lub w ogóle nie istniejące w żadnym skrypcie Windows (oznaczone „brak”). W listach używających jednego z poniższych kodowań mogą pojawić się znaki zapytania zamiast niektórych (poprawnie zakodowanych) znaków:

Charsettrzeba mapować na
ISO-8859-3Windows-1252, Windows-1250, brak
ISO-8859-4Windows-1257, Windows-1252, Windows-1250, brak
ISO-8859-7Windows-1253, brak
ISO-8859-16Windows-1250, Windows-1252, brak
KOI8-RWindows-1251, brak*

* brak jedynie znaków semigragfiki, które normalnie nie są używane w listach.

Na grupach dyskusyjnych używających różnych charsetów, które wymagają mapowania do różnych skryptów Windows, lub które zostały skonfigurowane do używania osobnych czcionek, zawsze widać krzaki w panelu z drzewkiem wiadomości, gdy tematy różnych postów używają różnych charsetów. Na szczęście takie grupy są bardzo rzadko spotykane. Problem ten może za to dotknąć użytkowników pełnego Agenta wykorzystującego go również jako program do obsługi poczty elektronicznej – konieczne będzie wówczas załozenie różnych folderów na pocztę, każdy z nich skonfigurowany tak, by używał odpowiedniego charsetu, i filtrowanie poczty przychodzącej do odpowiednich folderów w zależności od użytego charsetu.

Agent napotkawszy list z kodowaniem Windows może nie przekodować go całkowicie we wszystkich polach. Może to powodować pojawienie się krzaków w temacie wyświetlanym na belce. Problem ten może też wystąpić w niektórych innych sytuacjach (możliwe rozwiązanie: patrz p. 2.7).

2.2 Dodanie obsługi żądanych języków

Obsługę żądanych języków najłatwiej dodać na etapie instalacji klikając na przycisk „Choose Additional…”:

a następnie zaznaczając instalację właściwych charsetów:

Jeżeli zastaniemy już zainstalowanego Agenta bez zainstalowanej obsługi potrzebnych języków, nie trzeba go przeinstalowywać – po zamknięciu programu wystarczy przenieść z katalogu All_COD do katalogu głównego, w którym zainstalowany jest program, odpowiednie pliki .COD. Normalnie należy przenieść plik cp????.cod, dodający obsługę kodowania Windows, niezbędnego, gdy używa się skryptu czcionki windowsowej do wyświetlania listów w danym kodowaniu, oraz jeden lub więcej plików 8859-?.cod (ewentualnie koi8-?.cod), używanego do obsługi danego kodowania. Na przykład w celu dodania obsługi języka litewskiego, który kodowany jest z użyciem ISO-8859-13, należy przenieść pliki:
cp1257.cod
8859-13.cod

Analogicznie w celu dodania obsługi języka rosyjskiego lub ukraińskiego, które kodowane są z użyciem KOI8-R lub Windows-1251, należy przenieść pliki:
cp1251.cod
koi8.cod

Informacje, jakie charsety są używane dla wybranych języków, można znaleźć na podstronie z uwagami na temat charsetów różnych języków i konfiguracji czytników do pracy wielojęzycznej link prowadzi do podstrony. Po ponownym uruchomieniu Agenta w opcjach będą dostępne charsety dodanych języków.

Jeżeli we wspomnianym katalogu nie ma odpowiednich plików *.COD lub katalog ten nie istnieje, można ściagnąć komplet plików *.COD ze strony producenta link do str. zewnętrznej (na samym dole, nazywa się „Code Pages”).

Do poprawnej obsługi różnych języków Agent wymaga również zainstalowanej obsługi danej rodziny języków (języków środkowoeuropejskich, cyrylicy, bałtyckich itp.) w systemie.

2.3 Ustawienie charsetu i kodowania transportowego

Najpierw należy wejść w Tools ⇒ Options:

W otwartym oknie konfiguracyjnym należy wybrać pozycję „Languages”:

W tym oknie należy dodać grupy języków, dla których chce się uaktywnić obsługę (klikając na „Add…”). Konieczne jest dodanie grup językowych (lub języków) dla wszystkich charsetów, które będzie się używać do wyświetlania i pisania postów. Patrz strona z listą języków i używanych przez nie charsetów link prowadzi do podstrony. Następnie należy sprawdzić ustawić charsety dla każdej rodziny językowej osobno. Charset dla danego języka (grupy języków, kodowania) ustawia się zaznaczając ten język w panelu „Languages” na górze:
1 – kodowanie czcionki użytej do wyświetlania postów w tym języku. Najłatwiej jest użyć standardowej czcionki unikodowej i wybrać właściwy skrypt. W przypadku kodowań, które nie dają się mapować na pojedynczy skrypt Windows, a ma się do dyspozycji czcionkę w danym kodowaniu i sterownik klawiatury, można tu wybrać kodowanie tej czcionki (o wyborze czcionek czyt. w następnym kroku) – należy pamietać, że wybierając np. czcionkę ISO-8859-4 trzeba również używać klawiatury w układzie ISO-8859-4 do pisania. Gdy wybierze się czcionkę ISO, należy w tym miejscu wybrać kodowanie ISO, nie Windows.
UWAGA 1: Jeżeli nie ma na liście kodowania ISO, należy dodać jedną linię we właściwym pliku *.COD. Więcej o strukturze plików *.COD można poczytać poniżej w p-cie 4: Dodatek: struktura plików .COD.
UWAGA 2: Jedno z kodowań języków zachodnioeurpoejskich dostępnych na liście to dziwnie nazywające się „kodowanie ISO-8859-1 kompatybilne z Windows”. Jest to najzwyczajniej w świecie charset Windows-1252, który nieprawidłowo będzie deklarowany jako ISO-8859-1. Stosowanie tego kodowania nie ma żadnego uzasadnienia, ani technicznego, ani zwyczajowego, ani żadnego innego. Nie należy go pod żadnym pozorem używać do kodowania wysyłanych listów!
2 – charset, w jakim chcemy wysyłać posty, wybrany na podstawie strony z listą języków i używanych przez nie charsetów link prowadzi do podstrony. Należy pamiętać, aby dla żadnego języka używającego liter ze znakami diakrytycznymi (zasadniczo każdego poza angielskim) pod żadnym pozorem nie wybierać kodowania us-ascii, nawet gdy samemu pisze się tylko z użyciem liter łacińskich (odpowiednik pisania po polskawemu) – wysyłanie postów zawierających litery z diakrytykami (i inne znaki spoza US-ASCII) w cytowanych fragmentach będzie uciążliwe albo co gorsza prawidłowo zakodowane litery obecne w cytatach będą psute, co jest niedopuszczalne!
3 – domyślny charset do wyświetlenia listu, który nie zawiera deklaracji charsetu. Posty z nieskonfigurowanego OE nie zawierają deklaracji charsetu, co powoduje zwykle problemy dla innych z wyjątkiem samych opslukowców. Tu oczywiście możesz wybrać co chcesz, nawet us-ascii będzie technicznie poprawne (i do tego w 100% zgodne z RFC 2046 link do str. zewnętrznej p. 4.1.2), ale najwygodniej dla wszystkich będzie, gdy zostanie tu wybrany charset najczęściej używany dla danego języka czy grupy języków.
4 – a to już jest kodowanie transportowe. Koniecznie zaznacz opcję wysyłania nagłówków zgodnych z MIME, czyli wstaw ptaszek obok „MIME headers” (inaczej znaki spoza US-ASCII będą wysyłane w postaci 8-bitowej, przez co inni zwykle zobaczą krzaki, poza tym wysyłanie w nagłówkach znaków 8-bitowych jest zabronione przez RFC 2822 link do str. zewnętrznej p. 2.2). Wybór kodowania transportowego dla treści (wybierany z listy rozwijanej obok „Usenet text:”) zależy od ustaleń i zwyczajów panujących w danej hierarchii i na danej grupie – jak nie ma nic na ten temat w FAQ-u hierarchii ani grupy, najlepiej ustawić tak, jak mają ustawione inni.
5 – użytkownicy pełnego Agenta mogą ściągnąć ze strony producenta i zainstalować słowniki sprawdzania pisowni dla paru języków zachodnioeuropejskich. Instalacja słownika dodaje automatycznie dany język, ale konfiguracja charsetu i kodowania transportowego dla każdego języka przyjmuje wartości domyślne i trzeba je zmieniać na poprawne. Zasadniczo słowniki można zainstalować również i we Free Agencie, ale nie są one dostępne (przy próbie sprawdzania pisowni pojawia się stosowny komunikat). Pliki słowników mają rozszerzenia *.clx i *.tlx (użytkownicy Free Agenta mogą zaoszczędzić nieco miejsca usuwając bezużyteczne słowniki).

2.4 Konfiguracja czcionek

W oknie opcji po kliknięciu na „Display”, a następnie zaznaczeniu „Fonts”, otworzy się okno konfiguracji czcionek. Po kolei należy wybierać język, grupę języków lub kodowanie z listy (strzałka nr 1), a następnie ustawiać odpowiednie czcionki (wszystkie ustawienia objęte klamrą, na którą pokazuje strzałka nr 2). Wybierając czcionki unikodowe należy pamiętać, by oprócz wyboru samych czcionek wybrać też właściwy skrypt (bałtycki, cyrylica, grecki itp.). W każdym wypadku należy również zaznaczyć opcję używania przez program czcionki proporcjonalnej używanej do wyświetlania treści dla wyświetlania nagłówków – bez tego Agent użyje czcionki systemowej i zamiast liter z diakrytykami mogą pokazać się krzaki (strzałka nr 3):

2.5 Przypisanie ustawień językowych dla każdej z grup

Po zasubskrybowaniu należy kliknąć drugim klawiszem myszy na danej grupie i z menu kontekstowego wybrać „Folder properties”:

a następnie kliknąć na pozycję „Default language”, zaznaczyć klatkę, by program nie stosował dla tej grupy domyślnych ustawień, i z menu wybrać właściwy język (ten, dla którego zostały wybrane właściwe dla tej grupy opcje charsetu, kodowania transportowego i ewentualnie języka sprawdzania pisowni):

2.6 Wrotka i wielojęzyczne podpisy

Można mieć dowolnie wiele podpisów, ale nie można przypisać osobno domyślnego podpisu pod każdą grupę. Należy je przełączać w oknie kompozycji. Agent nie dodaje delimitera, więc sig trzeba zacząć od delimitera (minus, minus, spacja, Enter). Podpisy mogą być w dowolnych językach, ale podpis przeznaczony do użycia na danej grupie musi być w kodowaniu wybranym do wyświetlania postów z danej grupy (wybranym w p-cie 2.3, strzałka 1).

Program pozwala na zdefiniowanie tylko jednej wrotki. Z uwagi na ograniczenia obsługi kodowań, wrotka może zawierać tylko znaki wspólne dla wszystkich używanych kodowań. W praktyce w przypadku pracy wielojęzycznej z wieloma charsetami oznacza to konieczność ograniczenia się do US-ASCII.

2.7 Zmiana strony kodowej używanej do wyświetlenia treści listu

W przypadku pracy wielojęzycznej można mieć problemy pewne z poprawnym wyświetleniem listów kodowanych UTF-8. Ponieważ kodowanie to może być użyte z każdym językiem, program nie wie, jakiej strony kodowej użyć do wyświetlenia treści, więc używa domyślnej. Czasem skutkuje to pojawieniem się dużej ilości znaków zapytania w treści, odpowiedź na taki list również będzie zawierała znaki zapytania zamiast prawidłowych znaków. Gdy skonfigurowało się kilka grup językowych, można spróbować ręcznie dobrać stronę kodową: z menu „Edit” wybiera się „Language…”, po czym w nowo otwartym oknie można metodą prób i błędów dobrać najlepszą stronę kodową, albo po prostu czytać fragmentami:

Ponieważ unikod zawiera znaki, których nie ma w żadnej stronie kdoowej Windows (strzałki, ułamki, różne specjalne znaki interpunkcyjne, symbole matematyczne i wiele innych znaków specjalnych…), metoda ta nie zawsze zadziała do końca.

3. Własne nagłówki

Program od wersji 3.2 umożliwia konfigurację dodatkowych nagłówków, które będą dodawane do wysyłanych listów w różnych sytuacjach:

W każdym wypadku możliwe jest zaznaczenie, czy dany nagłówek ma być dodawany do nowych postów, do odpowiedzi na posty, do odpowiedzi na priva (i w przypadku opłaconego Forté Agenta do nowych maili i do odpowiedzi na maile).

Agent nie koduje znaków spoza US-ASCII w dodanych nagłówkach, przez co są one niezgodne z MIME i odpowiednimi RFC. Rozwiązaniem jest albo rezygnacja ze stosowania polskich liter, albo zakodowanie ciągu zgodnie z MIME.

4. Dodatek: Bugi i niedoróbki powodujące kłopoty z ogonkami (nie tylko polskimi)

1. Brak pełnej obsługi znaków z róznych stron kodowych
Opis buga: Program obsługuje liczne charsety, w tym unikod, ale wewnętrznie pracuje w oparciu o strony kodowe, przez co uzyskanie wyświetlania listów pisanych w różnych językach jest utrudnione, a prawidłowe wyświetlenie listów zawierających znaki z różnych stron kodowych Windows lub których nie ma w żadnej stronie kodowej Windows jest niemożliwe.
Metoda obejścia: Brak

2. Domyślne ustawienie, by posty na grupy dyskusyjne miały nagłówki niezgodne z MIME (zawierały niezakodowane znaki w postaci 8-bitowej)
Opis buga: Opcja „MIME headers” dla postów jest domyślnie niezaznaczona, przez co wysyłane posty są niezgodne z RFC 2822 link do str. zewnętrznej p. 2.2.
Metoda obejścia: Pamiętać o zaznaczeniu tej klatki

3. Brak kodowania znaków spoza US-ASCII w nagłówkach dodanych przez użytkownika
Opis buga: Znaki spoza US-ASCII (np. polskie litery) zostaną wysłane bez żadnego kodowania, co jest niezgodne z RFC 2822 link do str. zewnętrznej p. 2.2.
Metoda obejścia: Jako wartości dodawanych pól nagłówków należy wstawić ciągi prawidłowo zakodowane zgodnie z RFC 2047 link do str. zewnętrznej.

4. Mylące kodowanie „Western Windows compatible” jako domyślne dla kodowania zachodnioeuropejskiego
Opis buga: Kodowanie to to tak naprawdę kodowanie Windows-1252, które jest fałszywie deklarowane jako ISO-8859-1. W kodowaniu Windows występują dodatkowe znaki pisarskie w zakresie pozycji 128÷159, na tych pozycjach w kodowaniu ISO-8859-1 znajdują się znaki kontrolne. Użycie tego pseudokodowania nie ma żadnego uzasadnienia technicznego i zwykle sprawia problemy, zwłaszcza użytkownikom systemów innych niż Windows.
Metoda obejścia: Nie używać tego pseudokodowania, usunąć plik 8859-1w.cod. Ponieważ po usunięciu ww. pliku Agent będzie generował błąd (niewidoczny, ale zapisywany w logu), można otworzyć plik cp1252.cod w dowolnym edytorze tekstowym (notatnik systemowy będzie świetny) i usunąć linię
Outbound-Charsets: latin1old, Western Windows-compatible#STR_OCS_LATIN1OLD, ascii, iso-8859-1w
a następnie zapisać zmiany.
Mimo tej zmiany program dalej będzie potrafił poprawnie wyświetlić znaki z zakresu 128÷159 w liście kodowanym Windows-1252, ale nieprawidłowo deklarującym charset ISO-8859-1, jedynie nie będzie udostępniał możliwości wysyłania tak niepoprawnie deklarowanych listów.

5. Brak możliwości wyboru kodowania ISO-8859-13 jako domyślnego dla czytanych listów w przypadku konfiguracji języków bałtyckich
Opis buga: Jak w opisie.
Metoda obejścia: Po zamknięciu programu otworzyć plik cp1257.cod w dowolnym edytorze tekstowym (notatnik systemowy będzie świetny), znaleźć linię
Inbound-Charsets: ascii, iso-8859-4, utf7, utf8, cp1257
i dopisać w niej iso-8859-13. Linia ta będzie wyglądać np. tak:
Inbound-Charsets: ascii, iso-8859-4, iso-8859-13, utf7, utf8, cp1257
Zapisać zmiany.

6. Brak możliwości wyboru dla listów wysyłanych w językach bałtyckich dopuszczalnego kodowania US-ASCII i ISO-8859-13 bez UTF-8
Opis buga: Jak w opisie.
Metoda obejścia: Po zamknięciu programu otworzyć plik cp1257.cod w dowolnym edytorze tekstowym (notatnik systemowy będzie świetny), i między podobnie wyglądającymi liniami na początku pliku dopisać linię
Outbound-Charsets: balticrimnounicode, Baltic Rim no UTF#STR_OCS_BALTICRIMNOUNICODE, ascii, iso-8859-13
Zapisać zmiany.

7. Brak możliwości wyboru dla listów wysyłanych w cyrylicy dopuszczalnego kodowania US-ASCII, KOI8-R i UTF-8 ani kodowania Windows-1251
Opis buga: Jak w opisie.
Metoda obejścia: Po zamknięciu programu otworzyć plik cp1251.cod w dowolnym edytorze tekstowym (notatnik systemowy będzie świetny), i między podobnie wyglądającymi liniami na początku pliku dopisać 3 linie
Outbound-Charsets: win1251, Cyrillic (Windows-1251)#STR_OCS_WIN1251, ascii, cp1251
Outbound-Charsets: koi8utf, Cyrillic with UTF (KOI8-R)#STR_OCS_KOI8UTF, ascii, koi8, utf8
Outbound-Charsets: win1251u, Cyrillic with UTF (Windows-1251)#STR_OCS_WIN1251U, ascii, cp1251, utf8

Zapisać zmiany.

8. Brak możliwości wyboru dla listów wysyłanych w języku greckim dopuszczalnego kodowania US-ASCII i ISO-8859-7 bez UTF-8
Opis buga: Jak w opisie.
Metoda obejścia: Po zamknięciu programu otworzyć plik cp1253.cod w dowolnym edytorze tekstowym (notatnik systemowy będzie świetny), i między podobnie wyglądającymi liniami na początku pliku dopisać linię
Outbound-Charsets: greeknounicode, Greek no UTF#STR_OCS_GREEKNOUNICODE, ascii, iso-8859-7
Zapisać zmiany.

9. Brak możliwości wyboru dla listów wysyłanych w języku tureckim dopuszczalnego kodowania US-ASCII i ISO-8859-9 bez UTF-8
Opis buga: Jak w opisie.
Metoda obejścia: Po zamknięciu programu otworzyć plik cp1254.cod w dowolnym edytorze tekstowym (notatnik systemowy będzie świetny), i między podobnie wyglądającymi liniami na początku pliku dopisać linię
Outbound-Charsets: turkishnounicode, Turkish no UTF#STR_OCS_TURKISHNOUNICODE, ascii, iso-8859-9
Zapisać zmiany.

5. Dodatek: struktura plików .COD

Pliki .COD to pliki tekstowe zawierające mapowanie znaków danego charsetu 8-bitowego na unikod (wyłącznie górnego zakresu, czyli brak jest pozycji 127 i niższych; gdy w danym charsecie pewne pozycje nie są zdefiniowane lub są używane dla znaków sterujących, pozycji tych również brak). Na początku pliku znaleźć też można kilka linii używanych do identyfikacji charsetu i określania jego zastosowania.

Dokumentacja plików nie jest dostępna publicznie, więc informacje tu zamieszczone oparte są na własnych obserwacjach, analizie i próbach.

Poniżej nagłówek pliku przekodowania z i na charset Windows-1250:

  1. Name: cp1250
  2. Description: Eastern Europe#STR_DESC_CP1250
  3. Version: 1
  4. Codepage: 1250
  5. Charset: windows-1250, cp1250, cp-1250
  6. Inbound-Charsets: ascii, iso-8859-2, utf7, utf8, cp1250
  7. Outbound-Charsets: latin2noutf, Eastern Europe no UTF#STR_OCS_LATIN2NOUTF, ascii, iso-8859-2
  8. Outbound-Charsets: latin2, Eastern Europe#STR_OCS_LATIN2, ascii, iso-8859-2, utf8
  9. Outbound-Charsets: utf8, Unicode UTF-8#STR_OCS_UTF8, ascii, utf8
  10. Outbound-Charsets: utf7, Unicode UTF-7#STR_OCS_UTF7, ascii, utf7
  11. Outbound-Charsets: ascii, ASCII Only#STR_OCS_ASCII, ascii

Po kolei linie te znaczą co następuje:

  1. nazwa charsetu, używana wewnętrznie przez program
  2. nazwa opisowa charsetu. W ciągu po krzyżyku (#) pojawia się nazwa charsetu z linii 1
  3. wersja (we wszystkich plikach jest 1)
  4. strona kodowa. Linia ta występuje tylko w charsetach dostępnych jako kodowanie lokalne (w jakim ma być wyświetlana treść i wpisywany tekst – patrz p. 1.2 drugi rysunek, strzałka nr 1)
  5. lista oficjalnych nazw i aliasów charsetu zgodnie z rejestracją w IANA link do str. zewnętrznej (rozdzielona przecinkami i spacjami)
  6. lista charsetów (rozdzielona przecinkami i spacjami), z jakich można przekodować na charset definiowany danym plikiem .COD. Linia ta występuje tylko w charsetach dostępnych jako kodowanie lokalne (w jakim ma być wyświetlana treść i wpisywany tekst – patrz p. 1.2 drugi rysunek, strzałka nr 1)
  7. – 11. kodowania dopuszczone do użycia dla wysyłanych listów pisanych z użyciem charsetu definiowanego danym plikiem .COD. Linie te występują tylko w charsetach dostępnych jako kodowanie lokalne (w jakim ma być wyświetlana treść i wpisywany tekst). Struktura każdej linii: pierwszy element to wewnętrzna nazwa zestawu dopuszczonych kodowań. Po przecinku i spacji nazwa zestawu kodowań widoczna w menu konfiguracji języków (patrz p. 1.2 drugi rysunek, strzałka nr 2). W ciagu po krzyżyku (#) występuje wewnętrzna nazwa zestawu kodowań z pierwszej pozycji. Po przecinku lista nazw charsetów zestawu (rozdzielonych przecinkami i spacjami) w kolejności preferencji, nazwy są zgodne z nazwami definiowanymi w pierwszej linii plików .COD.

Po powyższych liniach znajduje się jedna pusta linia, po której umieszczona jest prosta lista znaków w formacie używanym w większości plików mapowań dostępnych na serwerze konsorcjum Unicode: każda linia opisuje jeden znak, zaczyna się od szesnastkowego numeru pozycji danego charsetu (w postaci 0xXX), po białej spacji (jedna lub więcej spacji lub tabulatorów) umieszczony jest numer znaku Unicode (w postaci 0xXXXX). Krzyżyk (#) oznacza, że od tego miejsca do końca linii znajduje się komentarz. Wynika z tego, że możliwe jest skopiowanie zawartości pliku definiującego mapowanie danego charsetu wprost z pliku z serwera konsorcjum Unicode link do str. zewnętrznej.

6. Gdzie i kiedy nie używać polskich liter (ani innych znaków narodowych lub specjalnych)

Oprócz oczywistej sytuacji, gdy wiemy, że odbiorca nie będzie w stanie odczytać polskich (czy innych) liter – np. jest za granicą, korzysta z kafejek internetowych lub z uprzejmości gospodarzy i nie może skonfigurować komputera do wyświetlenia wszystkich znaków – bardzo zalecane jest nieużywanie żadnych takich znaków w nazwach załączników. Spowodowane jest to tym, że znaki spoza US-ASCII mogą być zakodowane na jeden z trzech sposobów:

Aby odbiorca mógł otworzyć załącznik, jego program musi obsługiwać użytą metodę kodowania. Brak obsługi danego sposobu kodowania u odbiorcy skutkuje zmianą nazwy załącznika – gdy list zawiera kilka załączników z opisem ich zawartości w treści, jest to bardzo uciążliwe. Innym problemem jest to, że oprócz zmiany nazwy pliku często zmieniane jest też rozszerzenie (na nic nie mówiące .dat, .att lub .bin), z czym mniej zaawansowany odbiorca sobie nie poradzi. Dodatkowo, nawet gdy program odbiorcy obsługuje metodę kodowania użytą przez nadawcę, w przypadku metod RFC dodatkowo jego system operacyjny i aplikacje używane do otwierania tego typu plików muszą obsługiwać znaki użyte w nazwie. Z kolei w przypadku załączników wysłanych bez kodowania nazwy (tryb Raw) znaki spoza US-ASCII w nazwie mogą zostać wyświetlone w przypadkowym kodowaniu (np. kodowaniu systemowym lub ISO-8859-1), skutkiem czego w nazwie będą krzaki. Nie istnieje proste, w pełni skuteczne rozwiązanie powyższych ograniczeń, jedyny sposób, który na 100% zadziała u wszystkich, to użycie wyłącznie znaków US-ASCII w nazwie załącznika.

Należy również pamiętać, że niektóre formaty plików co prawda pozwalają na umieszczenie w treści znaków narodowych, ale nie przenoszą informacji o użytym kodowaniu, przez co w wypadku przesłania takiego pliku jako załącznik u odbiorcy znaki narodowe mogą się nie wyświetlić prawidłowo. Najbardziej powszechny przykład to pliki tekstowe (o rozszerzeniu .txt). W typowym systemie Windows plik taki otwierany jest w systemowym Notatniku, w którym zawsze używane jest kodowanie systemowe i nie ma żadnej możliwości zmiany kodowania treści. Znaki narodowe będą pokazane prawidłowo tylko w sytuacji, gdy komputer odbiorcy używa tego samego kodowania systemowego, którego używa komputer nadawcy. Kodowanie systemowe zależy od ustawień regionalnych (locale systemowego), w przypadku korespondencji z osobami przebywającymi w innych krajach należy założyć, że ustawienia regionalne komputera nadawcy i odbiorcy będą się różnić, oraz używanego systemu operacyjnego. Przed przesłaniem takiego załącznika należy się upewnić, że odbiorca będzie mógł zobaczyć znaki narodowe w treści.

7. Odsyłacze

Rozwiązania przetestowane na programie Forté Free Agent w wersji 3.1 i 3.3 pod Windows 2000 SP4 English.

licznik