最近做的乙個專案需要上傳比較多的到伺服器，伺服器限制大小是2m，在專案中，的大小都是有控制的，為100k；
在互動中，返回給我"http status 413" 上傳實體過大，超過伺服器大小。
這讓我很糾結，我傳給伺服器的是二進位製流 bytearray
然後想當然的去計算，上傳的在10張以內，每張大小都為 56k , 56*10不足1m。
怎麼會返回實體過大呢？
後來檢查程式以後，才發現，原來我上傳的二進位製流，不是在開啟時候載入進來的源，而是通過轉換的。這也就是bytearray的效率。
網上找過乙個bitampdata 和 bytearray 轉換的例子:
這位仁兄說:
乙個1024*1024大小的bitmapdata，通過此方式轉換為bytearray並儲存在sharedobject中有4m之巨！其實手工算一下也應如此：1024*1024*4/1024/1024 = 4
按這樣倍數算的話 我上傳的集就已經超過2m了; 還是不怎麼相信 果然 在最後將每張都去儲存後，得到的大小等於原圖的3倍以上；
所以呢 在應用中 後台需要的資料是源 而不需要變化以後的資料 可以直接在得到源的時候儲存二進位製流 這樣不會改變大小而產生我這個問題了
隨便侃侃 不貼**了
令人蛋疼的編碼問題
亂碼問題解決方法就是一句話 借助中間萬能編碼unicode進行編碼之間的轉換操作。為什麼這麼說？因為unicode與萬國的編碼都一種對映關係 gbk為了完美相容ascii碼，在萬國碼對映表中提出了高位元組的概念 就是在對映中凡是超過127的字元都認為是中文 eg 8 4 2 1 8 4 2 1 1 ...
iPhone開發 令人蛋疼的問題
執行出現如下錯誤 undefined symbols for architecture i386 objc class viewcontroller referenced from ld symbol s not found for architecture i386 clang error lin...
總結我那令人「蛋疼」的2011
先介紹下自己 免貴姓gao。現就職於山東日照的一家網路科技公司，從事 開發的工作。2011年3月22號，我和我的舍友離開了學校，來到這家公司，進行了令人緊張而又出乎意料的面試。緊張？是因為第一次參加正式的面試。出乎意料？面試官 我們現在的經理 就問了我們幾個非專業問題之後通過了。後來才知道，這家公司...