「傳輸自動生成代碼並執行、生成所需文件」能否成為未來的下載方式？

11-25

原文件
︾
︾
拖到客戶端自動轉換成一段可執行代碼（文本體積小）
︾
︾用戶端根據下載代碼，執行命令自動生成文件現在的文件傳輸是直接把整個文件傳輸吧，耗時且出錯率高
優點●將網路因素的影響直接降到最低，轉換成代碼恐怕不及原文件大小的千分之一，下載用時壓縮 ●伺服器成本減少
缺點●受限於電腦配置，影響文件合成速度

請問我的想法是否可行，能否給出一些意見？我說的並不是壓縮文件，而是類似於一張設計圖紙讓計算機執行，自動生成新文件

～～～～～看到這麼多人回答真的很開心呢，題主只是一個高三學生，愛好電子但對編程類知之甚少，上課突發奇想，然後被當作民科群嘲(?ω?) 哈哈哈哈

可能大家沒有足夠明白，但是我覺得原理是說的通的，大學上計算機再研究吧

我先高考去了

這個東西其實已經有人想出來了，就是過程生成（Procedural Generation)。
當然，這個並不是一種真正的「壓縮」技術…

話說當年，有一款遊戲叫做「毀滅殺手」（.kkrieger）

下載鏈接：scene.org file archive :: kkrieger-beta.zip
（右邊直接選Automatic）

這是一幫德國人在2005年開發的一款遊戲，劇情其實很簡單的，就是在一個外星基地裡面打打外星人，路上有幾把槍幾種敵人，最後有個boss。通關可能連30分鐘都不用。不過要我說，這個畫質放在2005年來看還是蠻不錯的，就是音樂次了點。

（2006年出的老滾4）

不過呢，這個遊戲有一個特別厲害的地方，不敢說前無古人但絕對是後無來者，那就是他的體積：

……等一下，讓我再看一眼。

卧槽！竟然只有96KB！？！？！
（作為比較，上面那張遊戲截圖的大小是172KB，近乎兩倍體積）

這遊戲真是逆了天了。

是怎麼做到的呢？

「kkrieger makes extensive use of procedural generation methods. Textures are stored via their creation history instead of a per-pixel basis, thus only requiring the history data and the generator code to be compiled into the executable, producing a relatively small file size. Meshes are created from basic solids such as boxes and cylinders, which are then deformed to achieve the desired shape - essentially a special way of box modeling. These two generation processes account for the extensive loading time of the game — all assets of the gameplay are reproduced during the loading phase.」

--Wikipedia

辦法和題主說的還真的一樣，通過儲存生成器和創造步驟來使複雜的紋理變成了非常省地省空間的執行代碼。而大部分形狀則都是通過圓筒和立方體的扭曲變形，畢竟保存一個建模還是省空間。

而運行之後，遊戲本身便會開始執行生成步驟，將所有的紋理建模在內存中生成出來。所以為什麼打開遊戲之後會有漫長的讀取時間，以及不科學的內存佔用量。

「According to the developers, .kkriegeritself would take up around 200–300 MB of space if it had been stored the conventional way.」
-Wikipedia

嗯，200MB的遊戲，愣是被壓縮到了0.1MB，這壓縮率，讓我算算……
恩，0.5‰，看來題主提出的千分之一還有不少富裕呢。

In computing, procedural generation is a method of creating data algorithmically as opposed to manually. In computer graphics it is commonly used for creating textures. In video games it is used for creating items, quests, and level geometry. Advantages of procedural generation include smaller file sizes, larger amounts of content, and randomness for less predictable gameplay.

簡單來講，就是並非通過保存成品，而是通過保存生成器和生成步驟，讓程序在啟動之後按照步驟重新將成品生成出來。

當然啦，這種壓縮方式有相當大的局限性。

首先他實際上並不是「壓縮」，他實際上是屬於再創造了...有一點像你自己買了個需要自己組裝的書桌...不對，這個其實連書桌的木板都沒給你，實際上就給了你一個如何砍樹做板材拼裝的手冊……
而一般的壓縮，則是把書桌研究一下，然後拆成一塊一塊的，最後配一本組裝說明書發送給你。

