公司升級ERP ，把 Oracle EBS 從 11.5.9 升到了 12.2.9 ，需要裝一堆的客戶端，由於製造型企業，老舊的電腦到處都是，客戶端安裝時碰到種種問題，小夥伴們各種度娘，基本搞定。

但是有一個子公司比較奇怪，近一半的機器有問題，就是那個FRM-92050 ，按度娘後的辦法嘗試後沒能解決問題，小夥伴們開始懷疑人生了。

為了排除瀏覽器的問題，特意安裝了低版本的FireFox ，果然收穫同樣的報錯。再回頭檢視度孃的各種各種解決方法，發現基本說是要關閉瀏覽器的XSS 過濾，那麼考慮是在客戶端出的問題。果然詳細報錯資訊給出了明確的 400 反饋。

又有極少資料提到似乎與Windows7 有關，果然這批有問題的機器都是 Windows7 的。但分析下來不得要領，嘗試把什麼 360 、電腦管家等各種安全軟體都解除安裝了， Windows 防火牆都關閉，瀏覽器的各種防護都開放，但還是沒什麼用， FRM-92050 總是神氣活現的出現在螢幕上。
靜心考慮，既然伺服器反饋說400 ，那麼肯定是客戶端的錯，至於是誰的鍋，作業系統、安全軟體還是瀏覽器，這個就要好好檢查了。但是伺服器一時摸不著，也不太想去折騰，反正絕大部分機器是正常的，說明伺服器還是靠譜的，可以信任。
所以，是祭出神器的時候了。Sniffer ，具體說是 WireShark 。一頓操作猛如虎，果然抓到狐狸尾巴了。伺服器出錯反饋前的那條客戶端請求中 4 個黑乎乎的菱形很刺眼，再瞅瞅前面似乎寫著 ifhost ，再瞅瞅後面的是 ifip 跟著客戶端的 ip 地址，於是大膽猜測這個引數應該客戶端的機器名。

回頭去檢查，果然這臺機器的名字是兩個漢字，其GBK 編碼跟 Sniffer 裡的資料是完全對上的。莫非是 GBK 惹得禍？

立刻馬上快速把機器名改成一個英文的，重啟後再登入EBS ，終於看到正常的畫面了。

題外：

鑑於度娘沒找到這種情形，其實Oracle自己的文件庫也找了，似乎也沒有。所以想寫點什麼能讓度娘知道。

再外：

沒來得及找一臺Windows7 以外的機器試試改成中文名會發生什麼事情，猜測 Windows10 大概是用 UTF 做中文編碼吧， EBS 後臺正確能處理。
也沒去檢查EBS 後端應用伺服器的 log 中是否有相關的出錯記錄，也沒問系統管理員應用伺服器能否配置成能正確處理帶 GBK 編碼的 URL 請求。

最後：
那家子公司之所以這麼多機器用中文名（人名），是因為他們都用共享的方式相互傳遞檔案，用中文方便查詢某個特定人員的機器。

Oracle EBS R12客戶端一種FRM-92050的產生原因

相關文章