Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering

TidBITS#515/31-Jan-00

De kwis van vorige week bracht een duister onderwerp voor het voetlicht: welke codeermethode kan je best gebruiken om e-mail attachments naar Windows gebruikers te sturen? Adam trekt zijn lieslaarzen aan om uit te leggen dat de beste methode eigenlijk nummer twee was, en waarom het meest gegeven antwoord ook niet echt verkeerd is. We kijken ook naar Digital Media Remote van Keyspan, we geven oude versies van de Internet Starter Kit vrij op het web, en we noteren de uitgave van SETI@home 2.0 client.

Onderwerpen:

Copyright 2000 TidBITS Electronic Publishing. All rights reserved.
Information: <[email protected]> Comments: <[email protected]>

-> Denk je dat TidBITS interessant is voor <-
-> je vrienden, kennissen, collega's? Geef <-
-> hen de tip zich ook GRATIS te abonneren <-
-> of stuur deze aflevering naar hen door! <-

Je kunt je gratis abonneren op de Nederlandse afleveringen van TidBITS door een (blanco) mailtje te sturen naar: [email protected]. Je krijgt deze dan per e-mail toegestuurd.
Om je abonnement op te zeggen, kun je een mailtje sturen naar: [email protected].

Deze editie van TidBITS werd gedeeltelijk gesponsord door:

De Nederlandse editie van TidBITS is een letterlijke vertaling van de oorspronkelijke Engelse versie. Daarom is het mogelijk dat een deel van de inhoud niet geldt in bepaalde landen buiten de USA.

Dit nummer werd uit het Engels vertaald door:

Verder werkten mee:

MailBITS/31-Jan-00

[vertaling: IdM]

Speurtocht naar E.T. gaat verder met SETI@home 2.0 -- Het SETI-project (Search for Extraterrestrial Intelligence) heeft zijn SETI@home client geüpdatet naar versie 2.0, met toevoeging van beveiligingsvoorzieningen, verbeterde proxy-ondersteuning en bug-fixes. De SETI-software gebruikt rekenkracht van computers om gegevens van de Arecibo radio-telescoop te analyseren. (Zie "SETI Brengt Heelal Exploratie naar de thuis-Macs" in TidBITS-482.) De nieuwe software probeert de pogingen te dwarsbomen van sommige mensen om hun waardering te verhogen door het opsporen van ongeoorloofde veranderingen aan data-bestanden en die bestanden te vernietigen. Het gevolg is dat nieuwe gegevensverwerkers de SETI@home 2.0 software nodig hebben; met andere woorden, je moet updaten om verder mee te doen met het project. De software pakt ook uit met betere ondersteuning voor SOCKS en HTTP-proxy's, compatibiliteit met Mac OS 9, nauwkeuriger berekening van CPU-tijd, en snellere verwerking van gegevens als het programma-venster wordt verborgen door het Venstersluiter-regelpaneel. Op grafisch gebied heeft de SETI@home 2.0 een nieuwe indicator die resultaten weergeeft in Gauss-curves. Door een bestaande bug moeten Systeem 7.x-gebruikers die de Appearance Manager niet gebruiken wachten op een nakende release. SETI@home 2.0 vraagt een PowerPC Mac met minstens 24 MB RAM en kan gratis worden gedownload (360 K). [JLC]

<http://setiathome.ssl.berkeley.edu/>
<http://db.tidbits.com/getbits.acgi?tbart=05401>
<http://setiathome.ssl.berkeley.edu/mac.html>