過程生成的缺陷就顯而易見了，他的內容從一開始就要決定是要通過特定的編輯器來創造並記錄過程。所以如果採用的是導入的素材（比如說現實世界中的樹啊布啊的紋理，人臉動物皮膚什麼的），那麼很明顯是無法進行「壓縮」。而普通壓縮方式則不一樣，因為他實際上是從已存在的文件入手，用詞典（說明書）的方式來對重複，空白部分進行索引以達到節省空間的方式。

另：
拓展閱讀：Procedural generation
.kkrieger創作者farbrausch的網站:http://www.farbrausch.de/

1、一個文件最小也不會小於它內部碼符號信息量的總和。如果用二進位表示，那麼底數取2，單位取Bit，一個文件的大小是 $-sum_{i=1}^{n}{Log_{2} Pi}$ Bit。n是信源符號所有子串的個數，Pi則是這個子串在這個文件中出現的概率。
現有壓縮方法主要是找到較長的高概率出現的重複子串，用一個較短的碼符號去替代它，減少n的個數以及這個子串的信息量表示。因此文件壓縮的極限尺寸，不會低於這個文件所有可能子串的排列組合中最小的 $-sum_{i=1}^{n}{Log_{2} Pi}$ Bit。
易見只有當某個文件內，存在一個超高概率出現的超長子串，才能把文件壓縮到不足原來的千分之一。
關於壓縮，我在另一個回答中也有說到一些，這裡不再重複說明。

2、關於程序編譯，幾百Bit的代碼，編譯出來的程序再壓縮，也可能超過數萬甚至數十萬 Bit。
這是因為編譯的過程中，引入了庫函數和編譯器本身的信息。
例如你打一行printf，那麼printf的原型是：

int printf(char *fmt, ...) { va_list args; int n; va_start(args, fmt); n = vsprintf(sprint_buf, fmt, args); va_end(args); write(stdout, sprint_buf, n); return n; }

問題來了，va_start、vsprintf、va_end、write你又得找到它的原型……
如此往複，最後為了把printf變成可執行文件，你需要引入大量的函數，還需要編譯器來將其轉換為機器碼。
這些編譯器和庫函數是無中生有的嗎？當然不是，假如這種無中生有的事，你再幫他說一遍，這等於你也有責任吧？所以你需要去下載它。

那麼所需要的Dependencies包含的信息量，必然遠遠大於你最終編譯生成的可執行文件。
再舉一例，如果你把一個可執行文件反編譯回Java傳輸，你想把他還原（也就是你說的解壓），那麼你還需要下載一個額外的JDK（約180 MiB）。

3、高票答案中提及到的kkrieger，除了系統自身的Dependencies外，它本身的信息量其實也並不高，只是看似艷麗的畫面給了你們錯覺。

4、如果你所謂的「壓縮」是指編程實現一個非常巨大的、有規律的、循環的輸出。且不論幾乎所有數據都不能滿足這個前提條件，時間換空間很多時候也並不是一個聰明的選擇。我在我還是初中生的時候，就自己編程實現了一個全世界最大的彩虹表，可以破解迭代任意次數的MD5，你只需要花一些時間去「解壓」它，當然這個時間可能會長達數百億年。

5、題主你這種想法給我這麼一個感覺：

magnet：？xt=urn：btih：41649B2378B73CAD34E432D3C7B3FF3FE295979C

看，我把14,602,888,806 Bit的文件壓縮成了480 Bit。
當然，這只是你的感覺（眼鏡發光）。

然而並沒有什麼卵用，雖然這串信息確實對應某個1.7G大小的的文件資源，但是因為這個信息在傳輸過程中嚴重失真了，你缺乏Dependencies來補全，所以並沒有辦法在沒有網路的情況還原它。
然而引入Dependencies，他也只會跟沒「壓縮」前相等甚至變得更大。

6、關於數據壓縮的類似的民科理論還有很多，最後分享一個算是比較有趣的民科理論。
載於《科幻世界》1999年第2期，作者名為星河，節選一段：

