附件名称中的UTF-8字符

我对他名字中的“ò”字有一段感情

我使用代理在Domino控制台中打印这个名称

在我的测试服务器上，此名称已正确打印。 在生产服务器上，“ò”替换为“？”字符

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

更新

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

我有一个notes文档，带有一个嵌入附件，其名称包含“ò”字符

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

在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服务器配置时，我注意到（locale命令）：

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

生产服务器（行为错误）：

你能相信吗

更新2

以下是根据Richard建议获得的结果：

==测试服务器（右）===

==生产服务器（错误）===

正如您所看到的，相同的十六进制表示法

更新3

Richard，所要求的信息

==测试服务器（正确）===

==生产服务器（错误）===

---

我强烈怀疑这种差异实际上与地区有关。显然，更改生产服务器上的区域设置是有风险的，因为其他事情可能会中断，所以我不建议这样做。相反，我认为最好向代理添加一些附加代码。首先，添加一行如下所示：

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

并打印出该值

还声明一个byte[]数组并调用attachmentName.getBytes（）--而不指定可选的字符集参数。然后将字节数组转换为十六进制字符串（请参阅），并将其打印出来。这样，就不会进行额外的转换，并且您将确切地看到@Urldecode调用的结果是内存中的内容。我认为，您在测试系统和生产系统上发现的差异将告诉我们，自动字符集转换正在某处发生，通过将字节与不同的编码图表进行比较，我们可能能够找出如何解释它

---

我还建议尝试使用指定的“Platform”字符集调用@Urldecode，以查看您在那里得到了什么。

服务器的详细信息是什么？窗户？Linux？哪个版本号，哪个语言？Domino的哪个版本？您正在查看实际服务器上的本机控制台、Domino管理员客户端中的远程控制台还是Java服务器控制器中的控制台？那日志呢？如果您从自己的Notes客户端打开两台服务器的日志，字符是否在这两台服务器的日志中正确呈现？Linux服务器，在8.5.1FP2和8.5.3FP4（英语）上有经验。我在看Domino管理器中的控制台，两台服务器都是相同的Linux、相同的版本、相同的操作系统语言和安装的Domino语言？您正在同一个Domino管理员客户端上查看两个控制台吗？从代理内部的内存到您查看的实际屏幕，过程中的每一步都会引入错误字符转换的可能性。如果你得到不同的结果，那么在某个地方的环境是不同的。顺便说一句，它不是一个“UTF-8”字符。这只是一个角色。LotusScript和Java代理的本机字符集是Unicode UTF-16，但出于显示目的，输出通常转换为“平台本机”字符集。对于许多服务器，例如英语Windows，平台本机字符集也是UTF-16，但我遇到过Domino服务器（我认为它们在Windows上），其中平台本机字符集是日语字符集之一，这暴露了我的一些Java代理代码中的一个bug，该代码在getBytes调用中使用默认的平台转换。谢谢Richard！不是相同的服务器（如我所说，8,5,3和8.5.1），而是相同的管理客户端。目的是按名称获取附件，并附加到另一个文档。在某些情况下是正确的，在另一种情况下是不正确的（“ò”字符未“解析”，因此附件获取失败！）这就是情况。我所说的控制台是指一个“System.out.println（attachName）”，我打印它是为了看看会发生什么。这就是为什么我说服务器配置中可能有一些东西（但我不知道是什么…）。希望解释清楚。理查德，在更新2测试结果。好的。您打印的十六进制似乎是针对attachmentNameUndecoded的。我实际上希望看到attachmentName的十六进制——在调用了使用“UTF-8”参数进行UrlDecode的原始代码，以及使用“platform”参数进行UrlDecode解码的版本的十六进制之后。我想我没有说清楚。对不起！：-）抱歉，理查德耽搁了。在更新3中，提供了所需的信息。短暂性脑缺血发作

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=

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

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