附件名稱中的UTF-8字符

Question

我在他的名字中附有字符「ò」。

使用代理，我在Domino控制檯中打印這個名稱。

在我的測試服務器上，正確打印此名稱。 在生產服務器上，「ò」被替換爲「？」字符。

是否有任何服務器參數設置？

UPDATE

我會後一些代碼，以便更好地說明情況。

我有一個Notes文檔，與名稱中包含「O」字

Field Name: $FILE 
Data Type: Attached Object 
Data Length: 66 bytes 
Seq Num: 18 
Dup Item ID: 0 
Field Flags: ATTACH SIGN SEAL SUMMARY 

Object Type: File 
Object ID: 0022E992 
Object Length: 567438 
File Name: ALLEGATO A instanza fossò.pdf <----------------------- 

使用代理嵌入式安裝，我想這個附件將其複製到另一個文件。要做到這一點，我通過Ajax調用它通過一個POST，傳遞到參數附件名稱

url = '/' + $F('DbJS') +'/myagent?openagent'; 

var pars = $H({ 
    attachmentName: attachmentName 
}); 


var ajReq = new Ajax.Request (
    url, 
    { 
     method: "post", 
     parameters: pars.toQueryString(), 
     onComplete: doSomething 
    } 
); 

在Java代理，首先我得到的參數從POST調用

Vector attachmentNameVec = session.evaluate("@urldecode(\"UTF-8\";@left(@right(request_content; \"attachmentName=\");\"&\"))", doc);  
String attachmentName= (String)attachmentNameVec.elementAt(0); 
System.out.println("ATTACHMENT NAME:" + attachmentName); 

在這一點上，我試着去拿那些武器。

在測試服務器，打印調試得到：

ATTACHMENT NAME: ALLEGATO A instanza fossò.pdf 

在生產服務器上獲取：

ATTACHMENT NAME: ALLEGATO A instanza foss?.pdf 

，因此

doc.getAttachment(attachmentName) 

失敗。

信息

檢查Linux服務器confuguration，我發現這個（區域命令）：

測試服務器（正確的行爲）：

LANG=POSIX 
LC_CTYPE="POSIX" 
LC_NUMERIC="POSIX" 
LC_TIME="POSIX" 
LC_COLLATE="POSIX" 
LC_MONETARY="POSIX" 
LC_MESSAGES="POSIX" 
LC_PAPER="POSIX" 
LC_NAME="POSIX" 
LC_ADDRESS="POSIX" 
LC_TELEPHONE="POSIX" 
LC_MEASUREMENT="POSIX" 
LC_IDENTIFICATION="POSIX" 
LC_ALL= 

生產服務器（錯誤行爲）：

LANG=en_US.UTF-8 
LC_CTYPE="en_US.UTF-8" 
LC_NUMERIC="en_US.UTF-8" 
LC_TIME="en_US.UTF-8" 
LC_COLLATE="en_US.UTF-8" 
LC_MONETARY="en_US.UTF-8" 
LC_MESSAGES="en_US.UTF-8" 
LC_PAPER="en_US.UTF-8" 
LC_NAME="en_US.UTF-8" 
LC_ADDRESS="en_US.UTF-8" 
LC_TELEPHONE="en_US.UTF-8" 
LC_MEASUREMENT="en_US.UTF-8" 
LC_IDENTIFICATION="en_US.UTF-8" 
LC_ALL= 

可能取決於此？

更新2

這些結果得到以下理查德建議：

===測試服務器（右）===

UNDECODED FILE NAME->File%201%20per%20Foss%C3%B2.txt.p7m 
HEX REPRESENTATION: 46696C6525323031253230706572253230466F73732543332542322E7478742E70376D25374346696C6525323031253230706572253230466F73732543332542322E7478742E70376D 
USING PLATFORM CHARSET->File 1 per Fossò.txt.p7m 

===生產服務器（錯）===

UNDECODED FILE NAME->File%201%20per%20Foss%C3%B2.txt.p7m 
HEX REPRESENTATION: 46696C6525323031253230706572253230466F73732543332542322E7478742E70376D25374346696C6525323031253230706572253230466F73732543332542322E7478742E70376D 
USING PLATFORM CHARSET->File 1 per Foss??.txt.p7m 

正如你所看到的，相同的HEX表示。

更新3

理查德的信息請

===測試服務器（正確）===

HEX for @urldecode using UTF-8 

46696C6520312070657220466F7373F22E7478742E70376D7C 
46696C6520312070657220466F7373F22E7478742E70376D 

HEX for @urldecode using Platform 

46696C6520312070657220466F7373C3B22E7478742E70376D7C 
46696C6520312070657220466F7373C3B22E7478742E70376D 

===生產服務器（錯誤）===

HEX for @urldecode using UTF-8 

46696C6520312070657220466F73733F2E7478742E70376D7C46696C6520312070 
657220466F73733F2E7478742E70376D 

HEX for @urldecode using Platform 

46696C6520312070657220466F73733F3F2E7478742E70376D7C46696C6520312070 
657220466F73733F3F2E7478742E70376D 

Answer 1

我強烈懷疑差異實際上與語言環境有關。很明顯，更改生產服務器上的語言環境是有風險的，因爲其他事情可能會中斷，所以我不打算提出這樣的建議。相反，我認爲最好向代理添加一些額外的代碼。首先添加一條這樣的線：

Vector attachmentNameUndecodedVec = session.evaluate("@left(@right(request_content; \"attachmentName=\");\"&\")", doc); 

並打印出該值。

還聲明一個byte []數組並調用attachmentName.getBytes（） - 不指定可選的charset參數。然後將字節數組轉換爲十六進制字符串（請參閱here）並將其打印出來。這樣，不會執行額外的轉換，您將看到由於@Urldecode調用而出現的內存。我認爲您在測試和生產系統上找到的差異會告訴我們某處會發生自動字符集轉換，並且通過將字節與不同的編碼圖表進行比較，我們可能會弄清楚如何解釋它。

我還建議嘗試使用指定的「Platform」字符集來呼叫@Urldecode，以查看您到達的位置。