很久很久以前有一個傳說，講得是有一天地球上突然來了一名外星人，自稱只要通過手中的一根金屬棒就能帶走地球上所有的知識。地球人不信，於是外星人說道：我們假設地球上所有的知識都寫在英文版的超級百科全書里，現在我給26個英文字母和10個阿拉伯數字編上號碼——A是01，B是02，……，Z是26，a是27，……，0是90，1是91，……；再加上一些常用的標點和符號，比如「.」是60，$」是79，空格是00，轉行是88，……，等等，那麼百科全書上任何一段語句就都可以被看作是一串數字，例如「Aquickbrownfoxjumpsoverthelazydog.（一隻伶俐的棕色狐狸跳過這隻懶惰的狗。）」就可以被寫作「01004347352937002844414940003241503647394245004148314400463431382752510030413360」；而整部百科全書則是一串長長的天文數字。但請注意，無論這個數字多長仍然有限，這時我只要在它前面加一個小數點，它就會成為一個小於1的純小數。因此我只要把這個金屬棒的長度看作1，那麼總能找到一個點，使它的坐標恰好是這個小數。地球人聽罷不禁愕然。

也就是用一個近乎無限精度的模擬量來儲存一個離散量。
那麼隨著科技的發展，未來用一個0.xxxxxxxxxxxxxxxxxx V的電信號來表示和傳輸數據豈不是能在瞬間傳遞任意大的數據？然而拋開工程上的失真、干擾、辨識度等種種困難不講，這個想法理論上也是不可行的。
現在大家都知道量子物理學了，民科也有很多宣稱自己涉獵了量子物理學，那麼只要對量子物理學的有一點最基本的了解，自然知道這個方法是不可行的。

這不就是 git clone 然後 make install 么？

挺反感現在某些知乎上的人，莫名其妙因為別人知道得多一點就產生優越感，開始嘲諷。這樣的行為跟台灣酸民和香港激進學生有什麼區別。這是學術討論的地方，不是你們秀優越感的地方。

提問者只是一個高三的學生因為不了解理論知識而產生了一個不太科學的想法而已，闡明原理就能夠讓他理解的人，憑什麼拿他跟妄圖否定科學根基的「民科」相提並論。你們高三的時候人人都懂得資訊理論么，能夠一眼看出各種永動機的理論缺陷么？原子理論和化學體系沒有建立起來的時代，牛頓不也苦心鑽研鍊金術么？

設你的代碼是x, 需要生成的內容是y
編譯運行可看做一個映射f: x-&>y
你需要找到一個x，使得y=f(x)，同時滿足length(x) + length(f) &<&< length(y)，f(x)是通用的或者說足夠簡單的，這裡你已經說它是編譯運行了，那就是通用了.
如果能找到這樣的
x，你的目標就達成了。

在特定情況下，這樣的壓縮方式是可以的，比如說你跟女朋友表白，又不想太直白，在畫圖板里點像素又太麻煩，你可以丟給她一個函數：
$r=1-sin heta$
畫出來是這樣的

好吧，如此完美的屁股的形狀，其實有更好看但是複雜一點的。
$9x^2-8|x|y+9y^2=1$
畫出來是這樣的

3D的也有， $(x^2+9y^2/4+z^2-1)^3-x^2z^3-9y^2z^3/80=0$

從本質上說，這三個方程，跟你所說的程序是一個東西，生成的圖像也可以對應你說的需要壓縮的「信息」，壓縮效果其實非常好。但是注意這些壓縮都是有條件限制的，就是在特定的環境下才能夠起作用，比如在這裡輸入限定為方程，輸出限定為函數圖像。

那我們通常說的壓縮指的是什麼問題，是對於計算機儲存的任意長的0/1序列，能夠通過一個通用的f得到一個更短的0/1的序列的映射，同時能夠無損地轉回來？答案是肯定的，是能夠通過某些演算法得到，但是這樣的通用演算法壓縮率是有限制的，限制是多少，這個問題請學習資訊理論。

不過換個角度說，有的實際應用跟題主的想法非常類似，不過它並沒有「壓縮」的過程，而只有映射。

就比如說，linux下很多程序都是直接下載源代碼之後本地編譯成可執行文件的，源代碼本身比二進位文件小很多，特別是經過壓縮以後。但是源代碼本身並不是可執行文件壓縮得到的，因為目前還沒有一個通用演算法能夠把二進位文件反編譯成和原來代碼長度差不多的源代碼。

建議樓主試著實現一下你的想法——這個程序一點都不難話說，而且可行（真的可行！）
然後如果發現問題
好好研究一下資訊理論和香農定理

