[四格]無題

無本文

無本文

無本文

>>842155
Just Monika

>>842157
等等！第三件壽司裡面裝了什麼！？

>>842157
.ex…

>>842168
Just ika

>>842176
>等等！第三件壽司裡面裝了什麼！？
看起來是zip實際上是exe
應該是很有年份的病毒檔

身邊的同學朋友總是問我為什麼都要把
"隱藏已知檔案類型的副檔名"取消掉
這樣在編輯檔案名稱的時候會很麻煩
而我每次都是回答:
怕類似>>842157
的情況

駭客任務的壽司

>>842218
一個有常識的電腦使用者都會顯示副檔名吧...

>>842218
什麼？
不顯示副檔名的話編輯名稱不是很麻煩嗎？

>>842235
看用途吧，沒顯示副檔名也只要留意附圖這個"類型"就好

>>842218
F2按下去不是不會選到副檔名嘛。

>>842257
普通操作也不會選到副檔名(WIN7)

>>842157
再怎樣壓縮也不至於體積(容量)變大吧？

>>842218
我看不到副檔名就會很焦躁
就好像可樂的包裝被撕掉一樣難受

>>842284
你知道嗎？
世上所有的壓縮檔技術
都勢必會把某些檔案的容量變大，某些變小
而且容量會變大的其實佔大多數，壓縮過後容量變小的才是特例
這是有邏輯上的理由的，所以不管技術再怎麼發達都絕對不可能突破

不過說變大，其實通常也就大個幾十Bytes而已
巨觀上來說其實比較像是沒變
而壓縮後會變小的檔案雖然在理論上是佔少數
但我們日常實際會用到的檔案絕大多數都是這些少數特例
也是因為這樣才有辦法玩壓縮

如果你想體驗看看什麼叫壓縮過會變大的話
你就把一個已經壓縮過的檔案再壓一次，如此反覆遲早會變大
一個優秀的壓縮法應該壓第二次就要變大了

>>842286
聽起來很有趣，原理是？

>>842286
你對壓縮算法的理解不太對
其實本質就是罰抄時偷懶
在原本的資訊存在大量贅複和冗餘時
就偷吃步用更簡短的形式來表記
如果資訊密度已經非常高
已經字字珠璣沒什麼廢話好再壓榨了
這種時候就沒什麼用甚至出現反效果

>>842295
我不清楚學界怎麼稱呼它，甚至不知道有沒有討論過這東西
我自己把他叫作可能性空間不足
經過壓縮以後，每個檔案都會變成另一個檔案
而為了讓它可以解壓縮，這個變換過程必須是可逆、一對一的
A壓縮過後會變成B，那C壓縮後就不可以也是B，否則你會不知道B解壓縮該變成A還是C

然而，B也得要能壓縮
雖然規則上是允許壓縮後變成自己，例如D壓縮後變成D，解壓縮還是D
但B的位置已經被A搶走了，所以他只能變成別的檔案，例如E
然後就換E找不到位置...
依此類推，最後一定要有個人回頭變成比較大的檔案(A)
否則低容量空間會爆滿

1Byte的檔案就只有256種，翻遍世界你都找不到第257種只佔1Byte的檔案
你把一個2Byte的檔案變成1Byte，那1Byte空間就爆滿了
你勢必得把舊的那256種檔案的一個給踢出1Byte空間，否則塞不下


更直白一點就是說
你把一個檔案餵給壓縮軟體不斷重複壓縮
他有可能最後大小變成0嗎？不會吧
但根據第一段講的，也不可能循環 (A→B→C→B→C是不可能的，因為你不知道B要解成A還C)
那怎麼辦？只好變大了

>>842303
我的重點就是勢必存在某些字字珠璣的筆記無法再壓榨
而且不只是無法壓榨，還必然會發生反效果
不管怎樣的壓縮技術都逃不掉這個命運

而實務上
腦袋正常的壓縮軟體遇上這種字字珠璣的筆記
就只會在前面加一個標籤寫說「這個筆記我壓不下去了，原文就長成：...」
然後解壓縮的時候把這個標籤砍掉
標籤必須要存在，否則壓縮跟解壓縮的次數會對不上，這就是反效果
(把一個檔案重複壓了100次，但只解壓縮1次就變回去了，如果使用者腦殘繼續解剩下的99次就會當掉)

>>842310
https://zh.wikipedia.org/wiki/熵_(信息论)
這個相關的討論關鍵字就叫ENRTOPY

>>842256
真是愚蠢，為了散布病毒，除了壓縮檔，圖片、影片、音樂、種子都有人拿來偽裝，只要是有人會想點開的都有

>>842284
>>842308
壓縮的原理很簡單
就是把重複出現的內容用簡短的代號代替
並在檔案前面建立一本對照用的字典
以壓縮英文文章的文字檔來舉例
如果like這個單字出現頻率最高
我們就用1來代替like
並在字典中建立對應 1=like
然後再找出頻率第二高的單字 如because
並在自店中建立對應 2=because
不斷的循環這個步驟就可以建立好一本專用字典和用代碼取代後的文章
這樣檔案就縮小了

所以如果你把壓縮過的內容在經過以上步驟，勢必無法再縮小了

詳細細節參考wiki
https://zh.wikipedia.org/wiki/霍夫曼编码

>>842317
給寫好的字典再編輯一份解說字典的感覺

>>842308
自己有寫過JPG、PNG壓縮程式，還是看不太懂你在說什麼

如果是用PNG那種無損壓縮法，壓過一次之後再壓就沒什麼意義了，因為壓縮法不像人類會偷懶，第一次壓就是100%的全力壓，不用再壓個兩三次
差不多像是>>842317 講的對照表一樣，那張表在第一次壓縮產出後就沒什麼好壓縮的

第二次、第三次檔案大小還會有變動
那是因為壓完之後還會加上一些tag，讓電腦知道這東西是用什麼壓縮法壓的，第二次壓縮就是把這些tag也壓進去，然後加上新tag，基本上大小不會有太大的變動


會越壓越小的是像JPG的有損壓縮
每次壓縮都會丟掉一些被認為是雜訊的資料
但那也是有極限的，最終會只剩下高強度資訊，沒有雜訊可以丟

說到圖像壓縮
之前不是有人把圖在大陸討論區重覆上傳
最後連原樣都看不出來

>>842344
PNG和JPG在大部分場景下並沒有“全力”去壓
非常燒CPU非常耗時
所以一般都是用個七八成功力就好
不會強求必須榨乾到每一bit

這種時候就還有繼續壓榨的餘地
像mozjpeg、optipng、zopfli、MP3packer這些
就可以利用格式標準和算法上的特性
“完全無損”地繼續進行二次優化

>>842357
百度貼吧是圖像變綠現象最常見的地方
但罪魁祸首其實是Google的一個bug
同時影響到Android和Chrome
（https://www.zhihu.com/question/29355920）