uudecode(1p)

PROLOG

Denna manualsida är en del av POSIX Programmer's Manual. Linux-implementationen av detta gränssnitt kan skilja sig från denna beskrivning. Se motsvarande Linux-manualsida för detaljer om Linux-beteende, eller notera att gränssnittet kanske inte är implementerat på Linux.

NAMN

uuencode — koda en binär fil

SYNOPSIS

uuencode [-m] [fil] avkodnings_sökväg

BESKRIVNING

Verktyget uuencode skriver en kodad version av den angivna indatafilen, eller standard in om ingen fil anges, till standard ut. Utdata ska kodas med en av algoritmerna som beskrivs i avsnittet STANDARD UTMATNING och ska innehålla filens åtkomstbehörighetsbitar (i oktal eller symbolisk notation enligt chmod) för indatafilen samt avkodnings_sökväg, för att filen ska kunna återskapas på ett annat system som överensstämmer med denna del av POSIX.1-2017.

ALTERNATIV

Verktyget uuencode ska följa Base Definitions-volymen i POSIX.1-2017, avsnitt 12.2, Utility Syntax Guidelines.

Följande alternativ ska stödjas av implementationen:

-m

Koda utdata med MIME Base64-algoritmen som beskrivs i STANDARD UTMATNING. Om -m inte anges ska den historiska algoritmen som beskrivs i STANDARD UTMATNING användas.

OPERANDER

Följande operander ska stödjas:

avkodnings_sökväg

Sökvägen till filen där verktyget uudecode ska placera den avkodade filen. Om operanden avkodnings_sökväg anges som /dev/stdout betyder det att uudecode ska använda standard ut. Om det finns tecken i avkodnings_sökväg som inte ingår i den portabla teckenuppsättningen för filnamn är resultatet ospecificerat.

fil

Sökvägen till filen som ska kodas.

STANDARD IN

Se avsnittet INDATAFILER.

INDATAFILER

Indatafiler kan vara filer av vilken typ som helst.

MILJÖVARIABLER

Följande miljövariabler påverkar körningen av uuencode:

LANG

Ger ett standardvärde för internationaliseringsvariabler som är osatta eller tomma. Se Base Definitions-volymen i POSIX.1-2017, avsnitt 8.2, Internationalization Variables, för prioritetsordningen mellan internationaliseringsvariabler.

LC_ALL

Om satt till en icke-tom sträng åsidosätter den värdena för alla andra internationaliseringsvariabler.

LC_CTYPE

Bestämmer lokal för tolkning av byteföljder i textdata som tecken, till exempel enbytes- kontra flerbytetecken i argument och indatafiler.

LC_MESSAGES

Bestämmer den lokal som ska användas för format och innehåll i diagnostiska meddelanden som skrivs till standard fel.

NLSPATH

Bestämmer platsen för meddelandekataloger vid behandling av LC_MESSAGES.

ASYNKRONA HÄNDELSER

Standard.

STANDARD UTMATNING

uuencode Base64-algoritm

Standardutmatningen ska vara en textfil, kodad i teckenuppsättningen för aktuell lokal, som börjar med raden:

begin-base64 %s %s\n

där värdena motsvarar <läge> och <avkodnings_sökväg>.

Den ska sluta med raden:

====\n

I båda fallen ska raderna inte ha inledande eller avslutande blanktecken.

Kodningsprocessen representerar 24-bitars grupper av indatabitar som utsträngar med fyra kodade tecken. Från vänster till höger bildas en 24-bitars indatagrupp genom att tre 8-bitars indatagrupper sammanfogas. Varje 24-bitars grupp ska därefter behandlas som fyra sammanfogade 6-bitars grupper, där varje grupp översätts till ett enda tecken i Base64-alfabetet.

Vid kodning av en bitström med Base64 ska bitströmmen antas vara ordnad med mest signifikanta bit först. Det betyder att den första biten i strömmen ska vara den mest signifikanta biten i den första byten, den åttonde biten ska vara den minst signifikanta biten i den första byten, och så vidare.

Varje 6-bitars grupp används som index i en matris med 64 utskrivbara tecken, enligt följande tabell:

