Question

我的名字中附有字符“ò”。

使用代理，我在Domino控制台中打印此名称。

在我的测试服务器上，正确打印此名称。在生产服务器上，“ò”被“？”取代字符。

是否要设置任何服务器参数？

更新

我会发布一些代码来更好地解释这种情况。

我有一个备注文档，其中包含一个名为“ò”字符的嵌入式附件

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   <-----------------------

使用代理，我希望获得此附件以将其复制到另一个文档中。为此，我通过POST通过Ajax调用它，将参数名称传递给参数

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);

此时，我试图获得附件。

在测试服务器上，打印调试get：

 ATTACHMENT NAME: ALLEGATO A instanza fossò.pdf

在生产服务器上获取：

 ATTACHMENT NAME: ALLEGATO A instanza foss?.pdf

因此

doc.getAttachment(attachmentName)

失败。

信息

检查Linux服务器的配置情况，我注意到了这一点（ locale 命令）：

测试服务器（正确行为）：

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调用后内存中的内容。我认为您在测试和生产系统上找到的内容之间的差异将向我们展示自动字符集转换正在某处发生，通过将字节与不同的编码图表进行比较，我们可以找出如何解释它。 / p>

我还建议尝试使用＆＃34;平台＆＃34;调用@Urldecode。 charset指定看你到那里。

附件名称中的UTF-8字符

1 个答案: