Sisältö:
Jos haluat tietää nyysien tekniikoista syvällisemmin, ks. Notes On News ("the one stop reading center for newsreader writers").
Internetin toiminta perustuu olennaisesti yhteisiin sopimuksiin eli protokolliin siitä, miten erilaiset tietokoneet, ohjelmat ja järjestelmät ovat vuorovaikutuksessa toistensa kanssa. Sellaiset sopimukset pyritään yleensä kirjoittamaan niin sanotuksi RFC:ksi. Sopimukset ovat välttämättömiä, koska muutoin ei voida saada aikaan sitä, että eri valmistajien erilaiset laitteet, ohjelmat ja järjestelmät "pelaavat yhteen". Olennaista on, että Internetissä asiat voidaan tehdä hyvin monella tavalla; juuri siksi tarvitaan sopimuksia keskeisistä vuorovaikutukseen liittyvistä asioista. Niinpä on esimerkiksi Internetin toimivuuden kannalta yhdentekevää, millä ohjelmalla kirjoitat nyysiartikkelin; mutta olennaista on, että ohjelma lähettää artikkelin siten, että siinä on määrätyt otsaketiedot niin, että kaikki muut, usein hyvin erilaiset, nyyseihin liittyvät ohjelmat voivat käsitellä artikkelin järkevästi, esim. lähettää sen eteenpäin tai näyttää sen käyttäjälleen.
Nyysien osalta perussopimuksena eli -protokollana on RFC 1036. Sen otsikko on Standard for Interchange of USENET Messages, vaikka kyseessä ei olekaan virallinen standardi. Toisaalta tämä jo vuonna 1987 määritelty protokolla on erittäin vakiintunut. Sen ongelmana on kuitenkin rajoittuneisuus: se on kirjoitettu aikana, jolloin mm. merkkivalikoimat olivat paljon suppeampia kuin nykyisin.
Henry Spencer kirjoitti luonnoksen RFC 1036:n seuraajaksi, News Article Format and Transmission, johon usein viitataan nimellä Son of 1036 ja josta RFC 2076 toteaa: "Not even an RFC, but still widely used and partly almost a de-facto standard for Usenet News". Käynnissä on paljolti siihen pohjautuva, UseFor-niminen hanke RFC 1036:n viralliseksi korvaamiseksi uudella määrittelyllä, mutta se etenee hitaasti.
Edellä mainittu RFC 1036 määrittelee artikkelien rakenteen lisäksi hyvin yleisellä tasolla sen, miten artikkelit leviävät eli propagoituvat nyysijärjestelmässä.
Kaavioin kuvitettu lyhyt esitys aiheesta on Jacob Palmen artikkelissa How the Usenet News Protocols Work.
RFC 1036 ei puutu tarkemmin siihen, miten palvelimet "keskustelevat" keskenään artikkelien propagoimiseksi, ei myöskään sitä, miten nyysiohjelma ja palvelin kommunikoivat sitä varten, että käyttäjä saa luettavakseen artikkeleita ja voi niitä lähettää. Käytännössä protokollana näitä tarkoituksia varten on NNTP, jonka nimi johtuu sanoista Network News Transfer Protocol ja jonka määrittelee RFC 977. Tavallinen käyttäjä ei yleensä tarvitse tietoa sen tason protokollista. Joskus kuitenkin RFC 977:stä saattaa olla hyötyä etenkin virheilmoitusten selvittelyssä; voi olla hyvä tietää, että jokin virheilmoitus on tullut nimenomaan palvelimelta, ei nyysiohjelmalta! Janne Kujala ja Panu Mäkinen ovat kirjoittaneet laajahkon suomenkielisen kuvauksen NNTP-protokollasta.
Mainittakoon vielä se joskus sekaannuksia aiheuttava asia, että usein protokollaa kutsutaan samalla nimellä kuin sen yhtä (esim. alkuperäistä) toteutusta. Ohjelma, joka toimii jonkin protokollan mukaan, on toki käsitteellisesti ja käytännöllisesti eri asia kuin protokolla itse! Erityisesti "NNTP" voi tarkoittaa paitsi protokollaa myös erästä ohjelmistoa, kyseisen protokollan alkuperäistä toteutusta. Eräs uudempi toteutus on INN eli InterNetNews. Näitä asioita selostaa mm. dokumentti Usenet Software: History and Sources.
Muita keskeisiä nyyseihin liittyviä protokollia on mainittu ja lyhyesti luonnehdittu Lars Magne Ingebrigtsenin dokumentissa Notes On News. Taustatietoja antaa ja tulevaisuuttakin arvioi Rohit Kharen The News about Jon... Reflections on the Wizard of TPs; and other Network News
Nyysiviestiin liittyy aina joukko otsakkeita (headers). Niitä voidaan verrata kirjekuoren päällä näkyviin tietoihin tai kirjan kansiin (ja nimiösivuun), jolloin itse viesti, "body", vastaa kuoren sisällä olevaa kirjettä tai kansissa olevaa kirjaa. Tärkeimpien otsakkeiden muodon määrittelee edellä mainittu nyysiprotokolla, tällä hetkellä siis RFC 1036. Lisäksi on vaihtelevassa määrin käytössä muitakin otsakkeita, ks. koosteita Common Internet Message Header Fields ja Quick reference to Internet message headers.
Otsake on erotettava otsikosta, joka
esitetään yhdellä otsakeriveistä, Subject-rivillä.
(Nämä nimitykset eivät valitettavasti ole vakiintuneita.)
Seuraavassa esimerkissä on erään artikkelin kaikki otsakkeet:
Path: news.cs.hut.fi!news.clinet.fi!nntp.teliafi.net!news.kolumbus.fi! nntp.se.dataphone.net!newsfeed.online.no!news-feed.inet.tele.dk!bofh.vszbr.cz! newsfeed.wli.net!nntp2.dejanews.com!nnrp1.dejanews.com!not-for-mail From: jkorpela@malibutelecom.com Newsgroups: sfnet.aloittelijat.kysymykset Subject: Re: Voisiko joku =?US-ASCII?Q?yst=E4v=E4llisesti?= auttaa? Date: Fri, 25 Sep 1998 11:59:02 GMT Organization: Deja News - The Leader in Internet Discussion Lines: 14 Message-ID: <6ug0i5$ohm$1@nnrp1.dejanews.com> References: <3607CB67.4320@na.netppl.fi> <6ud4f7$93p$1@ousrvr3.oulu.fi> NNTP-Posting-Host: 193.167.3.6 X-Article-Creation-Date: Fri Sep 25 11:59:02 1998 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95) X-Http-Proxy: 1.1 x3.dejanews.com:80 (Squid/1.1.22) for client 193.167.3.6 Xref: news.cs.hut.fi sfnet.aloittelijat.kysymykset:4997
Käytännön syistä edellä on jaettu Path-otsake
eri riveille. Todellisuudessa se on yhtenä pitkänä rivinä.
Subject-otsakkeen kummallisuus johtuu
(virheellisestä!)
otsakkeen koodauksesta, joka selitetään
jäljempänä kohdassa Mime.
Riippuu nyysiohjelmasta ja sen asetuksista, mitkä otsaketiedot se näyttää ja missä muodossa. Seuraava esimerkki sisältää kyseiset otsaketiedot sellaisina, kuin ne oletusarvoisesti näkyvät Gnus-ohjelmalla katsottuina:
From: jkorpela@malibutelecom.com Subject: Re: Voisiko joku =?US-ASCII?Q?yst=E4v=E4llisesti?= auttaa? Newsgroups: sfnet.aloittelijat.kysymykset Date: Fri, 25 Sep 1998 11:59:02 GMT Organization: Deja News - The Leader in Internet Discussion
Jotkin ohjelmat saattavat esittää otsakkeet esimerkiksi
suomenkielisiä nimityksiä käyttäen, esim. From-otsakkeen
nimellä "Lähettäjä". Mutta itse viestissä, sellaisena kuin ohjelma
sen vastaanottaa tai lähettää, otsakkeiden tulee noudattaa
protokollaa - muuten on jotain
pahasti pielessä.
Seuraavat otsakkeet ovat pakollisia:
Path | Polku, jota pitkin artikkeli on kulkenut (luettava oikealta vasemmalle). |
|---|---|
From | Lähettäjän meiliosoite. Mukana voi olla kommenttikentässä lähettäjän nimi. |
Newsgroups | Ryhmät, joihin artikkeli on lähetetty. |
Subject | Otsikko. |
Date | Ajankohta, jolloin
artikkeli alun perin lähetettiin nettiin.
Lopussa oleva merkintä kertoo aikavyöhykkeen; esim. GMT
tarkoittaa
UTC:tä, ent.
Greenwich Mean Time.
|
Message-ID | Artikkelin tunniste. |
"Pakollisuus" merkitsee tässä, että protokollan mukaan niiden pitää olla mukana. Tästä ei välttämättä seuraa, etteikö artikkeli voisi levitä nyyseihin, vaikka osa pakollisista otsakkeista puuttuu.
Kuten esimerkistämme yllä
näkyy, kaikki nyysiohjelmat eivät suinkaan aina
näytä kaikkia otsakkeita, edes kaikkia pakollisia.
Useat otsaketiedot ovat melko teknistä informaatiota, jonka
näkyminen häiritsisi itse asian lukemista; mm.
Path-otsaketta ohjelmat eivät yleensä näytä,
ainakaan oletusarvoisesti.
Yleensä nyysiohjelmaa voi kuitenkin
käskeä
näyttämään kaikki otsakkeet,
mikä on usein tärkeää
mm. virheiden selvittelyssä
tai ns. spämmistä valitettaessa.
Tämä tehdään esimerkiksi
Tietoja viestien otsakkeiden saamisesta näkyviin meiliohjelmissa on englanniksi sivulla How do I get my email program to reveal the full, unmodified email?. Osa näistä tiedoista on hyödyksi nyysien käytössäkin, koska joitakin meiliohjelmia käytetään nyysien lukemiseenkin.
Joskus taas haluat omaa artikkeliasi lähettäessäsi
kirjoittaa tai
muuttaa sellaisia otsikoita, jotka eivät normaalisti näy
käyttämässäsi ohjelmassa.
Tavallisimmin tämä tulee kyseeseen
siirrettäessä keskustelua toiseen ryhmään,
jolloin pitää päästä muuttamaan Followup-To-otsaketta.
Tarkoitukseen käytetään erilaisia ohjelmakohtaisia
menettelyjä, esimerkiksi
Newsgroups:-otsakkeen alle uudelle riville
tarvittavan otsakkeen (mutta älä jätä tyhjiä rivejä!)
Osan otsakkeista rakentavat erilaiset ohjelmat automaattisesti.
Esimerkiksi Path-otsakkeeseen keräytyy
vaiheittain
tieto siitä,
mitä reittiä pitkin artikkeli kulkee.
Osa taas on peräisin käytetyn nyysiohjelman
asetuksista; ne saattavat olla ihan poskellaan, jos käyttäjä
ei tiedä, miten ne pitää laittaa kuntoon.
Organization-kenttä sisältää periaatteessa tiedon
viestin lähettäjän organisaatiosta, mutta se on hyvin usein mitä
sattuu; esimerkkitapauksessamme se viittaa
Deja-järjestelmään, koska artikkeli oli lähetetty
sen kautta - ilman, että kirjoittaja suinkaan olisi ollut
Dejan leivissä!
Itse asiassa useimmiten vain Subject-otsikko
on käyttäjän kirjoittama, ja sekin yleensä vain, kun artikkeli
aloittaa uuden aiheen, t.s. sitä
lähetetä "follariksi" aiempaan viestiin.
Vastausartikkeleihinhan
käytettävä nyysiohjelma yleensä kirjoittaa automaattisesti
Subject-otsakkeen.
References-otsakkeen rakentaminen on
nyysiohjelman tehtävä, eikä siihen ole syytä käyttäjän puuttua.
Tämä otsake erottaa
vastausartikkelin
"follarin" sellaisesta artikkelista, joka aloittaa uuden aiheen, uuden
threadin.
Otsake sisältää niiden viestien
Message-ID:t, joihin se "viittaa",
niin että viimeisenä se viesti, johon viesti on lähetetty
vastaukseksi, ja sitä ennen on mahdollisesti se viesti, johon tämä
puolestaan oli vastaus jne.
(Jotkin ohjelmat kyllä ottavat viestejä
threadeiksi järjestäessään huomioon myös niiden
Subject-otsakkeet ainakin osittain.
Mutta References on se otsake, joka
protokollan mukaan ilmoittaa artikkelien
suhteet toisiinsa.) Kun rupeat kirjoittamaan vastausartikkelia, on
käyttämäsi ohjelman tehtävä rakentaa sinun viestiisi
References-kenttä.
References-otsakkeesta on hyötyä, kun lukemasi viesti
on vastaus johonkin viestiin, jota et ole nähnyt. Kyseisen otsakkeen
lopussa olevaa Message-ID:tä käyttämällä löydät
yleensä viestin, tavalla tai toisella.
Nyysiartikkelien otsakkeet ja koko rakenne muistuttavat suuresti
meiliviestien otsakkeita ja rakennetta.
Erona on keskeisesti vain se, että nyysiartikkelissa on
Newsgroups-otsake, meiliviestissä taas
To-otsake.
Samanlaisuus ei toki ole sattumaa, vaan nyysiartikkelien rakenne
suunniteltiin siten, että se on muunnelma meiliviestien rakenteesta,
jonka määrittelee vuonna 1982 kirjoitettu
RFC 822,
joka oli voimassa vuoteen 2001
Internet-standardina, STD 11.
(Uusi standardi
RFC 2822 on lähinnä RFC 822 jonkin verran
modernisoituna ja täsmennettynä.)
Message-ID-otsake
sisältää
viestin yksikäsitteisen tunnisteen.
Tunniste koostuu alkuosasta, @-merkistä ja sen
koneen Internet-nimestä tai -osoitteesta, jonka kautta
artikkeli alun perin lähetettiin nyyseihin; tämän ympärillä on useissa yhteyksissä
(mm. juuri Message-ID-otsakkeessa) oltava merkit
< ja >.
Tunnisteen alkuosa näyttää siansaksalta, koska se on ohjelman generoima ja
koska se on tarkoitettu ohjelmien käsiteltäväksi, ei juurikaan
ihmisen luettavaksi tai kirjoitettavaksi.
Edellä esitetyssä esimerkissä tunniste oli
<6ug0i5$ohm$1@nnrp1.dejanews.com>
Message-ID:n perusteella voidaan muodostaa
URL, joka viittaa viestiin, kirjoittamalla sen eteen
news:. Valitettavasti Web-selaimet eivät useinkaan ymmärrä niitä,
mutta useat nyysiohjelmat osaavat toimia järkevästi: ne näyttävät tuota muotoa
ovat rakenteen ikään kuin linkkinä, jota seuraamalla käyttäjä saattaa päästä
lukemaan viestiä, johon on viitattu. Tämä on joskus näppärää viitattaessa
artikkelissa johonkin toiseen, suhteellisen tuoreeseen viestiin.
Kyseistä tunnistetta ei pidä sekoittaa viestin numeroon, joka on
paitsi ryhmäkohtainen myös
palvelinkohtainen asia.
(Viestin numero kyllä usein näkyy
Xref-otsakkeessa, mutta
kyseinen otsake on nimenomaan sellainen, jonka sisällön kukin
palvelin muuttaa, kun artikkeli leviää
nyysijärjestelmässä!)
Mime on protokolla, joka kehitettiin alun perin mahdollistamaan muunkin kuin tekstin lähettäminen meilin kautta. Tätä kuvastaa se, että nimi on lyhenne sanoista Multipurpose Internet Mail Extensions. Protokollan nykyinen määrittely sisältyy RFC 2045:een ja RFC 2046:een sekä lukuisiin niitä täydentäviin dokumentteihin; ks. koostetta Multipurpose Internet Mail Extensions MIME, joka sisältää mm. aihetta koskevat perus-RFC:t hypertekstimuodossa ja niiden yhteisen sisällysluettelon.
Periaatteessa
Mime mahdollistaa sen, että niin meiliviestissä
kuin nyysiartikkelissakin on mitä hyvänsä dataa, jolle on määritelty
mediatyyppi (Mime-tyyppi).
Tämä tyyppi ilmaistaan viestin
Content-Type-otsakkeessa.
Viestin sisältö voisi olla vaikkapa ns. multipart-viesti
eli useasta erityyppisestä osasta koostuva kokonaisuus, joka
sisältää vaikkapa äänitiedoston, videonpätkän ja HTML-dokumentin.
Käytännössä tällaisten viestien lähettäminen on syytä
rajoittaa tilanteisiin, joissa viestinnän kaikki osapuolet
ovat siihen valmiit - "between consenting adults", kuten
jotkut asian ilmaisevat. Useimmiten multipart-viestin
ilmestyminen johtuu siitä, että käyttäjä on tietämättään käyttänyt lähettämiseen
Web-selainta, jota ei ole konfiguroitu kuntoon.
Monet palvelimet poistavat automaattisesti keskusteluryhmistä kaikki muut viestit kuin pelkkää tekstiä sisältävät. Google ei arkistoi muita kuin tekstiviestit. Näin ollen jos esimerkiksi liität artikkeliisi kuvan, varsin monet ihmiset eivät näe viestiäsi lainkaan.
Ihmiset voivat sopia keskenään vaikka minkämuotoisen aineiston lähettämisestä meilitse, kunhan tietävät, mitä tekevät, ja ovat varmistaneet, että vastaanottajan ohjelma selviää siitä, mitä lähettäjän ohjelma lähettää. Nyyseissä tämä ehto ei täyty juuri koskaan. Et voi järkevästi olettaa, että nyysien lukijoiden käyttämät ohjelmat selviäisivät muusta kuin tekstimuotoisesta datasta - siinäkään tapauksessa, että oma ohjelmasi osaisi lähettää sen oikealla tavalla (mikä ei ole mitenkään varmaa).
Poikkeuksen voivat muodostaa erikoisryhmät, joiden
omissa kuvauksissa ja säännöissä selkeästi sanotaan, että
niihin voi lähettää muutakin aineistoa.
Tyypillisesti sellainen ryhmä on
binaariryhmä, joka
olemassa vain
binaaridatan lähettämistä varten.
Aiemmin sellaista varten oli olemassa
sfnet.tiedostot, mutta se lakkautettiin
laajamittaisen väärinkäytön takia.
Kansainvälisiä binaariryhmiä on suuri määrä, mm.
alt.binaries-ryhmät.
Binaaridata tarkoittaa tässä yhteydessä mitä tahansa aineistoa, joka ei ole pelkkää tekstiä. Myös esim. Word-dokumentti katsotaan binaaridataksi, koska se sisältää muotoiluinformaatiota eikä ole sellaisenaan (ilman Word-ohjelmaa tai vastaavaa) luettavissa. Teoreettisesti voitaisiin kiistellä siitä, onko esim. HTML-muotoinen dokumentti tai vaikkapa LaTeX-dokumentti tekstiä vai binaaria; käytännöllinen vastaus on joka tapauksessa, että kummatkaan eivät kuulu nyyseihin. (HTML:ää tai LaTeXia käsittelevässä ryhmässä toki lyhyehköt otteet HTML- tai LaTeX-koodista ovat toki sallittuja silloin.)
Kirjoittamalla nyyseihin vain tekstiä parannat siis huomattavasti mahdollisuuksia saada viestisi perille. Esimerkiksi jos lähetät nyyseihin kysymyksen (esim. "mikähän sieni tämä on") ja sinulla on siihen liittyvä kuva (esim. piirros tai valokuva), niin älä lähetä itse kuvaa nyyseihin. Laita kuva Web-sivullesi ja kerro sen URL. Jos sinulla ei ole omaa Web-sivutilaa tai et osaa käyttää sitä, laita kuva esimerkiksi johonkin ilmaispalvelimeen kuten ImageShack tai PhotoBucket.
Kuvan laittaminen Webiin on vaikeudeltaan samaa luokkaa oleva asia kuin sen lähettäminen nyyseihin olisi. Mutta jos se jostain kumman syystä on mahdotonta, niin käytä edes jotain binaariryhmää (eikä keskusteluryhmää) kuvan lähettämiseen. Itse kysymyksen lähetät silloin tietenkin siihen ryhmään, mihin se kuuluu, ja mainitset, minne olet kuvan lähettänyt.
Binaaridatan lähettäminen nyyseihin on myös resurssien tuhlausta, koska esimerkiksi pienehkö kuvakin digitaalisessa muodossa vie paljon tilaa ja siirtoaikaa. Dokumentti The Bincancel FAQ perustelee asiaa tarkemmin. Huomaa myös, että jos liität nyysiartikkeliisi binaariliitteen, koko juttu - myös tekstisi - jää monelta lukematta, koska jokin tai joku suodattaa pois artikkeleita.
Ns. täysi newsfeed eli se määrä dataa, jonka nyysipalvelin ottaa vastaan, jos sen valikoimaan kuuluvat "kaikki ryhmät", oli erään arvion mukaan 350 gigatavua vuorokaudessa vuodenvaihteessa 2002/2003. Siitä binaariryhmien osuus on yli 99 %. (Arvio syysk. 1999: 50 gigatavua, siitä binaariryhmät 48 gigatavua.) ja Nykyisin kun binaareja on suurimmaksi osaksi vain erillisissa binaariryhmissä, palvelimen ylläpidon on helppo karsia binaareja pois tai kohdella niitä eri tavalla kuin tekstiartikkeleita, esim. asettaa lyhyempi ekspiroitumisaika. Jos binaareja olisi huomattavassa määrin muissakin ryhmissä, tilanne kävisi aika mahdottomaksi. Tässä on siis kyse palvelinten ja niiden ylläpidon resursseista. Tämän lisäksi tulevat vielä käyttäjien ongelmat. Nyysiohjelmaa ei ehkä lainkaan voi käskeä hakemaan vain määrätyn koon alittavat artikkelit (saati tunnistamaan binaarit!), joten esim. modemikäytössä syntyy erittäin inhottavia tilanteita, kun käyttäjä pyytää ohjelmaansa hakemaan uudet artikkelit ja seassa on yksikin iso binaari - ehkä vielä vahingossa useaan kertaan lähetettynä! (Jostakin syystä ihmiset, jotka lähettävät nyyseihin binaareja, usein töpeksivät muutenkin.)
Erityisesti ns. HTML-muotoiset viestit ovat typeriä monestakin syystä. Sama koskee sellaisia ns. multipart-viestejä, joissa on teksti tekstinä ja erikseen "HTML:nä" jossakin järjestyksessä ynnä lisäksi lisärivejä, jotka näyttävät lähinnä apinan kirjoittamilta. Ne tuhlaavat resursseja, koska viestit ovat paljon pidempiä kuin varsinainen teksti, eikä mukana juuri koskaan ole lisäinformaatiota. Päinvastoin siinä on disinformaatiota kuten pyrkimys pakottaa lukija näkemään teksti senkokoisilla ja -näköisillä kirjaimilla, joilla lähettäjä sen kirjoitti! "HTML-muoto" on käytännössä jonkin nyysiohjelman suoltamaa soopaa, joka ei yleensä ole edes muodollisesti oikeaa saati järkevää HTML-kieltä. Ja käsityksen siitä, miltä "HTML:ää" sisältävä, ns. multipart-viesti näyttää esim. Google Groups -järjestelmän kautta katsottuna, antanee seuraava ote:
Esimerkki on omasta testistäni: Lähetin testiviestin Outlook Expressillä asetuksin, jotka saattaisivat aivan hyvin olla normaaliasetukset (oletusasetukset). Kirjoitin viestin runkoon kaksi riviä ja niiden väliin tyhjän rivin, mutta OE lähetti sen ns. multipart-viestinä, jossa on kymmeniä rivejä. Vaikka esim. OE itse osaa luettaessa jotenkin tulkita tällaisen, niin esim. Google Groups ja monet nyysiohjelmat näyttävät sen sellaisenaan.
Katso myös Mika Latokartanon kirjoittamia perusteluja sille, että keskusteluryhmiin ei ole syytä lähettää binaareja.
Yksi Mimessä määritellyistä asioista on se, miten nyyseissä (ja meilissä) voidaan käyttää laajempaa merkkivalikoimaa kuin Ascii - käyttäen kuitenkin vain Ascii-merkkejä! Ideana tässä on sopia joistakin koodauksista. Koodausta voisi verrata salakirjoitukseen: merkit esittävät muita merkkejä joidenkin sääntöjen mukaan. Voidaan vaikkapa sopia, että kolmen Ascii-merkin jono =E4 tarkoittaa ä-kirjainta (joka ei ole Ascii-merkki).
Tällaisessa koodauksessa, aivan päinvastoin kuin salakirjoituksessa, perusajatuksena on, että käytetty menetelmä on julkisesti kuvattu. Mime-protokollakokonaisuuteen kuuluva RFC 2045 määrittelee seuraavat koodausmenetelmät:
=xx
(esim. ä-kirjaimen esitys on =E4)
UmVzZWFyY2g).
Ks. myös Michael Santovecin opasta Decoding Internet Attachments, joka kuvailee näiden lisäksi myös muita usein käytettyjä koodausmenetelmiä.
Koodauksen yksinkertaisuus tai monimutkaisuus ei sinänsä ole kovin olennainen asia, koska tarkoitus on, että koodaamisen ja koodauksen purkamisen (dekoodauksen) tekevät ohjelmat, eivät ihmiset. Periaatteessa vain sellaisten ohjelmien tekijöiden tarvitsee tuntea koodausmenetelmät.
Käytännössä tilanne
voi olla toinen, koska kaikki käytettävät ohjelmat eivät
suinkaan tunne kaikkia käytettyjä koodauksia vaan saattavat
useinkin näyttää käyttäjälle koodatun datan sellaisenaan
(siis esim. "yst=E4v=E4llisesti", ei
"ystävällisesti").
Niinpä onkin yleensä parempi esimerkiksi suomeksi nyyseihin
kirjoitettaessa käyttää ns. 8-bittisiä merkkejä
sellaisinaan,
ISO Latin 1 -merkkeinä, eikä koodattuina. Tällöin tulisi
huolehtia siitä, että otsaketiedoissa on
Content-Type: text/plain;charset=iso-8859-1
Yleisesti Content-Type-otsakkeessa voidaan kertoa
paitsi mediatyyppi (Mime-tyyppi)
kuten text/plain myös se merkkikoodi, jonka
mukaan data on esitetty. Merkkikoodi vastaa tässä yhteydessä
käsitettä
"character encoding",
mutta se on erotettava koodauksesta
edellä kuvatussa merkityksessä, joka sisältää jonkin merkistön
esittämisen jotakin toista merkistöä (yleensä Ascii) käyttäen.
Todettakoon, että tämä ei vain kuulosta vaikealta ja sekavalta,
se on vaikeaa ja sekavaakin; merkkikoodiasioita yrittää selittää
A tutorial on character code issues.
Viestien sisällön lisäksi myös
otsakkeissa, etenkin
Subject-otsakkeessa, halutaan usein käyttää
muitakin kuin Ascii-merkkejä
Mime-protokollakokonaisuuteen kuuluva
RFC 2047 määrittelee tätä varten erään menetelmän.
Menetelmä on seuraavanlainen:
=? aloittaa
ja merkkipari ?= lopettaa osuuden, joka on
koodattu. (Otsakkeen muu osa tulkitaan Ascii-tekstiksi.)
?koodaus?dataISO-8859-1)
kertoo, minkä merkkivalikoiman merkkejä on koodattu, koodaus
kertoo koodauksen (Q = Q-koodaus, joka
on käytännössä vastaava kuin Quoted Printable,
B = Base64)
Aiemmin esitetyssä otsake-esimerkissä oli otsake
Subject: Re: Voisiko joku =?US-ASCII?Q?yst=E4v=E4llisesti?= auttaa?US-ASCII on virheellinen. Eihän ä-kirjain suinkaan
kuulu Ascii-merkistöön! Jos merkkivalikoimana olisi
ISO-8859-1, niin otsake olisi periaatteessa oikea.
Käytännössä otsakkeiden koodausta ei yleensä kannata käyttää. Ensinnäkään nyysiohjelmat eivät useinkaan osaa tehdä sitä oikein, kuten esimerkistäkin ilmenee. Toiseksi nyysiohjelmat eivät useinkaan osaa tulkita (purkaa) koodausta silloinkaan, kun se on tehty oikein. Esimerkiksi Google Groups näyttää viestin otsikon sotkuna, jos siinä on käytetty em. koodausta. (Aiheesta on lisää erillisessä artikkelissani skandeista.) Nyysiviestien otsikoihinkin on siis parasta kirjoittaa ä:t ja ö:t sellaisinaan, ja laittaa nyysiohjelman asetukset sellaisiksi, että ohjelma myös lähettää ne sellaisinaan, koodaamattomina.