Oude Starter Kits nu online -- Vorige week schreef een lezer dat hij de online versies van mijn Internet Starter Kits-boeken (3de uitgave Mac, 2de uitgave Windows 3.1) niet kon vinden op de site van MacMillan Computer Publishing door nogmaals een reorganisatie. In plaats van voor de zoveelste keer te proberen mensen op die site te vinden en door te verwijzen, heb ik de volledige tekst van deze boeken op de website van TidBITS geplaatst. De bespreking van internet is waarschijnlijk nog min of meer correct, maar de details over programma's zijn enorm verouderd. Maar zelfs die oude informatie kan nuttig zijn voor iemand die een internet-verbinding wil tot stand brengen of repareren op een oude Mac of PC. Ik weet dat ik af en toe verwijs naar die boeken als ik me niet meer kan herinneren hoe je Mac TCP of Mac PPP moet configureren. Ik hoop dat mensen de boeken nuttig blijven vinden, ondanks hun leeftijd. [ACE]

<http://www.tidbits.com/iskm/iskm3html/>
<http://www.tidbits.com/iskm/iskw2html/toc.html>

Voorbeschouwing van opinipeiling: They Come in Colors -- Volgende week bekijken we Canvas 7.0, Deneba's jongste versie van het Zwitsers zakmes onder de grafische programma's. Behalve Canvas, waar deelnemend redacteur Matt Neuburg al lang in geïnteresseerd is, besteden we meestal weinig aandacht aan grafische programma's omdat de meesten van ons in een meer tekst-georiënteerde wereld leven. Dus vertel ons, wat zijn de grafische programma's die jullie het meest gebruiken om beelden te maken en te bewerken? We hebben een paar grote namen geselecteerd voor de antwoorden van de peiling, maar we zijn ons er van bewust dat er veel andere mogelijkheden bestaan. Daarom hebben we een thread gestart in TidBITS Talk waarin jullie ons kunnen vertellen welke andere programma's jullie gebruiken en waarom jullie ze goed vinden. [ACE]

<http://www.tidbits.com/>
<http://db.tidbits.com/getbits.acgi?tlkthrd=928>

Beter dan Draadverbinding

door Adam C. Engst <[email protected]>
[vertaling: MSH, LmR, JG]

Mijn familie hield altijd van afstansbedieningen. Vele jaren geleden - lang voordat iedere TV met een afstandsbediening werd geleverd - hadden mijn ouders een instrumentje dat ze een bleeper noemden. Het was een kleine elektrische schakelaar waarmee ze het geluid van de TV konden uitzetten zodra er reklame verscheen. Toen het tenslotte stuk ging bleek het onvervangbaar te zijn en mijn vader's oplossing was een beetje ongewoon. Hij kocht een bowdenkabel (algemeen gebruikt om handmatig het brandstof/luchtmengsel voor motoren bij te stellen), boorde toen een gaatje door de volumeknop van de TV, stopte een spijker in de knop en verbond de spijker met de kabelbediening. Toen hij klaar was kon je door duwen of trekken de kabel langer of korter maken, daardoor bewoog je de spijker en veranderde het TV volume - voor het gemak was hij bevestigd op de muur naast de zitbank. Het was eigenaardig, maar het werkte. Verplaatsen van de TV of het volume veranderen elders dan vanuit de zitbank was zelden nodig - en de eigengemaakte afstandsbediening was nooit zoek.

Al is een afstandbediening nu standaard bij televisietoestellen, in de computerwereld hebben we er in geen jaren aan gedacht. Immers, een personal computer gebruikte je alleen maar als je er voor zat, en er was dus weinig behoefte aan welke afstandsbediening dan ook. Infrarode muizen bestonden al enige tijd en de van ouds bekende Macintosh schrijver Andy Ihnatko heeft zijn Frankenstein-achtige benaderingen beschreven om van robotspeeltjes afstandsbedieningen te maken. Nochtans had ik geen belangstelling voor afstandsbediening van de computer totdat we verslaafd raakten aan het in de keuken op de Mac afspelen van onze CD verzameling als MP3 bestanden. Soms dienden we plots de muziek te laten pauzeren of laten zwijgen zodra de telefoon ging, of het volume zachter te zetten bij aan tafel gaan voor het avondeten.

<http://db.tidbits.com/getbits.acgi?tbart=05589>

