最近，需要移植faster-rcnn的detect部分到android平臺上，為方便刪減程式碼與除錯，需要跨平臺相容到windows下執行，windows下除錯的時候，用的是linux下的模型定義proto與訓練好的二進位制模型，但是，一直載入模型不成功，逐步解決方法如下：

（1）核對protobuf版本，均為2.5.0，不可能是因為版本不相容所致；

（2）核對cafe.proto，這個檔案在linux和windows下是相同的，編譯出來的caffe.pb.h與caffe.pb.h.cc幾乎完全相同（除個別處0填充外），因此不可能是proto定義不同引起的失敗；

無奈，只能除錯protobuf中的程式碼，逐步跟進：

（3）編譯windows下protobuf程式碼（debug版本），注意protoc同時編譯更新，並除錯caffe的模型載入，發現問題如下：

具體表現為：讀取模型buffer時，只讀取很少部分便檔案終止，因此，不能成功初始化每個layer的引數，問題出現在open/read檔案操作函式，

actual-read-size = open(file-descriptor,  buf-ptr, need-size)，其中need-size預設patch size = 8192，讀取到的actual-read-size為82， 遠遠沒有讀取完畢，懷疑是遇到了終止符；

用UltraEdit檢視二進位制模型，如下：

注意紅色圓圈部分，為第83個字元， 1A對應的ASCII碼為SUB，而在windows下，SUB是一種文字檔案讀取終止符，因此，讀取模型buffer提前終止，所以失敗，

1A對應的十進位制整數為26， protobuf在save以及parse caffe model的時候（取決於caffe.pb.cc， 不同的網路對應的二進位制模型可能出現26， 也可能不出現26，複雜程度不同而已），會插入tag作為分隔不同值域的標識，tag中出現了26， 即windows下的sub終止標識；

（4）為何會在二進位制中出現sub？

按道理來說，都是二進位制位元組流。這就是windows下open/read存在的問題， 同時也是windows與linux處理二進位制檔案盒文字檔案的方式不同。

(a) windows區分文字檔案與二進位制檔案，linux下則不區分（均為位元組流）；

（b）open/read（系統函式）與fopen/fread（C語言API）是不同的，除了緩衝機制外（此處的緩衝機制與我們的問題無關），

在windows下，fopen可以指定“rb”二進位制讀取方式開啟，read則需要聯合O_RDONLY|O_BINARY使用，讀取二進位制模型。

而在linux， 只有O_RDONLY，無O_BINARY,， O_RDONLY一般定義在/usr/include/bits/fcntl.h------->fcntl-linux.h 中， 即便存在O_BINARY的話，對於開啟讀取二進位制模型來說，O_RDONLY與O_RDONLY|O_BINARY是無差別的，fopen(file, "rb")與fopen(file, "r")也是無差別的；

那麼，在caffe的src/util/io.cpp檔案的ReadProtoFromBinaryFile函式中便存在一個小bug， 使得，caffe在windows下載入linux下訓練的模型成為一種不可跨平臺性（狹義的），

修正如下：

#ifdef _WIN32
  int fd = open(filename, O_RDONLY|O_BINARY);
#else
  int fd = open(filename, O_RDONLY);
#endif

當然，caffe原始碼中均未出現O_BINARY,需要在用到出現錯誤的同時，想到這點不同，並對應修正編譯（本處caffe版本為faster-rcnn python版中對應的caffe分支， 請檢查caffe最新分支是否更正過此所謂的bug（自定義bug  ^_^））。