=數據壓縮算法=循環(huán)頭部兼或尾部余數補全算法=

[規(guī)則]

1：定義一個特定長度來分割整個被壓縮文件。

2：定義一系列的特定長度特定內容的比對大小數據。

3：統計被壓縮文件總共有多少個二進制0和二進制1；統計被壓縮文件換算成17進制，有多少個0到9，A到G；統計被壓縮文件換算成十進制三位數的素數進制，各有多少個？？？；統計被壓縮文件換算成十進制四位數的素數進制，各有多少個？？？；統計被壓縮文件換算成十進制五位數的素數進制，各有多少個？？？；以此類推，文件越大，換算的進制數量越多。

[示例]

被壓縮文件：1001010001000011000110111011101111011101110111011101110111011101110111011101110110100100111001

按照7位來分割，就分割成了

1001010

0010000

1100011

0111011

1011110

1110111

0111011

1011101

1101110

1110111

0111011

1011010

0100111

001

記錄尾數是001（不足7位）

然后就是設定特定長度特定內容的比對大小數據：

常見的→01←+0（→←中間的內容，就是指特定數循環(huán)，比如→01←就是0101010101……一直循環(huán)下去，直到正好補充完數位，如果沒有補充完數位，就是需要有一個余數數據+?）

七位數的→01←+0就是0101010；

十一位數的→01←+0就是01010101010；

還有一種用法?+→*←（這里按照通配符的方式定義；?表示只有一位的任意值；*表示有等于或大于一位的任意值）

算法表示通則：數值A+→數值B←+數值C

其中數值A+表示開頭以什么為開頭，然后中間的→數值B←表示以什么為中間的循環(huán)數，后面的+數值C表示以什么為結尾；

十三位數的0+→01←+10就是0010101010110；

十九位數的0+→01←+10就是0010101010101010110；

常用的→數值B←的取值：

二位數：00，01，10，11；

三位數：000，001，010，011，100，101，110，111；

以此類推，然而并非所有的取值都會用到，只有用到時，才注冊，沒用到時，不注冊；

注冊表：

定義：

七位數的→01←+0是A；0101010

七位數的→10←+0是B；1010100

七位數的→101←+0是C；1011010

七位數的→010←+0是D；0100100

0101010A

1010100B

1011010C

0100100D

1001010被注冊表定義為大于A，小于B；3個1，4個0；

0010000被注冊表定義為小于D；1個1，6個0；

1100011被注冊表定義為大于C；4個1，3個0；

0111011被注冊表定義為大于A，小于B；5個1，2個0；

1011110被注冊表定義為大于C；5個1，2個0；

1110111被注冊表定義為大于C；6個1，1個0；

0111011被注冊表定義為大于A，小于B；5個1，2個0；

1011101被注冊表定義為大于C；5個1，2個0；

1101110被注冊表定義為大于C；5個1，2個0；

1110111被注冊表定義為大于C；6個1，1個0；

0111011被注冊表定義為大于A，小于B；5個1，2個0；

1011010被注冊表定義為等于C；4個1，3個0；

0100111被注冊表定義為大于D，小于A；4個1，3個0；

[示例完畢]

為了節(jié)省篇幅，以及避免作者使用自然人腦來進行比大小這種運算，而且使用的還是二進制，為了避免麻煩和出錯，也就沒有使用什么三百位的二進制作為注冊表，然而計算機完全可以通過這套算法，生成1KB大小的比大小篩選注冊表，從而加速解壓縮速度，以及碰撞速度。

當然了，如果是使用1GB大小的比大小篩選注冊表，就可以用于ZB級別的數據快速解壓縮了。

使用循環(huán)規(guī)則，把一個數控制在盡可能小的范圍內，然后使用各種進制的轉換，來逆推出其原本是什么數，減少運算次數同時，也加快解壓縮速度；減少了大量的無用但必須的運算（試錯運算）。

=作者的話=

學編程和做編程，如果不是準備做藝術類的應用程序（比如三維內容顯示在二維內）（比如把二維矢量圖記錄為數據）（藝術類應用程序也或多或少的接觸到數學），基本都是純數學，怎么現在的編程，都不怎么關注數學了？是我坐井觀天了么？還是編程已經起源于數學，而又超越了數學？？？