Keyspan Invoegen, Kant en Klare Oplossing -- De ideale oplossing voor ons dilemma zou MacSpeech's ListenDo kunnen zijn, dat ik nu geïnstalleerd heb, maar ik heb nog geen tijd gehad om het te configureren voor de soort taken die ik wenste. En je weet maar nooit of spraakherkenning goed zal werken als meerdere lieden praten en keukengedruis de op de computer gerichte spraak belemmert.

<http://www.macspeech.com/>

Maar wat er is en wat werkt, zo uit de doos, is Keyspan's $79 Digital Media Remote, in het algemeen benoemd als DMR. De op USB gebaseerde DMR is tweedelig, een ontvanger die in de USB poort geplugd wordt en een inkeping heeft voor het tweede deel, een half-inch dikke afstandsbediening ter grootte van een creditkaart. De afstandsbediening heeft 15 knoppen, waarvan 8 een label hebben met iconen, die start, stop, ga vooruit of terug, en verhoog of verlaag de geluidssterkte betekenen. Verder 4 pijlknoppen, die ruitvormig zijn geplaatst, met een Selecteerknop in het midden. De laatste twee knoppen zijn een Menuknop en een knop met een sterretje erop, die de Cycle-knop wordt genoemd.

<http://www.keyspan.com/products/usb/remote/>
<http://db.tidbits.com/getbits.acgi?tbart=05609>

Gezien vanuit hardware standpunt werkt de DMR voortreffelijk. Zoals bij alle infrarood afstandsbedieningen is een onbelemmerde lichtweg vereist, maar meestal kun je de straal ook laten reflecteren via een muur. Ik testte hem voor de grootste afstand in huis voorkomend (ongeveer 35 tot 40 voet), en de ontvanger had er geen moeite mee het signaal op te pikken. Ik zou me storing kunnen voorstellen in een grote gehoorzaal, maar ik veronderstel dat hij in bijna alle omstandigheden zal werken.

Omdat ik de DMR testte met een iBook wilde ik de ontvanger niet de hele tijd aangesloten laten, de software van Keyspan had er echter geen moeite mee dat de ontvanger steeds of aangesloten en/of verwijderd werd.

Doe alsof het een toetsenbord is -- De software die bij de Keyspan DMR wordt geleverd is functioneel maar niet indrukwekkend. Het komt er op neer dat de DMR een toetsenbord emuleert - alles wat het kan typen kan je programmeren naar en van de toetsen op de remote. De DMR heeft standaard een aantal key mappings voor diverse applicaties, en een default mapping die actief is als er een onbekend programma op de voorgrond draait. Samen met de Finder en Microsoft PowerPoint, zijn de applicaties die herkend worden voornamelijk multimedia applicaties zoals QuickTime Player, SoundJam MP, en AppleCD Audio Speler. Je kan je eigen mappings definiëren voor deze andere applicaties, hetgeen handig is als je een andere MP3 speler of presentatieprogramma gebruikt.

In de eerste uitgave installeerde Keyspan twee onderdelen in de map Regelpanmelen, een Keyspan DMR Assistant die hielp bij status en diagnostics en een Keyspan DMR Manager waarmee key mappings konden worden gedefiniëerd. In de net uitgegeven en gratis beschikbare 1.2 versie verplaatste Keyspan de Manager applicatie naar de map Voorkeuren en voegde een Configure knop toe aan de Assistant. Keyspan veranderde tevens de key mapping interface door het af te zonderen in een apart dialoogvenster in plaats van het in het standaardvenster te houden.

<http://www.keyspan.com/products/usb/remote/downloads/>

