yEnc är ett populärt binärt-till-text-kodningsschema som främst används av Usenet -användare . Används även när du skickar stora binära filer via e-post. Jämfört med andra scheman för att koda binär data till text, är det mer effektivt på grund av det faktum att det inte bara använder tecken från 7-bitars ASCII -tabellen utan också delar av tecknen från den utökade ASCII-tabellen . På grund av detta överstiger storleken på filer kodade med yEnc storleken på de ursprungliga med endast 1-2 % [1] . Detta är en betydande förbättring jämfört med 33%-40% extra utrymme för sex-bitars kodningsmetoder som uuencode och Base64 . Den första versionen av yEnc släpptes av Jürgen Helbing i början av 2001. År 2003 hade yEnc blivit utbredd och blev de facto standarden för kodning av binära filer på Usenet . [2] Namnet yEncode är en ordlek på "Varför koda?" ("Varför koda?"), ett skämt som uppstod på grund av att huvudidén med yEnc var att endast de tecken i en binär fil behöver kodas för vilka den ovillkorligen krävdes att placeras i brödtexten i enlighet med RFC :s tekniska standarder . [3]
En annan fördel med yEnc framför uuencode , Base64 och andra tidigare tekniker är CRC-koden , som låter dig kontrollera att källfilen är korrekt sammansatt och återställd från enskilda fragment som skickats med post.
Enligt RFC 822 och RFC 2822 får Usenet -e- postmeddelanden endast innehålla tecken från 7-bitars ASCII -kodtabellen . Men i praktiken har denna begränsning inte observerats på länge, och den stora majoriteten av modern programvara sänder regelbundet 8-bitars tecken i bokstäverna. Ur yEnc synvinkel, av 256 möjliga binära tecken, kan 252 sändas inuti bokstaven som en enda byte, oavsett om detta tecken visas på datorskärmen eller inte. Tecknen NUL, LF, CR och = (lika tecken) är kodade på ett speciellt sätt. För LF och CR är anledningen till undantaget att dessa tecken inuti bokstaven, ur RFC:s synvinkel, har en speciell betydelse. NUL - på grund av komplexiteten i att bearbeta strängar som innehåller detta tecken i dem i vissa programmeringsspråk och av skäl för att optimera yEnc-bearbetningsalgoritmer. Symbolen = används som escape-tecken .
Ett antal kritiker har pekat på svagheter i yEnc. [4] [5] [6] [7]
De påpekade särskilt att yEnc lider av samma brister i den vanligare uuencoden som löstes för länge sedan i MIME -poststandarden . Till exempel kräver yEnc att strängarna "=ybegin" och "=yend" placeras i e-postmeddelandets brödtext, vilket begränsar den binära biten som skickas i det e-postmeddelandet. [3]
Som ett resultat av detta är en falsk positiv av filsamlaren möjlig, som kommer att analysera brevets text och hitta en liknande rad där, som nämndes under diskussionen om yEnc själv i korrespondensen. Detta är ett mindre fel, allvarligare är att yEnc kodar filnumren i ämnesraden i e-postmeddelandet, vilket är ett opålitligt sätt att förmedla information och kan förvanskas. Som ett resultat kommer sammansättningen av den binära filen att misslyckas.
Kritiken gällde också avsaknaden av en formell standard som beskriver yEnc.
Bland förslagen för att förfina yEnc fanns också idén om att integrera yEnc i MIME , vilket uppenbarligen skulle rädda yEnc från de flesta av de brister som tillskrivs denna kodningsteknik. Men kritiker av yEnc vidtog inga praktiska åtgärder för att implementera sina idéer, så yEnc fortsätter att användas nu i den form som det definierades av teknikens författare.
yEnc har aldrig föreslagits som en teknisk standard av IETF . yEnc-hemsidan innehåller en informell teknikspecifikation , samt ett antal ytterligare tekniska anmärkningar.
yEnc stöds direkt av Usenet Forte Agent -nyhetsläsaren . Det finns också ett antal tredjepartsverktyg som låter dig använda yEnc tillsammans med andra e-post- och nyhetsläsare.
Det finns plugin-program från tredje part för Outlook Express , Windows Mail och Windows Live Mail som aktiverar den här tekniken. Mozilla Thunderbird stöder yEnc i begränsad utsträckning. Denna e-postklient kan inte avkoda filer uppdelade i flera e-postmeddelanden. [åtta]