=數據壓縮算法=循環頭部兼或尾部餘數補全算法=
[規則]
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（→←中間的內容，就是指特定數循環，比如→01←就是0101010101……一直循環下去，直到正好補充完數位，如果沒有補充完數位，就是需要有一個餘數數據+?）
七位數的→01←+0就是0101010；
十一位數的→01←+0就是01010101010；
還有一種用法?+→*←（這裏按照通配符的方式定義；?表示隻有一位的任意值；*表示有等於或大於一位的任意值）
算法表示通則：數值a+→數值b←+數值c
其中數值a+表示開頭以什麽為開頭，然後中間的→數值b←表示以什麽為中間的循環數，後麵的+數值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；
[示例完畢]
為了節省篇幅，以及避免作者使用自然人腦來進行比大小這種運算，而且使用的還是二進製，為了避免麻煩和出錯，也就沒有使用什麽三百位的二進製作為注冊表，然而計算機完全可以通過這套算法，生成1kb大小的比大小篩選注冊表，從而加速解壓縮速度，以及碰撞速度。
當然了，如果是使用1gb大小的比大小篩選注冊表，就可以用於zb級別的數據快速解壓縮了。
使用循環規則，把一個數控製在盡可能小的範圍內，然後使用各種進製的轉換，來逆推出其原本是什麽數，減少運算次數同時，也加快解壓縮速度；減少了大量的無用但必須的運算（試錯運算）。
學編程和做編程，如果不是準備做藝術類的應用程序（比如三維內容顯示在二維內）（比如把二維矢量圖記錄為數據）（藝術類應用程序也或多或少的接觸到數學），基本都是純數學，怎麽現在的編程，都不怎麽關注數學了？是我坐井觀天了麽？還是編程已經起源於數學，而又超越了數學？？？
[規則]
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（→←中間的內容，就是指特定數循環，比如→01←就是0101010101……一直循環下去，直到正好補充完數位，如果沒有補充完數位，就是需要有一個餘數數據+?）
七位數的→01←+0就是0101010；
十一位數的→01←+0就是01010101010；
還有一種用法?+→*←（這裏按照通配符的方式定義；?表示隻有一位的任意值；*表示有等於或大於一位的任意值）
算法表示通則：數值a+→數值b←+數值c
其中數值a+表示開頭以什麽為開頭，然後中間的→數值b←表示以什麽為中間的循環數，後麵的+數值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；
[示例完畢]
為了節省篇幅，以及避免作者使用自然人腦來進行比大小這種運算，而且使用的還是二進製，為了避免麻煩和出錯，也就沒有使用什麽三百位的二進製作為注冊表，然而計算機完全可以通過這套算法，生成1kb大小的比大小篩選注冊表，從而加速解壓縮速度，以及碰撞速度。
當然了，如果是使用1gb大小的比大小篩選注冊表，就可以用於zb級別的數據快速解壓縮了。
使用循環規則，把一個數控製在盡可能小的範圍內，然後使用各種進製的轉換，來逆推出其原本是什麽數，減少運算次數同時，也加快解壓縮速度；減少了大量的無用但必須的運算（試錯運算）。
學編程和做編程，如果不是準備做藝術類的應用程序（比如三維內容顯示在二維內）（比如把二維矢量圖記錄為數據）（藝術類應用程序也或多或少的接觸到數學），基本都是純數學，怎麽現在的編程，都不怎麽關注數學了？是我坐井觀天了麽？還是編程已經起源於數學，而又超越了數學？？？