Helaas gaan deze veranderingen, ook al zijn ze handig, voorbij aan de fundamentele interface problemen met de software. Bij voorbeeld het standaard statusvenster van de Assistant, dat slechts vertelt welke driver en mapper op het ogenblik actief zijn, zouden kunnen worden weggewerkt in een status-dialoogvenster. Verder geeft de Manager de namen van de beschikbare knoppen op de remote die je bij naam kan definiëren, terwijl slechts twee van de 15 knoppen namen hebben. De anderen hebben slechts iconen, dus is het moeilijk een verband te leggen tussen de naam "Cycle" en de knop met de asterisk erop. Een grafische afbeelding van de remote voor mapping van de toetsen naar de knoppen zou de software gebruikersvriendelijker maken. En ten slotte is er de kwestie waarom de software eigenlijk in twee utility's is gesplitst, terwijl vanuit een gebruikersstandpunt deze gemakkelijk zouden kunnen worden gebundeld in een enkel regelpaneel.

Ga naar het Westen, Ongeveer 11 Meter -- Wat ik zie als de verborgen functionaliteit van de DMR is de mogelijke combinatie met macro programma's zoals OneClick, QuicKeys, of KeyQuencer. Alhoewel je bijvoorbeeld de Cycle knop herhaaldelijk zou kunnen drukken om SoundJam naar voren te brengen (als default schakelt Cycle tussen applicaties door Command-Tab na te doen), druk dan de Menu knop (die de Keyspan software uitwerkt naar Command-M of Mute als default). Zou het niet eleganter zijn een macro te creëren die naar SoundJam overschakelde en Command-M met een enkel bevel typte? En alhoewel je beperkt bent tot 15 knoppen op de afstandsbediening, betekent dat 15 bevelen per applicatie. Dus zou je er makkelijk een macro aan kunnen verbinden die de Finder naar een van de knoppen schakelt en dan bepaal je 15 macro's die geactiveerd kunnen worden via de knoppen als je in de Finder bent. De hemel is de limiet als je die verbinding met een macro programma gemaakt hebt - richt de afstandsbediening naar je Mac van de andere kant van de kamer en druk op een knop en de Mac zou kunnen zeggen hoe laat het is, of wanneer je volgende afspraak is (misschien met behulp van AppleScript), of je zou een bepaalde groep applicaties kunnen starten. Bijna alles dat je wil doen maar waarvoor je niet rechtstreeks vóór de computer hoeft te zitten wordt mogelijk.

