我在Lotus-Domino中有一个Java WebAgent，它通过OpenURL命令（https://link.com/db.nsf/agentName?openagent）运行。创建此代理是为了接收带有XML内容的POST。在甚至解析或保存（XML）内容之前，Web代理将内容保存到内存文档中：
对于使用OpenAgent URL命令从浏览器运行的代理，内存中文档是一个新文档，其中包含Domino®支持的每个CGI（通用网关接口）变量的项目。每个项目都有受支持的CGI变量的名称和当前值。（您无需进行任何设计工作； CGI变量将自动可用。）https://www.ibm.com/support/knowledgecenter/zh-CN/SSVRGU_9.0.1/basic/H_DOCUMENTCONTEXT_PROPERTY_JAVA.html
POST的内容将（由Lotus）保存到该request_content字段中。接收带有以下字符的内容时：é，例如：
<Name xml:lang="en">tést</Name>
Lotus将é更改为？®。这也是我在读取request_content文档属性中的字段时看到的。是否可以将é另存为é，而不是a ：?在Lotus中？
解决方案：
我修复它的方法是通过这篇文章：
解决方案但是在Java中：
/****** INITIALIZATION ******/
session = getSession();
AgentContext agentContext = session.getAgentContext();
Stream stream = session.createStream();
stream.open("C:\\Temp\\test.txt", "LMBCS");
stream.writeText(agentContext.getDocumentContext().getItemValueString("REQUEST_CONTENT"));
stream.close();
stream.open("C:\\Temp\\test.txt", "UTF-8");
String Content = stream.readText();
stream.close();
System.out.println("Content: " + Content);
我之前已经处理过，但是我不再有权访问代码，因此必须从内存中进行工作。
这看起来像是UTF-8与UTF-16的问题，但是最多可以使用五个字符集：执行POST的代码中使用的字符集，运行代理的JVM的字符集， Domino服务器代码，NSF的字符集（始终为LMBCS）以及Domino服务器的主机OS的字符集。
如果我没记错的话，REQUEST_CONTENT将被视为原始数据，而不是字符数据。为了正确处理，您必须自己处理REQUEST_CONTENT的转换。
用于在Java代理中保存数据的Notes API调用将自动从Unicode转换为LMBCS，反之亦然，但这仅在Java正确解释了传入数据流的情况下有效。我认为在大多数情况下，在Domino下运行的JVM是针对UTF-16配置的-尽管事实并非如此。（我记得日本一台服务器的问题，其中一个字符集是JIS标准字符集之一，但是我不记得它是否在JVM中。）
因此，如果我没记错的话，您需要使用来将REQUEST_CONTENT作为UTF-8从String读入字节数组getBytes("UTF-8")，然后使用来从字节数组构造新的String new String(byte[] bytes, "UTF-16")。假设然后将那个字符串传递给，NotesDocument.ReplaceItemValue()那么Notes API调用应该正确地解释它。
我可能在这里有一些细节错误。有一阵子了。我很久以前建立了一个数据库，该数据库显示了多年前所有Unicode字符的LMBCS，UTF-8和UTF-16值。如果您可以深入了解字节值，那么它可以是查看此类数据并弄清实际情况的有用工具。这是从这里下载OpenNTF。在这种情况下，我回想起编写了获取字节数组并将其转换为十六进制并将其写入NotesItem的代码，以便我可以准确地看到即将出现的内容并将其与数据库条目进行比较。
而且，是的，根据评论，如果让双方的XML工具都可以处理字符集问题和编码，那就更好了，但这并不总是万无一失的。您将在流程中添加另一层字符集！您必须正确处理。如果目标是将数据存储在NotesItems中，则仍然必须确保服务器端XML工具解码为正确的字符集，这可能不是默认的字符集。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句