第一：請參考html css js全部都是下載源代碼到達你的環境（瀏覽器）執行的，但是依然有很多人覺得網頁打開慢
第二：請參考各種遊戲的模擬器，首先你得給我折騰個模擬器在你的電腦，好了，裝完之後，再發個遊戲你自己打開運行（模擬器可以參考PSP NDS GBA等PC模擬器甚至Android studio）
第三：甚至上面都解決了，你的所有什麼php環境,java環境，nodejs環境等等給折騰了一次之後，請來試試蘋果，如果你裝好了Xcode（看好了windows的不行,跨平台請自行解決），甚至折騰好了IOS模擬器，我的ipa源代碼直接發你運行，你的下載的確變快了，好吧，那真的是開源世界了，世界從此沒有了知識產權，喬布斯怒從棺起
那麼最後問題來了Xcode有多大？

題主應該學習一下資訊理論和壓縮演算法方面的知識。

舉個例子，我有一個文件，內容是「123456」，那麼一個「生成123456這個文件」的程序一定比這個文件本身小么？

實際上，你所描述的「生成一個文件的程序」就是對文件內容的壓縮描述方法，例如123456可以描述為1-6，僅僅一個-就代表了23456，當然落實到程序上肯定不會這麼去表示。

但是如果文件內容是全隨機的呢？那麼生成文件的程序里就必須完整記錄要要生成文件的全部內容，否則由於內容隨機，彼此沒有關聯，無法「舉一反三」，必須全部記錄下來。
而我們平時說的文件壓縮用通俗的話說就是對文件找規律，找出其中內容的聯繫，例如連續6個0可以即為06，這樣就壓縮了三分之二（當然遇到12345就得記成1121314151反而划不來了）。

那這跟WinRAR的那個固實壓縮包再加一層exe的殼上傳上去有什麼區別？

由於不可計算數遠比可計算數多，所以不存在這樣的通用演算法的。

那個pifsphilipl/pifs · GitHub 的想法是不切實際的，實測結果是metadata的大小比原文件更大。

簡單的解釋一下，我們假設有演算法，生成了一列數，它包含可能的100以內的正整數10進位表示。那麼所有100以內的數都可以用一個位置和一個長度來表示了。我們用最平凡的方式生成這列數，於是發現，為了表示"99", 我們需要用（188,2）,已經超過了99本身的表示法所用的bit數了。

不要死磕資訊理論嘛……

假設人類現在的知識總共是100Pb，某人設計出來了一小行代碼，只需1kb執行就能生成全部的人類知識。
但根據香農資訊理論，至少有100Pb-1kb的100Pb大小的數據你們無法用這種辦法生成，不能接受這個叫做壓縮！

拜託，那些壓不下來的文件，who cares？
我只希望我需要的文件壓縮下來就行了啊……

而且根據資訊理論，照這麼算，我們的壓縮軟體根本不能工作好嗎……

我們在討論壓縮，不是違反資訊理論的穩定壓縮！

========原回答=======

看到這麼多IT大神群嘲，生物狗來強答一個……

你們都沒get到題主的意思啊！題主說的壓縮方法我們用了幾億年了啊！

=====逗逼故事的分割線=====

2058年地球與KIC8462852方面依賴微型蟲洞取得了聯繫，由於每次只能發送32kb級別的信息/能量/物質，我們邪惡的程序員Adam只得發送了一張愛喵的皂片。
於是K對地球文明陷入了瘋狂……

K：未知文明，我們的文明已經率先解析了本宇宙全部基本規律，正在搜集能量以打開空間維度捲曲，解放熱力學第一定律，因此我們不存在任何利益衝突。我們已將所有我方已知的數據發送到你們的坐標，希望能換取一隻喵星人的原子陣列文件。文件上傳和解壓需要花點時間，請慢用！

E文明表示不能辜負宇宙文明之間最基本的信任，組織了大批測量學人士對Adam的愛喵Emily進行測量，要求精確到百分納米級，每個原子都不能定錯位。
接下來無數IT大牛對著生成的海量數據發愁……

Ian Wilmut不能忍了：卧槽，你們就不能只測一個受精卵的數據然後加一個ReadMe.txt解釋怎麼培養嗎？

旁邊一個搞遺傳學的phD忍不住提醒了一句：大神，其實送個基因組和表觀遺傳數據就可以了……記得把病毒序列剔掉……