Zelfs al is de software voor de Keyspan DMR niet perfect, het is moeilijk om al te veel te klagen, omdat het toestel goed werkt en omdat het onwaarschijnlijk is dat je je eigen uitwerkingen zo vaak zal definiëren. Als je een behoefte aan een infrarood-afstandsbedieningsapparaat kan voorstellen die iedere applicatie op jouw Mac kan besturen (of in Windows - het werkt ook met USB-uitgeruste PC's die Windows 98 gebruiken), kan je niet verkeerd gaan met Digital Media Remote van Keyspan.

Een Uitleg over Formaten van E-mail Attachments

door Adam C. Engst <[email protected]>
[vertaling: DPF, HvH, MK, JS, PEP]

Okee, misschien hebben we bij een aantal mensen verwarring veroorzaakt met de quiz van vorige week. De vraag was wat de beste coderingsmethode voor een bestand was wanneer je dat bestand naar een Windows gebruiker wilde sturen via e-mail. Ik zal zo meteen het juiste antwoord geven, maar laat me eerst even ingaan op de bronnen van verwarring.

Terminologie -- Zoals ik heb uitgelegd in "Macintosh Internet Bestandsformaat Inleiding," in TidBITS-445, zijn er gewoonlijk twee acties die plaats vinden wanneer Macintosh bestanden via e-mail verstuurd worden: het verpakken als binary en het coderen voor verzenden. Het verpakken als binary is de kern van formaten als AppleDouble, AppleSingle en MacBinary lost het probleem op dat andere platformen in principe niet overweg kunnen met Macintosh bestanden omdat ze zowel data- als gegevensvorken hebben. Coderen voor verzenden, meestal via Base64 of uuencode, zet een 8-bit bestand om in een 7-bit ASCII tekstbestand dat de reis door Internet e-mail kan overleven, omdat verzending alleen maar gegarandeerd kan worden wanneer het om 7-bit ASCII data gaat. Het BinHex formaat combineert zowel verpakken als binary en coderen voor verzending.

<http://db.tidbits.com/getbits.acgi?tbart=05066>

Dat is het punt waarbij de verwarring ontstond. De meeste e-mailprogramma's, zoals Eudora, Emailer en Outlook Express noemen het proces van een aangehecht bestand formatteren voor verzinding "encoding", waarbij ze dus het verpakken in binary met het coderen voor verzending samennemen. In het algemeen is dat een probleem voor gebruikers, maar het zorgde wel voor wat verwarring in onze quiz voor die mensen die wisten dat Base64 (dat de meeste stemmen kreeg) een coderingsformaat voor verzenden is, terwijl AppleDouble (nummer 2) technisch gesproken een binair verpakkingsbestand is.

Nu vraag je je misschien het volgende af: "Indien AppleDouble alleen maar als binary verpakt, hoe overleeft zo'n bestand dan in een e-mail?" Het antwoord is dat een attachment wanneer het met AppleDouble wordt verpakt en via e-mail verstuurd wordt ook automatisch met Base64 gecodeerd wordt. Onder de meeste omstandigheden is die Base64 encodering transparant voor de gebruikers aan beide zijden. Laat me daarom wat dieper ingaan op alle formaten voor e-mail attachments.

Het Juiste Antwoord: AppleDouble -- Ondanks de verwarring die we per ongeluk hebben veroorzaakt, is AppleDouble het beste formaat om te gebruiken wanneer je attachments naar Macintosh of Windows gebruikers verstuurt, en vooral als je hetzelfde bestand tegelijkertijd naar Mac en Windows gebruikers verstuurt. De reden hiervoor is dat AppleDouble de Macintosh data- en resourcevorken van een bestand apart neemt, en ze ieder afzonderlijk weer aan het bericht bevestigt, waarna ze bovendien met Base64 worden gecodeerd voor verzending. Als een modern Macintosh e-mailprogramma de twee attachments ziet, decodeert het de Base64 en voegt ze dan weer samen in een enkel bestand. Als een e-mailprogramma op een ander platform de twee attachments ziet, gooit het de resourcevork weg en decodeert het alleen de datavork, daar andere platforms de Macintosh resourcevorken niet begrijpen.

Sommige mensen hebben vraagtekens gezet bij mijn voorkeur voor AppleDouble boven uuencode voor het verzenden van bestanden naar Windows gebruikers. In werkelijkheid zal uuencode meestal werken, maar dit is waarom ik AppleDouble verkies boven uuencode:

"AppleDouble is het geprefereerde formaat voor een Macintosh bestand dat in een Internet mail bericht opgenomen moet worden, omdat het ontvangers met Macintosh computers voorziet van het gehele document, inclusief iconen en andere specifieke Macintosh informatie, terwijl andere gebruikers eenvoudig de datavork (de werkelijke data) kunnen uitnemen daar deze gescheiden is van de AppleDouble codering."

<http://www.cis.ohio-state.edu/htbin/rfc/rfc1740.html>

Gebruik van en zich houden aan standaarden is een goede zaak, en het is de voornaamste reden dat we vandaag de dag over Internet beschikken. Hoe eerder we ons ontdoen van verouderde e-mailprogramma's die alleen oude attachment formaten begrijpen, hoe beter, en des te eerder worden artikelen als dit overbodig.

Weet dat sommige Macintosh e-mailprogramma's niet de term "AppleDouble," gebruiken maar het in plaats daarvan "MIME," noemen en zelfs Eudora is begonnen het "AppleDouble ("MIME")." te noemen. Dat is niet helemaal onredelijk, daar "AppleDouble" niet de indruk wekt dat het geschikt is voor het versturen van bestanden naar Windows gebruikers. Het probleem echter is dat MIME iets anders betekent in Windows programma's (en in Outlook Express 5.0 voor de Mac), daar Windows helemaal geen binaire verpakking gebruikt, dus "MIME" betekent slechts "Base64 codering" voor binaire bestanden die aan e-mail zijn bevestigd.

Het voornaamste probleem met AppleDouble is dat het in een aantal uitzonderlijke gevallen niet werkt, meestal bij mensen achter oude e-mail poorten die de Internet standaarden niet goed ondersteunen. In dat geval gebruik je wat volgens jou zal werken.

AppleSingle -- Waar AppleDouble de data- en resourcevork in twee (attachment-)bestanden splitst, bundelt AppleSingle deze samen in een enkel bestand (net zoals MacBinary, dat niet wordt gebruikt voor e-mail). AppleSingle's bruikbaarheid voor e-mail attachments is minimaal, daar het nauwelijks wordt ondersteund in het Macintosh e-mail-universum. De voornaamste reden waarom AppleSingle nog steeds bestaat is dat de MacMIME specificatie ook zegt dat Mac bestanden waaraan de datavork ontbreekt als AppleSingle moeten worden verstuurd. In het algemeen echter is AppleSingle vandaag de dag voor de meeste mensen niet echt relevant meer.

uuencode -- Nogmaals, uuencode is een transportcoderingsformaat dat de resource fork van een Macintosh-bestand weggooit en de overblijvende data fork van 8-bits in 7-bits ASCII tekst omzet. Hoewel dit destructieve gedrag nogal betreurenswaardig klinkt, is het in werkelijkheid niet zo vreselijk als ik het heb laten lijken, omdat Windows-applicaties toch niets zouden kunnen aanvangen met de informatie in de resource fork, zelfs al zou die wel worden meegetransporteerd. Als in een Macintosh document de resource fork onmisbaarzou zijn, zou die in een Windows-omgeving toch niet leesbaar zijn. En als je een Macintosh applicatie zou inpakken met uuencode om hem te kunnen versturen via e-mail, zou de applicatie daardoor weliswaar worden vernietigd, maar die zou onder Windows toch niet hebben kunnen draaien; daar hebben we dus ook geen last van.

De voornaamste reden dat uuencode nog steeds bestaat, is een historische - het formaat was zo alomtegenwoordig in de tijd voordat MIME bestond, dat het een soort noodzakelijke optie blijft om op terug te kunnen vallen als je iets naar mensen met een Windows- of andere eigenaardige computer stuurt die al jaren met dezelfde oude versie van een e-mailprogramma werken.

Base64 -- Base64 is in grote lijnen vergelijkbaar met uuencode als transportcoderingsformaat, maar het heeft het voordeel dat het meer van deze tijd is, en bovendien gestandaardiseerd. Net als met uuencode gaat de resource fork van je Macintosh-bestanden verloren als je ze met Base64 te lijf gaat. Onthou dat Base64 automatisch wordt gebruikt als je met AppleDouble codeert, en als je een e-mailprogramma onder Windows bekijkt, betekent "MIME" in de context van het formaat van de attachments waarschijnlijk dat die met Base64 worden gecodeerd.

<http://www.cis.ohio-state.edu/htbin/rfc/rfc2045.html>

Ik heb mijn tests met America OnLine nog niet helemaal af, maar het lijkt erop uit te draaien dat Base64 de beste keuze is als je iets wilt versturen naar AOL-gebruikers. Andere formaten doen het ook, maar niet zo naadloos. Volgende week zijn de definitieve uitslagen er.

BinHex -- Zoals ik hierboven al meldde, is BinHex een combinatie van een binair inpakformaat en transportcoderingsformaat. Het voegt de resource fork en de data fork van een Macintosh-bestand samen en converteert het van 8-bits naar 7-bits ASCII tekst. BinHex blijft populair om bestanden mee te versturen tussen Macintosh gebruikers onderling, omdat eigenlijk alle Macintosh e-mailprogramma's BinHex begrijpen. Daar staat echter tegenover dat BinHex veel slechter werkt als je bestanden naar Windows gebruikers verstuurt, want op het Windows-platform begrijpt vrijwel alleen Eudora het BinHex-formaat. Veel Mac gebruikers vertrouwen nog steeds volledig op BinHex voor het versturen van bestanden als aanhangsel bij e-mailberichten, en als het in jouw geval goed werkt, prima. Maar ik zou je toch aanraden om te overwegen over te stappen naar AppleDouble, en wel hierom:

<http://db.tidbits.com/getbits.acgi?tbart=05050>

Aan de andere kant is er ook iets dat voor BinHex pleit: als enige voegt het een integrale checksum aan het eind van het bestand toe, waardoor een e-mailprogramma makkelijker kan controleren of het attachment al dan niet is beschadigd.

Quoted-Printable -- Hoewel quoted-printable (wat de meeste mensen alleen gezien hebben via de QP knop in Eudora) een formaat is om te encoderen, is het niet gebruikt voor bijgevoegde bestanden, maar voor de hoge ASCII karakters (speciale letters met bijvoorbeeld diacritische tekens). Omdat ze geen deel uitmaken van de 7-bit (ookwel lage) ASCII, worden quoted-printable karakters gecodeerd als een is-gelijkteken gevolgd door een getal. Omdat alle lage ASCII karakters gelijk blijven, is het bericht vrijwel geheel leesbaar voor gewone mensen ondanks de quoted-printable encodering.

Een e-mailbericht met een is-gelijkteken aan het einde van de regels is vrijwel zeker een quoted-printable bericht dat niet gedecodeerd is, meestal omdat de Content-Transfer-Encoding kop van het bericht dat de methode van encoderen specificeert ontbreekt. Dit probleem komt vooral voor in mailing lijsten die berichten samenvoegen, omdat de software de meeste kopregels van berichten afknipt voordat ze ze samenvoegen. De belangrijkste oplossing van dit probleem is het gebruik van MIME samenvoegingen, die de kopregels bevatten voor elk bericht in de samenvoeging, waardoor het mogelijk wordt om in de samengevoegde berichten de speciale encodering van bijzondere tekens te bewaren.

De Rol van Compressie -- Net als je dacht dat je een vinger achter het probleem kreeg, geef ik je nog een variabele: compressie. Het is vaak slim een bestand te comprimeren voordat je het via e-mail verstuurt. Dat geldt in het bijzonder als je grote bestanden stuurt, of veel bestanden in een enkel bericht wilt stoppen, omdat het comprimeren van de bestanden naar een enkel bestand ruimte scheelt en het gemakkelijker kan maken om er mee te werken aan de ontvangende kant. Ik zeg "kan" maken omdat een van de ontwikkelaars van Mulberry, wat voornamelijk een IMAP-e-mailprogramma is, opmerkte dat in de IMAP wereld alles op de server staat totdat de client het wil hebben, dus de mogelijkheid om uit verschillende bijvoegsels er eentje te kiezen om op te halen is een voordeel.

Compressie kan een ander voordeel beiden omdat het het mogelijk maakt de Macintosh bestanden de encoderingsmethode te helpen overleven die normaliter de resource fork van een bestand verwijdert. Bijvoorbeeld, een StuffIt 5 bestand bewaart alles in de data fork, dus uuencode en Base64 beschadigen het niet. Vorige versies van het StuffIt bestandsformaat konden bepaalde dingen in de resource fork bewaren (geloof me op dit punt, de informatie komt rechtstreeks van de ontwikkelaars); alles verplaatsen naar de data fork voor ondersteuning van meerdere platformen is de belangrijkste reden voor Aladdin om het StuffIt 5 formaat te introduceren. Dus, als je een e-mailprogramma hebt dat automatisch bestanden kan comprimeren voordat ze verzonden worden dan werken uuencode en Base64 wellicht veel beter voor je.

Uiteraard geldt dat als je een gecomprimeerd bestand naar een Windows gebruiker mailt, ze wellicht het bijgevoegde bestand kunnen decoderen, maar dan met een gecomprimeerd bestand zitten dat ze niet kunnen decomprimeren. Als je anticipeert dat je een persoon veel gecomprimeerde bestanden gaat sturen, moedig ze dan aan een gratis exemplaar van Aladdin Expander for Windows op te halen, dat een reeks van formaten kan decoderen, ongeveer zoals StuffIt Expander aan de Mac kant. Aan de andere kant, als je slechts af en toe een gecomprimeerd bestand naar een Windows gebruiker stuurt, is het handig te weten dat DropStuff 5.5 en StuffIt Deluxe 5.5 voor Windows zelf-uitpakkende applicaties kan maken (.exe in plaats van .sea) dat de ontvanger kan opstarten om de bestanden uit te pakken.

<http://www.aladdinsys.com/>

Een ander nut van het comprimeren van bestanden is als je Windows of een Unix computer als tussenpersoon gebruikt voor het uitwisselen tussen twee Macs van bestanden met een resource fork. Door het bestand te comprimeren tot alleen een data fork ben je er zeker van zijn dat er geen informatie verloren gaat als het bestand tijdelijk geparkeerd staat voordat het op de uiteindelijke Mac terecht komt (via het netwerk, floppy disk, of andere transportmechanismen). Hierbij aangenomen uiteraard dat StuffIt Expander beschikbaar is op de Mac waar het allemaal naar toe gaat.

En Dan Attachments --In deze hele discussie heb ik het nauwelijks gehad over de bestandssoorten die je met een e-mailbericht kunt meezenden. De ontvanger heeft er niets aan als jij de juiste vorm kiest voor het verzenden van je attachment maar hij kan het meegezonden document zelf niet openen. Er zijn veel factoren die hier meespelen, maar als je de volgende regels in acht neemt ben je op het goede spoor.

Pakje Dicht --Ik hoop dat deze verhandeling de gewoonlijk wat duistere materie heeft verhelderd. De vraag waarmee dit onderwerp werd aangekaart - de beste format voor het verzenden van bestanden aan Windows gebruikers - klinkt redelijk eenvoudig, en in een ideale wereld zouden we er nooit over hoeven na te denken. Dat is dan ook de reden dat ik altijd het gebruik van AppleDouble (met de transparante Base64 codering) adviseer - dit zou moeten werken met alle moderne e-mail-programmatuur die zich houdt aan de Internet standaarden. Het feit dat dit niet altijd lukt wil niet zeggen dat we het anders moeten doen, behalve bij dat sporadische bestand dat we moeten versturen aan een gebruiker van een zeer oud e-mailprogramma. Wel betekent dit dat we met z'n allen eraan moeten werken dat AppleDouble de standaard is die overal wordt ondersteund, dan kan deze hele kwestie worden gearchiveerd bij de andere oude internet verhalen waar die thuishoort. Je hoort nooit te hoeven nadenken over de format van je attachments, en dat bereiken we alleen met volledige naleving van de MIME standaard van AppleDouble en Base64.

Volgende week maak ik dit verhaal af met informatie over welke formats vandaag de dag door de grotere e-mailprogramma's ondersteund worden bij het verzenden van attachments, plus de resultaten van de ontvangen attachments test met AOL.

Niet-winstgevende en niet-commerciële publicaties en Websites mogen artikels overnemen of een HTML link maken als de bron duidelijk en volledig vermeld wordt. Anderen gelieve ons te contacteren. We garanderen de precisie van de artikels niet. Caveat lector. Publicatie-, product- en firmanamen kunnen gedeponeerde merken zijn van hun ondernemingen.

Vorige aflevering | Search TidBITS | TidBITS Homepage | Volgende aflevering