File: uudecode.xml

package info (click to toggle)
virtuoso-opensource 7.2.5.1%2Bdfsg1-0.3
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 285,240 kB
  • sloc: ansic: 641,220; sql: 490,413; xml: 269,570; java: 83,893; javascript: 79,900; cpp: 36,927; sh: 31,653; cs: 25,702; php: 12,690; yacc: 10,227; lex: 7,601; makefile: 7,129; jsp: 4,523; awk: 1,697; perl: 1,013; ruby: 1,003; python: 326
file content (217 lines) | stat: -rw-r--r-- 8,265 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
<?xml version="1.0" encoding="ISO-8859-1"?>
<!--
 -  
 -  This file is part of the OpenLink Software Virtuoso Open-Source (VOS)
 -  project.
 -  
 -  Copyright (C) 1998-2018 OpenLink Software
 -  
 -  This project is free software; you can redistribute it and/or modify it
 -  under the terms of the GNU General Public License as published by the
 -  Free Software Foundation; only version 2 of the License, dated June 1991.
 -  
 -  This program is distributed in the hope that it will be useful, but
 -  WITHOUT ANY WARRANTY; without even the implied warranty of
 -  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 -  General Public License for more details.
 -  
 -  You should have received a copy of the GNU General Public License along
 -  with this program; if not, write to the Free Software Foundation, Inc.,
 -  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
 -  
 -  
-->
<refentry id="fn_uudecode">
  <refmeta>
    <refentrytitle>uudecode</refentrytitle>
    <refmiscinfo>encoding</refmiscinfo>
  </refmeta>
  <refnamediv>
    <refname>uudecode</refname>
    <refpurpose>Decodes a string previously encoded by uuencode</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
    <funcsynopsis id="fsyn_uudecode">
      <funcprototype id="fproto_uudecode">
        <funcdef><function>uudecode</function></funcdef>
	<paramdef>in <parameter>input</parameter> string</paramdef>
	<paramdef>in <parameter>mode</parameter> integer</paramdef>
      </funcprototype>
    </funcsynopsis>
  </refsynopsisdiv>
  <refsect1 id="desc_uudecode"><title>Description</title>
    <para>
Uudecode transforms uuencoded data into original form.
Uuencode may return a number of sections as a vector of them,
each of these sections should be decoded by separate call and results
should be concatenated in order to compose original text.
The mode of decoding should match to the mode used for encoding, of course.
    </para>
    <para>
RFC 2045,
(N. Borenstein, N. Freed.
MIME (Multipurpose Internet Mail Extensions) Part One:
The Format of Internet Message Bodies),
contains detailed description of most important encodings used by mail
systems.
Older RFC 1521 is now obsoleted.
    </para>
    <para>
Currently, eight conventions are used for mail attachments.
In Virtuoso, they are enumerated by integer IDs.
    </para>
    <table><title>Unicode-like standards, supported by Virtuoso</title>
      <tgroup cols="3">
       <thead><row><entry>ID</entry><entry>Standard</entry><entry>Description</entry></row></thead>
	<tbody>
	  <row>
	    <entry>1</entry><entry>"Native" UUencode</entry>
	    <entry>
Optional header is one line started by "begin " or "&lt;pre&gt;begin " keyword, with some system-specific data after it.
Optional footer is one line started by "end" keyword.
	    </entry>
	  </row>
	  <row>
	    <entry>2</entry><entry>Base-64, UNIX version</entry>
	    <entry>
There are no agreements about headers or footers.
	    </entry>
	  </row>
	  <row>
	    <entry>3</entry><entry>Base-64, MIME version</entry>
	    <entry>
This standard is very similar to "Base-64, UNIX version".
Virtuoso, like all modern mail clients,
feel no difference between them when decode sections, because
the only difference is in the number of data bytes per line.
	    </entry>
	  </row>
	  <row>
	    <entry>4</entry><entry>XXencode</entry>
	    <entry>
This standard is an obsolete standard, similar to Unicode,
but not compatible.
There are no agreements about headers or footers.
	    </entry>
	  </row>
	  <row>
	    <entry>5</entry><entry>BinHex</entry>
	    <entry>
There are no header or footer lines, but first line of every
section should be prefixed by colon (':') character.
	    </entry>
	  </row>
	  <row>
	    <entry>6-9</entry><entry>reserved</entry>
	    <entry>