旁邊一個搞生信的phD冷笑一聲：你們就不能發個最早的單細胞生物基因組序列，告訴他們用什麼條件自己去算演化演算法結果嗎？

一個合成生物學的phD沉思良久：我認為基因組都可以不用發，你們給合成條件讓他們模擬就行，雖然算出不來原模原樣的貓但能算個類似的趨同演化產物就行。

最後一個長著一大把鬍子的老頭髮話了：不，我認為只需要五個公設就行……
=====完=====

結尾有點扯不過發育生物學上看的確是這樣。兩個雙胞胎那麼大的信息量相當於受精卵基因組在細胞環境內的自解壓產物。

這有點像摺紙：你或許很難通過說清楚你的紙飛機成品長啥樣來讓別人重複，但你可以很容易地教會別人怎麼疊。基因組儲存的不是生物長啥樣，而是怎麼一步步搭建出生物體。
#新高票給的那個名詞好形象……「步驟生成」……還是你們計算機專業的會起名……

再例如我要給別人發這樣一個模型……

用點陣完整描述這個形狀起碼好幾兆吧，不過其實我可以只發百來位元組過去：
((z - 3 ArcTan[x - 3])^2/(3 (1 + 3 E^(-(2 x/3 - 2)^2))) + (3 + x/10)^2*(y + 1/3 (Sqrt[x^2 + 8] + x) + 1/2)^2/(16 (E^(-x^2/3) + 1)) - 1) ((z - 3 ArcTan[x - 3])^2/(3 (1 + 3 E^(-(2 x/3 - 2)^2))) + (3 + x/10)^2*(y - 1/3 (Sqrt[x^2 + 8] + x) - 1/2)^2/(16 (E^(-x^2/3) + 1)) - 1) ((x - (x + y + z)/9 + 7)^2 + (z - (x + y + z)/9 + 2)^2 + (y - (x + y + z)/9 - 3)^2 - 2) ((x - (x - y + z)/9 + 7)^2 + (z - (x - y + z)/9 + 2)^2 + (y + (x - y + z)/9 + 3)^2 - 2) == 4,
{x, -10, 10}, {y, -10, 10}, {z, -10, 10}

電腦文件也類似的，文件里只需要描述：
「這一段文件是吧……嗯……你去把π的十進位小數算出來，到裡面找一個MD5碼是xxx的n長度數串，就是你需要的數（kang）據（ti）啦！」
「哦……這一段啊，我們寫的是oo，你可以把Windows系統內核里的xxx區域寫的文件拷（zhuan）貝（zuo）過來，正好一樣……」
「額……這個常數是多少我不記得了，你算一下目前已經解析出來的數據里的xx到oo那一段對應的代碼，看第n位往後5634位就能知道了~哦對了，拿來算的這個代碼不屬於這個文件，算完記得刪（jiang）除（jie）掉哦。」
「這一段→_→你懂得啦~你知道要寫什麼的啦~猜一猜嘛么么噠~」

這個方法真的可以達到千分之一的壓縮率……但是你們IT行業不會壓的那麼喪心病狂，因為你們面對的數據沒有那麼多能被「你懂得」和「自己去算」的成分……
沒記錯的話avi的壓縮就有針對視頻進行「這一個區域在這段時間沒太大變化，只要留第一幀的數據就行了」的操作，其實已經在運用題主說的部分方法了。
對於某些文件內容冗雜（例如各種附加屬性，某些格式即使沒有這個屬性也會在文件里塞個「此處為空白」的玩意兒占空間），壓縮軟體也會大刀闊斧的砍掉——「沒有就沒有，別瞎BB，解壓的時候再給你補一個就是了，反正是空的」……

以上。

P.S.圍觀了一下高票給的這個鏈接里的下載流量記錄……暴露一切……

6號以及之前都是10+而7號突然跳到了682……今天（8號）目前是85……
論利用互聯網研究社會行為的可能性……
誰敢抄這個高票，這個流量記錄分分鐘暴露你！

從數學上來講，即使加上各種庫，各種計算方法，能表達的信息空間也是受限的。比如你用100bit，能表達2^100的信息作為輸入，你有2^10000種函數來供調用，但你可表達的空間仍然是受限的。壓縮有上限，信息空間首先是第一個原因。即使表達的空間很大，信息空間更大。

