RFC1951的部分翻譯及原文(2/2) (轉)
3. Detailed specification
3.1. Overall conventions In the diagrams below, a box like this:
下面的圖形表示一個位元組：
+---+
| | +---+
下面的圖形表示若干位元組：
represents one byte; a box like this:
+==============+
| |
+==============+
represents a variable number of bytes.
中所存貯的位元組並不存在“位順序”，因為位元組本身被看作是一個單元。
但是，當一個位元組被看作是一個0到255之間的整數時，就會有一些最重要的或是最不重
要的位。通常我們會將一個位元組中最重要的位寫在左邊，將幾個位元組中，最重要的位元組
寫在左邊。在圖表中，我們將一個位元組中的各位標上序號：位0表示最不重要的位等等：
Bytes stored within a computer do not have a "bit order", since
they are always treated as a unit. However, a byte consred as
an integer between 0 and 255 does have a most- and least-
significant bit, and since we write numbers with the most-
significant digit on the left, we also write bytes with the most-
significant bit on the left. In the diagrams below, we number the
bits of a byte so that bit 0 is the least-significant bit, i.e.,
the bits are numbered:
+--------+
|76543210|
+--------+
在計算機中，一個數可能佔用幾個位元組。這裡所說的多位元組資料都是將不重要的
部分存貯在低地址的位元組中，如520被儲存為：
Within a computer, a number may occupy multiple bytes. All
multi-byte numbers in the format described here are stored with
the least-significant byte first (at the lower memory address).
For example, the decimal number 520 is stored as:
0 1
+--------+--------+
|00001000|00000010|
+--------+--------+
^ ^
| |
| + more significant byte = 2 x 256
+ less significant byte = 8
3.1.1. Packing into bytes
這篇文件中沒有指明在位連續的傳輸媒介中，位元組中的位順序。因為這
裡所描述的最終資料格式是位元組，而不是位。但是，我們設計了下面的塊格式，其中
的資料元素是不定長的位序列，而不是位元組。因此我們必須指明如何將這些位組合成位元組
序列。
This document does not address the issue of the order in which
bits of a byte are transmitted on a bit-sequential medium,
since the final data format described here is byte- rather than
bit-oriented. However, we describe the compressed block format
in below, as a sequence of data elements of various bit
lengths, not a sequence of bytes. We must therefore specify
how to pack these data elements into bytes to fothe final
compressed byte sequence:
資料元素(位)被打包到位元組中時，是以逐漸增加的位序號排列的。
如：以最不重要的位開始。
資料元素(除了Huffman編碼外)以最不重要的位開始。
Huffman 編碼以最重要的位開始。
* Data elements are packed into bytes in order of
increasing bit number within the byte, i.e., starting
with the least-significant bit of the byte.
* Data elements other than Huffman codes are packed
starting with the least-significant bit of the data
element.
* Huffman codes are packed starting with the most-
significant bit of the code.
換句話說，如果想要以位元組序列的方式列印壓縮資料，從最右邊的空白
開始向最左邊進行。將每位元組中最重要的位放在左邊。
In other s, if one were to print out the compressed data as
a sequence of bytes, starting with the first byte at the
*right* margin and proceeding to the *left*, with the most-
significant bit of each byte on the left as usual, one would be
able to parse the result from right to left, with fixed-width
elements in the correct MSB-to-LSB order and Huffman codes in
bit-reversed order (i.e., with the first bit of the code in the
relative LSB position).
3.2. Compressed block format 壓縮的塊結構
3.2.1. Synopsis of prefix and Huffman coding
字首編碼方式描述了一種可以從位序列預知的字母表。每個符號有一個
編碼，其特點是不同的符號有不同的長度的位序列。但是解析器可以明白的解析出編碼的
內容。
Prefix coding represents symbols from an apriori known
alphabet by bit sequences (codes), one code for each symbol, in
a manner such that different symbols may be represented by bit
sequences of different lengths, but a parser can always parse
an encoded string unambiguously symbol-by-symbol.
我們根據一個二進位制樹來進行字首編碼。兩邊的非葉子結點依次的標上
0,1，而葉子結點則一個一人的標記上字母表中的字元。這樣，每個字元的編碼就是一個
從根結點到葉子結點的0,1的序列了，如：
We define a prefix code in terms of a binary tree in which the
two edges descending from each non-leaf node are labeled 0 and
1 and in which the leaf nodes correspond one-for-one with (are
labeled with) the symbols of the alphabet; then the code for a
symbol is the sequence of 0's and 1's on the edges leading from
the to the leaf labeled with that symbol. For example:
/ Symbol Code
0 1 ------ ----
/ A 00
/ B B 1
0 1 C 011
/ D 010
A /
0 1
/
D C
解碼器可以解碼輸入的內容：讓輸入的流從這個樹的根結點走到葉子
結點，每次的前進都選擇與流中下一位相同的一邊。
A parser can decode the next symbol from an encoded input
stream by walking down the tree from the root, at each step
choosing the edge corresponding to the next input bit.
給出一個已知使用頻率的字母表，Huffman規則允許解釋成一個最佳的
字首編碼，這樣的編碼被稱作Huffman 編碼。
Given an alphabet with known symbol frequencies, the Huffman
algorithm allows the construction of an optimal prefix code
(one which represents strings with those symbol frequencies
using the fewest bits of any possible prefix codes for that
alphabet). Such a code is called a Huffman code. (See
reference [1] in Chapter 5, references for additional
information on Huffman codes.)
注意，在"deflate"格式中，Huffman 編碼對於不同的字母表來說
不可以超過最大的編碼長度。這個規定使得透過使用頻率來計算編碼長度的演算法變得複雜
了。詳細內容見第五節。
Note that in the "deflate" format, the Huffman codes for the
various alphabets must not exceed certain maximum code lengths.
This constraint complicates the algorithm for computing code
lengths from symbol frequencies. Again, see Chapter 5,
references for details.
3.2.2. Use of Huffman coding in the "deflate" format 在"deflate"格式中使用Huffman編碼
在"deflate"格式中，每一個字母表使用的Huffman編碼方式都有兩條附加規則：
The Huffman codes used for each alphabet in the "deflate"
format have two additional rules:
所有指定了位長度的編碼都有相鄰值。而且與他們所代表的符號有
相同的順序。
* All codes of a given bit length have lexicographically
consecutive values, in the same order as the symbols
they represent;
較短的編碼在時要先於長的編碼。
* Shorter codes lexicographically precede longer codes.
我們可以依照這些規則來重新編碼上面的例子，假定字母表中的
順序是ABCD：
We could recode the example above to follow this rule as
follows, assuming that the order of the alphabet is ABCD:
Symbol Code
------ ----
A 10
B 0
C 110
D 111
0在10的前面，10在11X的前面。110和111是連續的。
I.e., 0 precedes 10 which precedes 11x, and 110 and 111 are
lexicographically consecutive.
有了這個規則，我們可以透過按順序給定字母表中每一個符號的位長度來
為一個字母表定義Huffman編碼。在我們的例子中，編碼由位長度的序列所完全定義。下面
的演算法將編碼生成為整數，規定為從最重要的位讀向最不重要的位。編碼長度為
tree[I].len，編碼則存在於tree[I].Code中。
Given this rule, we can define the Huffman code for an alphabet
just by giving the bit lengths of the codes for each symbol of
the alphabet in order; this is sufficient to detene the
actual codes. In our example, the code is completely defined
by the sequence of bit lengths (2, 1, 3, 3). The following
algorithm generates the codes as integers, intended to be read
from most- to least-significant bit. The code lengths are
initially in tree[I].Len; the codes are produced in
tree[I].Code.
為每一個編碼長度計算編碼的數量。使bl_count[N]為長度為N(N>=1)
的編碼的數量。
1) Count the number of codes for each code length. Let
bl_count[N] be the number of codes of length N, N >= 1.
在每一個編碼長度中找出最小的數值。
2) Find the numerical value of the smallest code for each
code length:
code = 0;
bl_count[0] = 0;
for (bits = 1; bits <= MAX_BITS; bits++) {
code = (code + bl_count[bits-1]) << 1;
next_code[bits] = code;
}
將數值賦給所有的編碼：以第二步中找到的(next_code[bits])為基礎，為相同長度
的所有編碼連續的賦值。不要為永遠不使用的編碼(一位的0)賦值。
3) Assign numerical values to all codes, using consecutive
values for all codes of the same length with the base
values determined at step 2. Codes that are never used
(which have a bit length of zero) must not be assigned a
value.
for (n = 0; n <= max_code; n++) {
len = tree[n].Len;
if (len != 0) {
tree[n].Code = next_code[len];
next_code[len]++;
}
}
Example:
Consider the alphabet ABCDEFGH, with bit lengths (3, 3, 3, 3,
3, 2, 4, 4). After step 1, we have:
N bl_count[N]
- -----------
2 1
3 5
4 2
Step 2 computes the following next_code values:
N next_code[N]
- ------------
1 0
2 0
3 2
4 14
Step 3 produces the following code values:
Symbol Length Code
------ ------ ----
A 3 010
B 3 011
C 3 100
D 3 101
E 3 110
F 2 00
G 4 1110
H 4 1111
3.2.3. Details of block format 塊結構的詳細資料
每個壓縮資料塊都以三個頭位開始：
Each block of compressed data begins with 3 header bits
containing the following data:
first bit BFINAL 第一位
next 2 bits BTYPE 下二位
注意，頭位不需要從一個位元組的邊界開始，因為“塊”不需要佔據完整
的若干位元組。
Note that the header bits do not necessarily begin on a byte
boundary, since a block does not necessarily occupy an integral
number of bytes.
只有當前塊是最後一塊的時候，才設定BFINAL位。
BFINAL is set if and only if this is the last block of the data
set.
BTYPE指定了塊資料是如何壓縮的：
BTYPE specifies how the data are compressed, as follows:
00 - no compression 非壓縮
01 - compressed with fixed Huffman codes 用固定的Huffman編碼來壓縮。
10 - compressed with dynamic Huffman codes 用動態的Huffman編碼來壓縮。
11 - reserved (error) 保留(錯誤)
兩種壓縮方案的唯一不同是：如何定義Huffman編碼。
The only difference between the two compressed cases is how the
Huffman codes for the literal/length and distance alphabets are
defined.
在所有的情況下，解碼的方案如下：
In all cases, the decoding algorithm for the actual data is as
follows:
do
從輸入流讀入塊頭部
if 非壓縮存貯
跳過當前處理的位元組中剩餘的位
讀入LEN和NLEN(見下一節)
向輸出複製LEN位元組。
else
if 動態的Huffman編碼
讀入編碼樹
l(直到塊的結尾)
從輸入流解碼出文字/長度值
if value < 256
向輸出複製value(文字位元組)
else
if value = 塊的結尾(256)
break;(跳出loop)
else (value = 257到285)
從輸入流解碼出距離(distance)
在輸出流中，向後(已經解碼的部分)跳過distance
位元組，複製當前的length位元組
到輸出流中。
end loop
while 不是最後一塊時
do
read block header from input stream.
if stored with no compression
skany remaining bits in current partially
processed byte
read LEN and NLEN (see next section)
copy LEN bytes of data to output
otherwise
if compressed with dynamic Huffman codes
read representation of code trees (see
subsection below)
loop (until end of block code recognized)
decode literal/length value from input stream
if value < 256
copy value (literal byte) to output stream
otherwise
if value = end of block (256)
break from loop
otherwise (value = 257..285)
decode distance from input stream
move backwards distance bytes in the output
stream, and copy length bytes from this
position to the output stream.
end loop
while not last block
注意，一個複製的參考串可能指向前一個塊，如：向後的distnace可能
穿過一個或幾個塊邊界。但是distance不可能越過輸出串的開始。(一個使用預先設定的
字母表的應用可能會忽略輸出流中的一部分，distance可以指出這部分)還要注意，
被參考的串可能會與當前位置重合，如：如果最後的兩個位元組解碼後是X，Y，一個串提
及：
Note that a duplicated string reference may refer to a string
in a previous block; i.e., the backward distance may cross one
or more block boundaries. However a distance cannot refer past
the beginning of the output stream. (An application using a
preset dictionary might discard part of the output stream; a
distance can refer to that part of the output stream anyway)
Note also that the referenced string may overlap the current
position; for example, if the last 2 bytes decoded have values
X and Y, a string reference with
adds X,Y,X,Y,X to the output stream.
現在，我們按順序說明每種壓縮方法。
We now specify each compression method in turn.
3.2.4. Non-compressed blocks (BTYPE=00) 非壓縮的塊
忽略直到下一個位元組邊界的所有位，這塊中的其它內容包含如下資訊：
Any bits of input up to the next byte boundary are ignored.
The rest of the block consists of the following information:
0 1 2 3 4...
+---+---+---+---+================================+
| LEN | NLEN |... LEN bytes of literal data...|
+---+---+---+---+================================+
LEN是塊中的位元組數。NLEN是LEN的補碼。
LEN is the number of data bytes in the block. NLEN is the
one's complement of LEN.
3.2.5. Compressed blocks (length and distance codes)
被壓縮的塊(length,distance的編碼)
如前所述，用"deflate"格式所編碼的資料塊包含一系列的記號來表示
三種概念清楚的字母表：文字位元組，值在0至255之間；或
length表示3至258之間，distnace在1至32768之間。實際上，文字和長度字母表被合併
到一個字母表中,從0至285。其中的0至255表示文字位元組，256表示塊的結束，257至285
表示length，見下表(length可能和幾個存在於符號編碼後面的額外位聯合在一起，表示
不同的含義：)
As noted above, encoded data blocks in the "deflate" format
consist of sequences of symbols drawn from three conceptually
distinct alphabets: either literal bytes, from the alphabet of
byte values (0..255), or
where the length is drawn from (3..258) and the distance is
drawn from (1..32,768). In fact, the literal and length
alphabets are merged into a single alphabet (0..285), where
values 0..255 represent literal bytes, the value 256 indicates
end-of-block, and values 257..285 represent length codes
(possibly in conjunction with extra bits following the symbol
code) as follows:
Extra Extra Extra
Code Bits Length(s) Code Bits Lengths Code Bits Length(s)
---- ---- ------ ---- ---- ------- ---- ---- -------
257 0 3 267 1 15,16 277 4 67-82
258 0 4 268 1 17,18 278 4 83-98
259 0 5 269 2 19-22 279 4 99-114
260 0 6 270 2 23-26 280 4 115-130
261 0 7 271 2 27-30 281 5 131-162
262 0 8 272 2 31-34 282 5 163-194
263 0 9 273 3 35-42 283 5 195-226
264 0 10 274 3 43-50 284 5 227-257
265 1 11,12 275 3 51-58 285 0 258
266 1 13,14 276 3 59-66
額外的位應該被宣告成整數，最重要的位在前面，如：1110代表14。
The extra bits should be interpreted as a machine integer
stored with the most-significant bit first, e.g., bits 1110
represent the value 14.
Extra Extra Extra
Code Bits Dist Code Bits Dist Code Bits Distance
---- ---- ---- ---- ---- ------ ---- ---- --------
0 0 1 10 4 33-48 20 9 1025-1536
1 0 2 11 4 49-64 21 9 1537-2048
2 0 3 12 5 65-96 22 10 2049-3072
3 0 4 13 5 97-128 23 10 3073-4096
4 1 5,6 14 6 129-192 24 11 4097-6144
5 1 7,8 15 6 193-256 25 11 6145-8192
6 2 9-12 16 7 257-384 26 12 8193-12288
7 2 13-16 17 7 385-512 27 12 12289-16384
8 3 17-24 18 8 513-768 28 13 16385-24576
9 3 25-32 19 8 769-1024 29 13 24577-32768
3.2.6. Compression with fixed Huffman codes (BTYPE=01)
用固定的Huffman編碼壓縮
兩個字母表的Huffman編碼是固定的，沒有在資料中明確的指出。
文字/length的Huffman編碼長度如下：
The Huffman codes for the two alphabets are fixed, and are not
represented explicitly in the data. The Huffman code lengths
for the literal/length alphabet are:
Lit Value Bits Codes
--------- ---- -----
0 - 143 8 00110000 through
10111111
144 - 255 9 110010000 through
111111111
256 - 279 7 0000000 through
0010111
280 - 287 8 11000000 through
11000111
上面所述的編碼長度足以產生實際的編碼。文字/length值286至287
永遠不會真正的出現在壓縮資料中，但是也存在於編碼結構中。
The code lengths are sufficient to generate the actual codes,
as described above; we show the codes in the table for added
clarity. Literal/length values 286-287 will never actually
occur in the compressed data, but participate in the code
construction.
distance的程式碼 0-31被表示成5位的編碼以及可能存在的附加位，
如上面3.2.5節中的圖表所示。注意距離程式碼30-31不會真正出現在壓縮資料中。
Distance codes 0-31 are represented by (fixed-length) 5-bit
codes, with possible additional bits as shown in the table
shown in Paragraph 3.2.5, above. Note that distance codes 30-
31 will never actually occur in the compressed data.
3.2.7. Compression with dynamic Huffman codes (BTYPE=10)
用動態Huffman編碼壓縮
一個塊中的Huffman 編碼(對兩個字母表的編碼)存在於頭位的後面，
實際壓縮內容的前面。第一個是文字/length 編碼，第二個是distance編碼。每個
編碼都被一系列編碼長度所定義，見3.2.2節。為了更加簡潔，編碼長度本身也是經過
了Huffman編碼壓縮的(這句話十分重要，以前就是由於沒有透徹理解這一點才會看不
懂後面的內容--注)。字母表的編碼長度如下：
The Huffman codes for the two alphabets appear in the block
immediately after the header bits and before the actual
compressed data, first the literal/length code and then the
distance code. Each code is defined by a sequence of code
lengths, as discussed in Paragraph 3.2.2, above. For even
greater compactness, the code length sequences themselves are
compressed using a Huffman code. The alphabet for code lengths
is as follows:
0 - 15: 表示編碼長度為0 - 15
16: 複製前面的編碼長度3 - 6次，
下兩位指出了複製的次數
(0 = 3, ... , 3 = 6)
如:編碼： 8, 16 (+2 bits 11),16 (+2 bits 10)
會被擴充套件為：
12個長度為8 的編碼 (12 = 1 + 6 + 5)
17: 重複3 - 10 次長度為0
(下三位指出了重複次數)
18: 重複11 - 138 次長度為0
(下7位指出了重複次數)
0 - 15: Represent code lengths of 0 - 15
16: Copy the previous code length 3 - 6 times.
The next 2 bits indicate repeat length
(0 = 3, ... , 3 = 6)
Example: Codes 8, 16 (+2 bits 11),
16 (+2 bits 10) will expand to
12 code lengths of 8 (1 + 6 + 5)
17: Repeat a code length of 0 for 3 - 10 times.
(3 bits of length)
18: Repeat a code length of 0 for 11 - 138 times
(7 bits of length)
編碼長度為0表示文字/length或distance不會出現在塊中，也就不存在
於Huffman編碼中。如果只使用一個distance編碼長度，則編碼時，使用一位，而不是0
位。
在這種情況下，只有一個編碼長度1，和一個不使用的編碼。0位的distance編碼表示沒
有
distance編碼(所有的內容都是文字的)
A code length of 0 indicates that the corresponding symbol in
the literal/length or distance alphabet will not occur in the
block, and should not participate in the Huffman code
construction algorithm given earlier. If only one distance
code is used, it is encoded using one bit, not zero bits; in
this case there is a single code length of one, with one unused
code. One distance code of zero bits means that there are no
distance codes used at all (the data is all literals).
現在我們可以定義塊的格式了(在某一塊中，除了最前面的三個標誌位之外，
就是如下的內容了--注)：
We can now define the format of the block:
5 Bits: HLIT, # 文字/length編碼 - 257 (見3.2.5節。
由於使用了LZ77演算法，所以除了文字之外，還要對
母表中,從0至285。其中的0至255表示文字位元組，256表示塊
的結束，257至285表示length。但由於不一定要使用所有的
length, 所以，這裡的5位表示本塊中所能用到的最大的
值--是指0到285間的一個值--減去257之後的值----注)
5 Bits: HDIST, # of Distance 編碼 - 1 (同理，這裡儲存
的是3.2.5節中描述的在本塊中可能用到的distance的最
大值-1----注)
4 Bits: HCLEN, # of "編碼長度"的編碼 - 4 (其實這4
位中儲存的是所能用到的編碼長度的種類 - 4，這裡的“編
碼長度”是指從0到18的值，其含義在3.2.7節中所定義。換
句話說，有下面一個陣列：16, 17, 18, 0, 8, 7, 9, 6,
10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15，HCLEN+4的值就
表示了在本塊的編碼時，都用到了本陣列中前幾項的長度值，
而其它的長度值則不被使用爭----注)
5 Bits: HLIT, # of Literal/Length codes - 257 (257 - 286)
5 Bits: HDIST, # of Distance codes - 1 (1 - 32)
4 Bits: HCLEN, # of Code Length codes - 4 (4 - 19)
(HCLEN + 4) x 3 bits: 編碼長度表中的編碼長度按照如下順序排列(關鍵的
地方在這裡。這裡3位一組，表示相應位置的長度值在Huffman
編碼中有幾位。這句話不好理解，詳細解釋一下：在前面說過
了，HCLEN+4表示會使用多少種不同的編碼長度值，至於都使
用哪些長度，則檢視下面的陣列，其前面的HCLEN+4項中所示
的值就是本塊編碼中所要使用的編碼長度。於是，在下一部分
中就要分別指出每個字元的編碼長度了 ---- 在Huffman解碼
時，只要知道了每一個字元的編碼長度，就可以無誤的構造出
編碼時使用的二叉樹了。但是目前的問題是，怎樣表示出每個
字元用幾位編碼。為了獲得更大的壓縮，採用了另一個
huffman樹來編碼不同的長度值。就在本部分中，每三位表示
一個值X，這個值X就是指要用X位來編碼陣列中相應位置的那
個長度值。----注)
(HCLEN + 4) x 3 bits: code lengths for the code length
alphabet given just above, in the order: 16, 17, 18,
0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15
這些編碼的長度被表示成3位的整數(0-7)，如前所述，一個編碼
的長度為0，意味著相應的符號(文字/length或distance編碼長度不被使用)
These code lengths are interpreted as 3-bit integers
(0-7); as above, a code length of 0 means the
corresponding symbol (literal/length or distance code
length) is not used.
用Huffman編碼的HLIT+257個編碼長度。(這一部分解碼後是HLIT+257個值，每
個值分別依次代表從0到HLIT+257-1的編碼長度。至於解碼的方法
則是用從前一部分中所得到的Huffman碼。----注)
HLIT + 257 code lengths for the literal/length alphabet,
encoded using the code length Huffman code
用Huffman編碼的HDIST+1的編碼長度。(這一部分解碼後是HDIST+1個值，依次
代表
----注)
HDIST + 1 code lengths for the distance alphabet,
encoded using the code length Huffman code
實際的壓縮資料，使用Huffman編碼的文字/length、distance。(用上面兩部分
中所列舉的編碼長度，可以構造出兩個Huffman樹，再用它們對
這部分中的壓縮資料進行解碼。以上所說的編碼長度均是指用
多少位對資料進行編碼----注)
The actual compressed data of the block,
encoded using the literal/length and distance Huffman
codes
最後寫入256的Huffman編碼,這樣解碼時，解出值256，就會知道
已經到塊尾了。
The literal/length symbol 256 (end of data),
encoded using the literal/length Huffman code
The code length repeat codes can cross from HLIT + 257 to the
HDIST + 1 code lengths. In other words, all code lengths form
a single sequence of HLIT + HDIST + 258 values.
3.3. Compliance
A compressor may limit further the ranges of values specified in
the previous section and still be compliant; for example, it may
limit the range of backward pointers to some value smaller than
32K. Similarly, a compressor may limit the size of blocks so that
a compressible block fits in memory.
A compliant decompressor must accept the full range of possible
values defined in the previous section, and must accept blocks of
arbitrary size.
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10794571/viewspace-974296/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- RFC1951的部分翻譯及原文(1/2) (轉)
- RFC1952的部分翻譯及原文 (轉)
- 【轉載】周易大象傳原文及譯文
- 《新編高中文言文助讀》原文及翻譯
- rabbitmq 官方文件翻譯-2MQ
- docker官方文件翻譯2Docker
- The Pragmatic Programmer 翻譯(前言章節部分) (轉)
- 學php之翻譯wordpress(2)PHP
- Electron教程翻譯2：安裝
- 2 Java NIO Channel-翻譯Java
- cassandra streaming 操作(翻譯2)
- [Flutter翻譯]使用Flutter WEB實現桌面GUI（第2部分：Dock）FlutterWebGUI
- J2EE Development without EJB序言的第一部分的翻譯dev
- The Self-Managing Database: Automatic Performance Diagnosis（一）原文翻譯DatabaseORM
- 蝴蝶書-task2: 文字推理、摘要、糾錯 transformers實現翻譯 OpenAI翻譯 PyDeepLX翻譯 DeepLpro翻譯ORMOpenAI
- [翻譯]http2-for-a-faster-web——快速瞭解http2HTTPASTWeb
- OpenSSL專案路線圖【已翻譯100%】（2/2）
- QT TS檔案翻譯，部分不能正確被翻譯QT
- MySQl引數管理( 部分翻譯）MySql
- <<Modern CMake>> 翻譯 2. CMake 基礎
- DOCTYPE探索【已翻譯100%】(1/2)
- J2EE核心模式的翻譯問題模式
- 對一些詞句翻譯的吐槽（2）
- 張正友標定論文翻譯(2)
- django 1.8 官方文件翻譯： 2-3-2 關聯物件參考Django物件
- GDC演講翻譯——看門狗2的載具同步
- Retrofit 2 0非常簡單的入門（翻譯官方文件）
- Quartz.NET 2.x 文件翻譯 - Lesson 2：Jobs 和 Triggersquartz
- 通過Doctype啟用瀏覽器模式【已翻譯100%】(2/2)瀏覽器模式
- django1.8官方文件翻譯：5-2-2表單素材(Media類)Django
- 【風農翻譯】開始畫畫素畫 #2
- 翻譯 | Learning React Without Using React Part 2React
- 使用Urllib2製作有道翻譯器
- Income sheet報表專案的部分翻譯
- SpringAop英文文件部分翻譯Spring
- 使用 LLVM 框架建立有效的編譯器，第 2 部分LVM框架編譯
- 微軟新CEO的郵件這2篇翻譯哪個好？微軟
- 翻譯：EJB in a Nutshell (轉)