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
|
<?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_uuvalidate">
<refmeta>
<refentrytitle>uuvalidate</refentrytitle>
<refmiscinfo>mail</refmiscinfo>
</refmeta>
<refnamediv>
<refname>uuvalidate</refname>
<refpurpose>Encodes string or string session into sequence of printable characters, suitable for transfer via "ASCII-only" data channels</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis id="fsyn_uuvalidate">
<funcprototype id="fproto_uuvalidate">
<funcdef><function>uuvalidate</function></funcdef>
<paramdef>in <parameter>input</parameter> string or string session</paramdef>
<paramdef>in <parameter>mode</parameter> integer</paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1 id="desc_uuvalidate"><title>Description</title>
<para>
This function tries to ensure what applied data have a pointed encoding mode.
If mode parameter is 0 (ie unknown) or if the validation fails,
it will try to determine which mode was used in fact.
</para>
<para>
RFC 1521,
(N. Borenstein, N. Freed.
MIME (Multipurpose Internet Mail Extensions) Part One:
Mechanisms for Specifying and Describing
the Format of Internet Message Bodies),
contains detailed description of most important encodings used by mail
systems.
RFC 2045,
(N. Borenstein, N. Freed.
MIME (Multipurpose Internet Mail Extensions) Part One:
The Format of Internet Message Bodies).
</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 "<pre>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.
Application should place colon before data lines of every section.
(this function will prepare only data lines without this prefix).
</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>
</refsect1>
<refsect1 id="params_uuvalidate"><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_uuvalidate"><title>Return Types</title><para>
Vector of strings, where every string contains all data lines of a section.
</para></refsect1>
<refsect1 id="errors_uuvalidate"><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>UUV01</errorcode></entry>
<entry><errorname>Unsupported type of UU-encoding (..)</errorname></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1 id="examples_uuvalidate"><title>Examples</title>
<example id="ex_uuvalidate"><title>Detection of encoding type</title>
<para>The function gets a string 'Hello' in BinHex encoding and returns 5 indicating that the string is probably in BinHex encoding.</para>
<screen>
-- note doubled single quotes inside string literal
select uuvalidate (':5''9XE''m:', 0);
5
</screen>
</example>
</refsect1>
<refsect1 id="seealso_uuvalidate"><title>See Also</title>
<para>
<link linkend="fn_uudecode">uuencode</link>,
<link linkend="fn_uudecode">uudecode</link>
</para>
</refsect1>
</refentry>
|