另一個是信息能否轉換成解析式，如何獲得解析式是更難的事情。

題主的意思是用小程序去生成大程序？

你說的辦法可以適用於部分領域。
已經在使用了，比如:
傳輸音頻wav文件之前，可以轉換為APE，flac等格式，可以減少體積一半了，如果轉換為mp3，更小，轉換為midi，微小，會信息損失而已。
傳輸密碼字典，這種文件可以很大，但可以傳輸字典生成程序，接收後自己生成即可。
這基本屬於用時間換空間理論。
很久以前有過64k小程序，有點你說的意思。
有個傳說是把所有信息轉成很長的二進位，前面加個0.就是一個小數，把這個數字刻度刻在一根1根單位為1的小棍上帶走，就等於帶走地球上所有信息了，至於怎能讀取出來，好像是外星人的事了。
現階段，大眾常見的形式就是文件解壓縮了。或者叫信息編解碼。
希望你能有所更高明的發現。

題主想的類似於
C語言…下載源代碼然後自己電腦編譯？

自解壓文件_百度百科

你這種，只能是公式化的數據，而非被創造的數據。
雖然不能憑空說個定力，但我隨意提個猜想: 被生成的內容信息量必定小於（演算法或信息生成裝置本身）+原數據的總信息量。

比如實時高清cg電影，那是原始數據加生成程序加gpu運算產生的。實際信息量與預生成沒有壓縮的同等級視頻數據量是一樣的。下載這樣一組數據來生成電影下載量確實會少，但省去的部分是要硬體運算來彌補的。關鍵這組用來生成電影的數據本身並不小多少，它本身加演算法也包含了整部電影的信息量。

我跟你講...其實HTML就是這個原理...一模一樣...

你訪問網頁時發一個wget命令給伺服器...

然後伺服器將這個網頁的HTML代碼返回給你...

只是幾行代碼...

然後再由瀏覽器將HTML代碼解釋並繪製成整個網頁...

你設想整個網頁包括表格文字邊框背景等等等等如果都以圖片形式發給你那是不是要很大的空間了

當年我還小，想把一個遊戲傳給我同學。但那時候qq還不能傳文件。
然後我靈機一動，想著把文件轉換成文本，然後發給我同學，他再轉回exe的就好啦。而且文本文檔多小啊，不都是只有幾KB這麼大么。

機智如我！

然後我直接把.exe改成了.txt，再打開。媽蛋開死機了……重啟之後看了一眼屬性。

這是我第一次見到單位是MB的文本。

首先很遺憾的告訴題主，你的設想早就被廣泛應用了。
譬如你現在打開的知乎網頁，就是由伺服器根據用戶的狀態自動生成的，每個用戶拿到的頁面都是完全不一樣的。即所謂的「動態網頁」。
再譬如你在線看視頻、聽歌，那也是分段下載的，不需要的文件不下載。

然後就題主關注的對可執行代碼的壓縮問題，很遺憾的是那不現實。
首先，可執行代碼本身所佔的空間非常小，大量的流量是被圖片、視頻流等不易拆分的數據佔據的（除了在線看那種有明顯時間分段特徵的模型），所以效果不大
其次，拆分可執行代碼很複雜，要保證依賴完整，風險很大
再次，代碼中重複冗餘的部分佔的空間，其實整體打個壓縮包不就好了，又簡單又成熟又安全，幹嘛勞神苦思去拆代碼。。。

題主的想法可能更接近於「矢量圖」這個概念。

點陣圖是通過定義每一個點來確定圖形，而矢量圖則是通過公式來繪製圖片，點陣圖的圓形可能需要100個點，而矢量圖只需要一個公式，聽起來同樣的圖片明顯矢量圖更小一些對吧。

但是實際上很多圖片用矢量的方式表示並不簡單，因為你幾乎沒有辦法用幾個簡單的公式表示出來，強行用公式的話，只能一個公式表示一個點，如此就比點陣圖還要大了。

所以題主的這個想法是可以的，而且我們已經在使用了。壓縮演算法其實就是把一些數據變成了公式，解壓的時候再執行代碼還原。

樓主想到的並不是什麼神奇的黑科技，這就是當今現實的技術。