Time Limit: Java: 2000 ms / Others: 2000 ms
Memory Limit: Java: 65536 KB / Others: 65536 KB
One day, Nobita found that his computer is extremely slow. After several hours' work, he finally found that it was a virus that made his poor computer slow and the virus was activated by a misoperation of opening an attachment of an email.
Nobita did use an outstanding anti-virus software, however, for some strange reason, this software did not check email attachments. Now Nobita decide to detect viruses in emails by himself.
To detect an virus, a virus sample (several binary bytes) is needed. If these binary bytes can be found in the email attachment (binary data), then the attachment contains the virus.
Note that attachments (binary data) in emails are usually encoded in base64. To encode a binary stream in base64, first write the binary stream into bits. Then take 6 bits from the stream in turn, encode these 6 bits into a base64 character according the following table:
That is, translate every 3 bytes into 4 base64 characters. If the original binary stream contains 3k + 1 bytes, where k is an integer, fill last bits using zero when encoding and append '==' as padding. If the original binary stream contains 3k + 2 bytes, fill last bits using zero when encoding and append '=' as padding. No padding is needed when the original binary stream contains 3k bytes.
For example, to encode 'hello' into base64, first write 'hello' as binary bits, that is: 01101000 01100101 01101100 01101100 01101111
Then, take 6 bits in turn and fill last bits as zero as padding (zero padding bits are marked in bold): 011010 000110 010101 101100 011011 000110 111100
They are 26 6 21 44 27 6 60in decimal. Look up the table above and use corresponding characters: aGVsbG8
Since original binary data contains 1 * 3 + 2 bytes, padding is needed, append '=' and 'hello' is finally encoded in base64:aGVsbG8=
Section 5.2 of RFC 1521 describes how to encode a binary stream in base64 much more detailedly:The Base64 Content-Transfer-Encoding is designed to representarbitrary sequences of octets in a form that need not be humanlyreadable. The encoding and decoding algorithms are simple, but theencoded data are consistently only about 33 percent larger than theunencoded data. This encoding is virtually identical to the one usedin Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421.The base64 encoding is adapted from RFC 1421, with one change: base64eliminates the "*" mechanism for embedded clear text.A 65-character subset of US-ASCII is used, enabling 6 bits to berepresented per printable character. (The extra 65th character, "=",is used to signify a special processing function.) NOTE: This subset has the important property that it is represented identically in all versions of ISO 646, including US ASCII, and all characters in the subset are also represented identically in all versions of EBCDIC. Other popular encodings, such as the encoding used by the uuencode utility and the base85 encoding specified as part of Level 2 PostScript, do not share these properties, and thus do not fulfill the portability requirements a binary transport encoding for mail must meet.The encoding process represents 24-bit groups of input bits as outputstrings of 4 encoded characters. Proceeding from left to right, a24-bit input group is formed by concatenating 3 8-bit input groups.These 24 bits are then treated as 4 concatenated 6-bit groups, eachof which is translated into a single digit in the base64 alphabet.When encoding a bit stream via the base64 encoding, the bit streammust be presumed to be ordered with the most-significant-bit first.That is, the first bit in the stream will be the high-order bit inthe first byte, and the eighth bit will be the low-order bit in thefirst byte, and so on.Each 6-bit group is used as an index into an array of 64 printablecharacters. The character referenced by the index is placed in theoutput string. These characters, identified in Table 1, below, areselected so as to be universally representable, and the set excludescharacters with particular significance to SMTP (e.g., ".", CR, LF)and to the encapsulation boundaries defined in this document (e.g.,"-").Table 1: The Base64 Alphabet Value Encoding Value Encoding Value Encoding Value Encoding 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 810 K 27 b 44 s 61 911 L 28 c 45 t 62 +12 M 29 d 46 u 63 /13 N 30 e 47 v14 O 31 f 48 w (pad) =15 P 32 g 49 x16 Q 33 h 50 yThe output stream (encoded bytes) must be represented in lines of nomore than 76 characters each. All line breaks or other charactersnot found in Table 1 must be ignored by decoding software. In base64data, characters other than those in Table 1, line breaks, and otherwhite space probably indicate a transmission error, about which awarning message or even a message rejection might be appropriateunder some circumstances.Special processing is performed if fewer than 24 bits are availableat the end of the data being encoded. A full encoding quantum isalways completed at the end of a body. When fewer than 24 input bitsare available in an input group, zero bits are added (on the right)to form an integral number of 6-bit groups. Padding at the end ofthe data is performed using the '=' character. Since all base64input is an integral number of octets, only the following cases canarise: (1) the final quantum of encoding input is an integralmultiple of 24 bits; here, the final unit of encoded output will bean integral multiple of 4 characters with no "=" padding, (2) thefinal quantum of encoding input is exactly 8 bits; here, the finalunit of encoded output will be two characters followed by two "="padding characters, or (3) the final quantum of encoding input isexactly 16 bits; here, the final unit of encoded output will be threecharacters followed by one "=" padding character.Because it is used only for padding at the end of the data, theoccurrence of any '=' characters may be taken as evidence that theend of the data has been reached (without truncation in transit). Nosuch assurance is possible, however, when the number of octetstransmitted was a multiple of three.Any characters outside of the base64 alphabet are to be ignored inbase64-encoded data. The same applies to any illegal sequence ofcharacters in the base64 encoding, such as "====="Care must be taken to use the proper octets for line breaks if base64encoding is applied directly to text material that has not beenconverted to canonical form. In particular, text line breaks must beconverted into CRLF sequences prior to base64 encoding. The importantthing to note is that this may be done directly by the encoder ratherthan in a prior canonicalization step in some implementations. NOTE: There is no need to worry about quoting apparent encapsulation boundaries within base64-encoded parts of multipart entities because no hyphen characters are used in the base64 encoding.
Here is a piece of ANSI C code that can encode binary data in base64. It contains a function, encode (infile, outfile), to encode binary file infile in base64 and output result to outfile.#include <stdio.h>
Input contains multiple cases (about 15, of which most are small ones). The first line of each case contains an integer N (0 <= N <= 512). In the next N distinct lines, each line contains a sample of a kind of virus, which is not empty, has not more than 64 bytes in binary and is encoded in base64. Then, the next line contains an integer M (1 <= M <= 128). In the following M lines, each line contains the content of a file to be detected, which is not empty, has no more than 2048 bytes in binary and is encoded in base64.
There is a blank line after each case.
For each case, output M lines. The ith line contains the number of kinds of virus detected in the ith file.
Output a blank line after each case.
In the first sample case, there are three virus samples: base64, virus and t: , the data to be checked is test: virus., which contains the second and the third, two virus samples.