Värde	Kodning	Värde	Kodning	Värde	Kodning	Värde	Kodning
0	A	17	R	34	i	51	z
1	B	18	S	35	j	52	0
2	C	19	T	36	k	53	1
3	D	20	U	37	l	54	2
4	E	21	V	38	m	55	3
5	F	22	W	39	n	56	4
6	G	23	X	40	o	57	5
7	H	24	Y	41	p	58	6
8	I	25	Z	42	q	59	7
9	J	26	a	43	r	60	8
10	K	27	b	44	s	61	9
11	L	28	c	45	t	62	+
12	M	29	d	46	u	63	/
13	N	30	e	47	v
14	O	31	f	48	w	pad	=
15	P	32	g	49	x
16	Q	33	h	50	y

Tecknet som motsvarar indexet ska placeras i utsträngen.

Utströmmen, alltså de kodade bytena, ska representeras i rader om högst 76 tecken vardera. Alla radbrytningar eller andra tecken som inte finns i tabellen ska ignoreras av avkodande programvara, se uudecode(1p).

Särskild behandling ska användas om färre än 24 bitar finns tillgängliga vid slutet av ett meddelande eller en inkapslad del av ett meddelande. En fullständig kodningskvant ska alltid avslutas vid slutet av ett meddelande. När färre än 24 indatabitar finns tillgängliga i en indatagrupp ska nollbitar läggas till på höger sida för att bilda ett helt antal 6-bitarsgrupper. Utteckenspositioner som inte krävs för att representera faktisk indata ska sättas till tecknet =.

Eftersom all Base64-indata består av ett helt antal oktetter kan endast följande fall uppstå:

1. Den sista kodningsgruppen är ett helt multipel av 24 bitar. Då ska den sista kodade enheten vara ett helt multipel av 4 tecken utan utfyllnad med =.
2. Den sista kodningsgruppen är exakt 16 bitar. Då ska den sista kodade enheten vara tre tecken följt av ett utfyllnadstecken =.
3. Den sista kodningsgruppen är exakt 8 bitar. Då ska den sista kodade enheten vara två tecken följt av två utfyllnadstecken =.

En avslutande sträng ==== motsvarar inget data och markerar slutet på den kodade datan.

uuencode historisk algoritm

Standardutmatningen ska vara en textfil, kodad i teckenuppsättningen för aktuell lokal, som börjar med raden:

begin %s %s\n

där värdena motsvarar <läge> och <avkodnings_sökväg>.

Den ska sluta med raden:

end\n

I båda fallen ska raderna inte ha inledande eller avslutande blanktecken.

Algoritmen som ska användas för raderna mellan begin och end tar tre oktetter som indata och skriver fyra tecken som utdata genom att dela upp indata vid 6-bitarsintervall i fyra oktetter, där endast de lägre sex bitarna innehåller data. Dessa oktetter ska omvandlas till tecken genom att värdet 0x20 adderas till varje oktett, så att varje oktett hamnar i intervallet [0x20,0x5f], och därefter ska det antas att den representerar ett utskrivbart tecken i teckenuppsättningen ISO/IEC 646:1991. Den ska sedan översättas till motsvarande teckenkoder i koduppsättningen som används i aktuell lokal.

Där bitar från två oktetter kombineras ska de minst signifikanta bitarna i den första oktetten skiftas åt vänster och kombineras med de mest signifikanta bitarna i den andra oktetten skiftade åt höger. De tre oktetterna A, B och C ska därför omvandlas till de fyra oktetterna:

0x20 + (( A >> 2                    ) & 0x3F)
0x20 + (((A << 4) | ((B >> 4) & 0xF)) & 0x3F)
0x20 + (((B << 2) | ((C >> 6) & 0x3)) & 0x3F)
0x20 + (( C                         ) & 0x3F)

Dessa oktetter ska sedan översättas till den lokala teckenuppsättningen.

Varje kodad rad innehåller ett längdtecken, lika med antalet tecken som ska avkodas plus 0x20, översatt till den lokala teckenuppsättningen enligt beskrivningen ovan, följt av de kodade tecknen. Det maximala antalet oktetter som får kodas på varje rad ska vara 45.