More standards may be used in the future. It is unsafe to
assume that all existing standards are listed here.
Real application will often receive messages with unknown or
misspelled encodings' names, syntax errors in data etc.
	    </entry>
	  </row>
	  <row>
	    <entry>10</entry><entry>MIME Plain-Text</entry>
	    <entry>
This "encoding" is suitable only for texts.
They are stored "as is", but line ends will not be preserved.
	    </entry>
	  </row>
	  <row>
	    <entry>11</entry><entry>MIME Quoted-Printable (for texts)</entry>
	    <entry>
This encoding is suitable for any sort of textual data,
because ASCII printable characters are stored
"as is" and only nonprintable characters are encoded.
UNIX linefeeds (LF chars) will be encoded as "hard breaks", so decoding
side may convert them into its own system-specific "line end" chars, e.g.
in CRLF sequence.
	    </entry>
	  </row>
	  <row>
	    <entry>12</entry><entry>MIME Quoted-Printable (for binaries)</entry>
	    <entry>
This encoding is suitable for any sort of data but it is especially
useful for textual data, because ASCII printable characters are stored
"as is" and only nonprintable characters are encoded.
No "hard breaks" will be used for UNIX linefeeds (LF chars) of source file,
so the file will be decoded exactly as it was encoded, no matter which
character sequence is used for "line end" in the decoder's OS.
When in trouble, whether the data encoded are text or binary, use
this variant ("for binaries"): text may be easily recovered by recipient
if linefeeds are wrong whereas binary data will become unusable if encoded as text.
	    </entry>
	  </row>
	</tbody>
      </tgroup>
    </table>
    <para>
If there's no information about the encoding used in the message,
zero may be passed to the uudecode() function instead of proper ID.
uudecode() will try to guess the proper algorithm.
In any case, decoder feels no difference between modes 2 and 3
(two slightly different "Base64" encodings) and between modes
11 and 12 (two "Quoted-Printable" methods which are different
only encoding side).
Application may try all methods in turn if automatic guess will fail.
    </para>
  </refsect1>
  <refsect1 id="params_uudecode"><title>Parameters</title>
    <refsect2><title>input</title>
      <para>String or string-output session with data to be encoded.</para></refsect2>
    <refsect2><title>mode</title>
      <para>Integer ID of encoding to be used.</para></refsect2>
  </refsect1>
  <refsect1 id="ret_uudecode"><title>Return Types</title><para>
Vector of strings, where every string contains all data lines of a section.
</para></refsect1>
  <refsect1 id="errors_uuencode"><title>Errors</title>
    <table><title>Errors signalled by</title>
      <tgroup cols="4">
       <thead><row><entry>SQLState</entry><entry>Error Code</entry><entry>Error Text</entry><entry>Description</entry></row></thead>
	<tbody>
	  <row>
	    <entry><errorcode>22003</errorcode></entry>
	    <entry><errorcode>UUD01</errorcode></entry>
	    <entry><errorname>Unsupported type of UU-encoding (...)</errorname></entry>
	    <entry></entry>
	  </row>
	  <row>
	    <entry><errorcode>22003</errorcode></entry>
	    <entry><errorcode>UUD02</errorcode></entry>
	    <entry><errorname>Data string contains errors [...]</errorname></entry>
	    <entry></entry>
	  </row>
	  <row>
	    <entry><errorcode>22003</errorcode></entry>
	    <entry><errorcode>UUD03</errorcode></entry>
	    <entry><errorname>Encoded data ended prematurely</errorname></entry>
	    <entry></entry>
	  </row>
	  <row>
	    <entry><errorcode>22003</errorcode></entry>
	    <entry><errorcode>UUD04</errorcode></entry>
	    <entry><errorname>No data found to be decoded</errorname></entry>
	    <entry></entry>
	  </row>
	</tbody>
      </tgroup>
    </table>
  </refsect1>
  <refsect1 id="examples_uudecode"><title>Examples</title>
    <example id="ex_uudecode"><title>Encoding with auto-detection of the encoding type</title>
      <para>The function gets a string &apos;Hello&apos; in BinHex encoding and zero to let it guess that the encoding is BinHex. The call returns 'Hello'.</para>
      <screen>
-- note doubled single quotes inside string literal
select uudecode (':5''9XE''m:', 0);
Hello
</screen>
    </example>
  </refsect1>
  <refsect1 id="seealso_uudecode"><title>See Also</title>
    <para>
      <link linkend="fn_uuvalidate">uuencode</link>,
      <link linkend="fn_uuvalidate">uuvalidate</link>
    </para>
  </refsect1>
</refentry>