Date: Mon, 19 Aug 1996 21:06:34 +0200 From: Wojciech Myszka 1. Jest bardzo wiele standardów kodowania znaków w komputerach pracu- jących w Internecie (inaczej ma DOS, inaczej Windows, MAC, Amiga i Unix). 2. Zasadą używaną podczas przesyłania poczty elektronicznej powinno być, że pisana jest przy użyciu narzędzi i zestawu fontów dostępnych lokalnie. 3. Aby taka przesyłka mogła być odebrana poprawnie u odbiorcy, trzeba zapewnić dwie rzeczy: + wszystkie znaki przejdą niezniekształcone przez system poczty, + odbiorca znajdzie w nagłówkach przesyłki informację o sposobie jej zakodowania (żeby wiedział jakich przestawień ma dokonywać). 4. Do osiągnięcia tego celu w Internecie obmyślono standard MIME. Po- zwala on: + na przesyłanie znaków narodowych (czytaj o "niezerowym ósmym bicie") kanałami poczty elektronicznej zgodnymi z SMTP; + na przesyłanie dowolnej przesyłki zawierającej dane "nietekstowe"; + zdefiniowanie typu przesyłanej wiadomości (zawartości przesyłki) - daje to możliwość automatycznego uruchamiania odpowiedniej aplikacji u odbiorcy w celu jej odczytania". 5. Zasady użycia MIME w poczcie określają RFC 1521 "MIME (Multipur- pose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies". RFC 1521 definiuje format wiadomości (zasadniczo zgodny z RFC 822 czy precyzyjniej mówiąc nie naruszający RFC 822, ale rozszerzony o nowe nagłówki), sposoby kodowania informacji (BASE64 i Quoted- Printable) oraz sposób określania zawartości przesyłki. Definiuje również zestaw podstawowych typów (Image, Audio, Video). W rozdziale 7.1.1 definiuje zestawy znaków, które mogą być używane w przesyłkach MIME. Są to: us-ascii i iso-8859-x (0 < x < 10). Można powiedzieć, że ten dokument jest już stary, ale najnowsza jego "wersja" (czy ogólniej draft rfc, który opisuje pocztę elektroniczna) - stanowisko to podtrzymuje. Można znaleźć go szukając pliku o nazwie draft-ietf-822ext-mime-hdrs-00.txt Oba powyżej cytowane dokumenty w identyczny sposób formułują kwe- stię używanych zestawów znaków (cytują za draftem"): Beyond US-ASCII, an enormous proliferation of character sets is possible. It is the opinion of the IETF working group that a large number of character sets is NOT a good thing. We would prefer to specify a SINGLE character set that can be used universally for representing all of the world's languages in Internet mail. Unfortunately, existing practice in several communities seems to point to the continued use of multiple character sets in the near future. For this reason, we define names for a small number of character sets for which a strong constituent base exists. The defined charset values are: (1) US-ASCII - as defined in ANSI X3.4-1986 [US-ASCII]. (2) ISO-8859-X - where "X" is to be replaced, as necessary, for the parts of ISO-8859 [ISO-8859]. Note that the ISO 646 character sets have deliberately been omitted in favor of their 8859 replacements, which are the designated character sets for Internet mail. As of the publication of this document, the legitimate values for "X" are the digits 1 through 9. All of these character sets are used as pure 7bit or 8bit sets without any shift or escape functions. The meaning of shift and escape sequences in these character sets is not defined. The character sets specified above are the ones that were relatively uncontroversial during the drafting of MIME. This document does not endorse the use of any particular cha- racter set other than US-ASCII, and recognizes that the fu- ture evolution of world character sets remains unclear. It is expected that in the future, additional character sets will be registered for use in MIME. Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field. No other character set name may be used in Internet mail without the publication of a formal specification and its registration with IANA, or by private agreement, in which case the character set name must begin with "X-". Implementors are discouraged from defining new character sets unless absolutely necessary. (Zwracam uwagę na pierwszy i ostatni ustęp cytatu: autorzy normy sugerują żebu nie mnożyć bytów nad miarę :-)) 6. W przypadku WWW sprawa jest nieco bardziej skomplikowana. Chyba żaden z obowiązujących dokumentów nie pisze nic na temat zestawu znaków używanych przez protokół http (poza iso-8859-1 i us-ascii). W bardzo wielu miejscach znajdują się tam natomiast odwołania do standardu MIME (przy określaniu typu przesyłanego pliku na przy- kład). Stąd, wydaje się, że można ekstrapolować wszystkie zasady MIME. I rzeczywiście w tym kierunku idzie draft opisujący wersje HTTP/1.1 (Dokument zatytułowany Hypertext Transfer Protocol - HTTP/1.1 można znaleźć w wielu archiwach poszukując pliku o nazwie draft-ietf-http-v11-spec-05). Współzależności i różnice pomiędzy RFC 1521 a standardem HTTP opisane są w rozdziale 19.4 cytowanego dokumentu. Dokument bardzo wyraźnie wypowiada się na temat kwestii używanych zestawów znaków (rozdział 3.4): Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA Character Set registry MUST represent the character set defined by that registry. Applications SHOULD limit their use of character sets to those defined by the IANA registry. Czy (rozdział 3.7.1): The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. I wreszcie w rozdziale 19.8.1: The following names should be added to the IANA character set registry under the category "Preferred MIME name" and this section deleted. "US-ASCII" | "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3" | "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6" | "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9" | "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR" | "SHIFT_JIS" | "EUC-KR" | "GB2312" | "BIG5" | "KOI8-R" Definiuje on zestawy "preferowanych znaków MIME" przy czym ta informacja ma być wpisana do "IANA character set registry", a więc jej znaczenie będzie szersze niż tylko dla HTTP. 7. Najgorzej jest chyba w przypadku NNTP (newsów). RFC opisujący jest tak stary, że nawiązuje jedynie do RFC 822, z tym tylko, że dopusz- cza przesyłanie informacji "binarnych"... Ekstrapolując jednak dalszą ewolucję rfc822, sprawa wydaje się oczywista - należy użyć MIME. Na koniec wreszcie (poza sprawami formalo-prawnymi jeżeli tylko do- kumenty RFC - lub ich projekty - można nazwać prawem) pozostają kwestie czysto techniczne. Otóż wydaje mi się, że z technicznego punktu widzenia, sprawą zasadni- czą jest umieszczanie w standardowy sposób w "nagłówkach" przesyłanych dokumentów informacji o użytym zestawie znaków i typie przesyłki. Tylko bowiem takie postępowanie daje odbiorcy sznsę na automatyczne przekodo- wanie otrzymanago dokumentu do lokalnego standardu wyświetlania i wybór najlepszej aplikacji do jej obejrzenia. Na koniec wreszcie pragnę wyrazić przekonanie, że firma Microsoft buduje oprogramowanie, które stara się być zgodne z obowiązującymi standardami (w tym i MIME). A jedno co jej w tym przeszkadza to brak czasu i ograni- czone zasoby (że zacytuję wypowiedź z FAQ grupy comp.mail.mime - pytanie 1.3.11 "Does Microsoft Mail support MIME?"): All current Microsoft Internet connectivity products are MIME compliant, although somewhat eccentric in their behavior. Oddly enough, the eccentric behavior is not because of Microsoft's alleged goal to dominate the Internet with quasi- proprietary protocols, nor is it out of ignorance. It's just a matter of finite resources and tight delivery schedules. Surprise. (Carl S. Gutekunst 20-Feb-1996)