STANDARD FEL

Standard fel ska endast användas för diagnostiska meddelanden.

UTDATAFILER

Inga.

UTVIDGAD BESKRIVNING

Ingen.

AVSLUTNINGSSTATUS

Följande avslutningsvärden ska returneras:

• 0 — lyckad körning
• >0 — ett fel inträffade

KONSEKVENSER AV FEL

Standard.

Följande avsnitt är informativa.

ANVÄNDNING

Filen expanderas med 35 procent, eftersom varje tre oktetter blir fyra, plus styrinformation, vilket gör att överföringen tar längre tid.

Eftersom detta verktyg är avsett att skapa filer för datautbyte mellan system med eventuellt olika teckenuppsättningar, och att representera binär data som en textfil, valdes standarden ISO/IEC 646:1991 som en känd referenspunkt mitt i algoritmen. Utdata från uuencode är en textfil på det lokala systemet. Om utdata vore i teckenuppsättningen ISO/IEC 646:1991 kanske den inte längre skulle vara en textfil, bland annat eftersom radbrytningstecknen kanske inte skulle stämma, och målet att skapa en textfil skulle då gå förlorat.

Om denna textfil sedan flyttas till en annan maskin med samma teckenuppsättning är den helt kompatibel med den maskinens uudecode. Om den skickas via e-post eller överförs till en maskin med en annan teckenuppsättning antas att någon översättningsmekanism, precis som för andra textfiler, omvandlar den till en lämplig teckenuppsättning när den når användaren på det andra systemet. Denna översättning är bara meningsfull från den lokala teckenuppsättningen, inte om filen först har gjorts om till en ren ISO/IEC 646:1991-representation. På samma sätt kan filer behandlade med uuencode placeras i pax-arkiv blandat med andra textfiler i samma teckenuppsättning.

EXEMPEL

Inga.

MOTIVERING

En ny algoritm lades till på begäran av det internationella samfundet för att motsvara arbetet i RFC 2045 (MIME). Liksom det historiska formatet för uuencode är Base64-kodningen för innehållsöverföring avsedd att representera godtyckliga oktettsekvenser i en form som inte är direkt läsbar för människor. En delmängd på 65 tecken från ISO/IEC 646:1991 används, vilket gör det möjligt att representera 6 bitar per utskrivbart tecken. Det extra 65:e tecknet, =, används för att markera en särskild bearbetningsfunktion.

Denna delmängd har den viktiga egenskapen att den representeras identiskt i alla versioner av ISO/IEC 646:1991, inklusive US ASCII, och att alla tecken i delmängden också representeras identiskt i alla versioner av EBCDIC. Den historiska uuencode-algoritmen har inte denna egenskap, vilket är anledningen till att en andra algoritm lades till i ISO POSIX-2-standarden.

Strängen ==== användes som avslutning i stället för end från originalformatet, eftersom den senare är en sträng som skulle kunna vara giltig kodad indata.

I ett tidigt utkast hette alternativet -m i stället -b för Base64, men det döptes om för att bättre återspegla dess relation till RFC 2045. Ett alternativ -u fanns också för att uttryckligen aktivera standardalgoritmen, men eftersom detta inte var historisk praxis utelämnades det som onödigt.

Se avsnittet MOTIVERING i uudecode(1p) för härledningen av symbolen /dev/stdout.

FRAMTIDA UTVECKLING

Ingen.

SE ÄVEN

• chmod(1p)
• mailx(1p)
• uuencode(1p)

Base Definitions-volymen av POSIX.1-2017, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines

UPPHOVSRÄTT

Delar av denna text är återgivna och reproducerade i elektronisk form från IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, copyright (C) 2018 av Institute of Electrical and Electronics Engineers, Inc och The Open Group.

Om det finns någon avvikelse mellan denna version och den ursprungliga standarden från IEEE och The Open Group, är originalstandarden det styrande dokumentet.

Eventuella typografiska eller formateringsfel i denna sida har sannolikt uppstått vid konverteringen av källfilerna till manualsideformat.

Sidslut

Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/uudecode.1p.html Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till PC Service som har sponsrat Linux.se med webbhotell.