发送阿拉伯语SOAP请求至Oracle Fusion时遇输入截断错误求助

咱们一步步拆解这个问题——这个Unexpected end of input block in end tag报错几乎肯定和编码不匹配、多字节字符未转义导致的XML格式损坏，或者近期破坏了原有正常流程的环境变更有关。结合你的场景，我整理了以下排查和解决步骤：

一、先锁定编码一致性问题 #

• 验证EBS侧的字符编码输出：你提到用UTF-8编码，但得确保生成SOAP请求时，阿拉伯语字符真的被正确编码成UTF-8。比如在拼接XML（像你示例里'||r.Description||'这类动态变量）时，EBS的PL/SQL环境字符集是否正确？执行这条SQL查看EBS数据库字符集：

  SELECT userenv('NLS_CHARACTERSET') FROM dual;
  

  如果结果是AL32UTF8没问题，但如果是WE8ISO8859P1这类不支持阿拉伯语的字符集，那拼接时阿拉伯语字符已经乱码，自然会导致Fusion解析失败。
• 检查HTTP请求头的编码声明：确保发送SOAP请求时，HTTP头里的Content-Type正确设置为text/xml; charset=UTF-8。如果头里的charset和实际XML内容的编码不匹配，Fusion的XML解析器直接就会报错。

二、修复XML生成时的格式完整性 #

你的XML用了动态变量拼接，阿拉伯语字符可能包含&、<、>这类XML特殊字符，或者不可见控制字符，直接拼接会破坏XML结构：

• 对动态变量做XML转义处理：在PL/SQL里拼接XML时，必须把变量里的特殊字符转义。可以用Oracle自带的DBMS_XMLGEN.convert函数，比如：

  <loc:Description>'||DBMS_XMLGEN.convert(r.Description, 1)||'</loc:Description>
  <loc:AddressLine1>'||DBMS_XMLGEN.convert(R.ADDRESS_LINE_1, 1)||'</loc:AddressLine1>
  

  第二个参数1表示转义所有XML特殊字符，避免标签被意外截断或破坏。
• 排查字符截断问题：如果阿拉伯语字符串长度超过了EBS侧字段的定义长度，拼接时会被截断，导致XML标签不完整（比如<loc:Description>的内容没结束，标签就断了）。可以把生成的完整XML输出到日志里，检查阿拉伯语部分是否完整，有没有被截断的痕迹。

三、确认数据库字符集的影响 #

你不确定数据库是不是AL16UTF16，这一步必须搞清楚：

• 执行这条SQL确认EBS数据库的字符集：

  SELECT value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';
  

• 如果数据库是AL16UTF16（UTF-16编码），那生成UTF-8的SOAP请求时，需要把字符转成UTF-8格式，用UTL_I18N.CONVERT函数：

  <loc:Description>'||UTL_I18N.CONVERT(r.Description, 'AL32UTF8', 'AL16UTF16')||'</loc:Description>
  

四、排查近期环境变更 #

你说之前功能正常现在失效，一定要查近期的变更：

• EBS侧有没有打补丁、修改过字符集配置？
• Fusion侧的Web服务有没有版本升级、安全策略调整？
• 中间的代理、防火墙有没有更新，会不会过滤或截断多字节字符？

五、验证生成的XML有效性 #

把包含阿拉伯语的完整XML拿到XML验证工具里检查（比如W3C的XML验证器），看有没有格式错误。如果XML本身就无效（比如标签不闭合、特殊字符未转义），Fusion的解析器肯定会报类似的“输入意外结束”错误。

先从这些方向排查，应该能快速定位到问题根源。

内容的提问来源于stack exchange，提问作者mostafa khalil