Oracle SQL生成埃及电子收据UUID：SHA256哈希差异及步骤疑问

对接埃及电子发票（EInvoicing）、电子收据（EReceipt）系统，按官方步骤生成收据UUID，已完成步骤1-4，第5步通过Oracle SQL生成SHA256哈希值，但遇到两个问题：

疑问1：步骤6的转换要求是否多余？ #

官方步骤6要求“将32字节的哈希值转换为64字符的十六进制字符串”，但执行STANDARD_HASH后直接得到64字符结果。

解答：
该步骤是通用流程，针对的是那些生成原始二进制哈希值（32字节字节数组）的场景（比如部分编程语言的哈希函数默认返回二进制数据）。而Oracle的STANDARD_HASH函数已经内置了“二进制哈希转十六进制字符串”的逻辑，返回的结果就是64字符的十六进制字符串，因此对你来说这一步已经自动完成，无需额外操作。

疑问2：哈希结果与官方预期不符，如何调整SQL？ #

当前执行SQL得到的结果为E1F20DB1DB2C79B84C823CFB0F9B8C89BF3FAD367CD732CEFB3E9AEAFD2E3F8B，但官方预期结果是65e952fae3e93f64441433bb72eaa6d4d038945fc132e6e8ae3d3444c5d26a50，结果不匹配。

调整方案：
问题核心是字符串编码和哈希函数的字符集依赖，需确保按UTF-8编码处理字符串，同时明确指定哈希算法。调整后的SQL如下：

SELECT LOWER(
  RAWTOHEX(
    DBMS_CRYPTO.HASH(
      UTL_I18N.STRING_TO_RAW('"HEADER""DATETIMEISSUED""2023-05-25T00:34:00Z""RECEIPTNUMBER""001""UUID""""PREVIOUSUUID""""REFERENCEOLDUUID""""CURRENCY""EGP""EXCHANGERATE""0""SORDERNAMECODE""sOrderNameCode""ORDERDELIVERYMODE""""GROSSWEIGHT""6.58""NETWEIGHT""6.89""DOCUMENTTYPE""RECEIPTTYPE""S""TYPEVERSION""1.2""SELLER""RIN""100334776""COMPANYTRADENAME""Minapharm""BRANCHCODE""0""BRANCHADDRESS""COUNTRY""EG""GOVERNATE""cairo""REGIONCITY""city center""STREET""16 street""BUILDINGNUMBER""14BN""POSTALCODE""74235""FLOOR""1F""ROOM""3R""LANDMARK""tahrir square""ADDITIONALINFORMATION""talaat harb street""DEVICESERIALNUMBER""Sofy123""SYNDICATELICENSENUMBER""1000056""ACTIVITYCODE""4620""BUYER""TYPE""F""ID""313717919""NAME""taxpayer 1""MOBILENUMBER""+201020567462""PAYMENTNUMBER""987654""ITEMDATA""ITEMDATA""INTERNALCODE""880609""DESCRIPTION""Samsung A02 32GB_LTE_BLACK_DS_SM-A022FZKDMEB_A022 _ A022_SM-A022FZKDMEB""ITEMTYPE""GS1""ITEMCODE""037000401629""UNITTYPE""EA""QUANTITY""35""UNITPRICE""247.96000""NETSALE""7810.74000""TOTALSALE""8678.60000""TOTAL""8887.04360""COMMERCIALDISCOUNTDATA""COMMERCIALDISCOUNTDATA""AMOUNT""867.86000""DESCRIPTION""XYZ""ITEMDISCOUNTDATA""ITEMDISCOUNTDATA""AMOUNT""10""DESCRIPTION""ABC""ITEMDISCOUNTDATA""AMOUNT""10""DESCRIPTION""XYZ""VALUEDIFFERENCE""20""TAXABLEITEMS""TAXABLEITEMS""TAXTYPE""T1""AMOUNT""1096.30360""SUBTYPE""V009""RATE""14""TOTALSALES""8678.60000""TOTALCOMMERCIALDISCOUNT""867.86000""TOTALITEMSDISCOUNT""20""EXTRARECEIPTDISCOUNTDATA""EXTRARECEIPTDISCOUNTDATA""AMOUNT""0""DESCRIPTION""ABC""NETAMOUNT""7810.74000""FEESAMOUNT""0""TOTALAMOUNT""8887.04360""TAXTOTALS""TAXTOTALS""TAXTYPE""T1""AMOUNT""1096.30360""PAYMENTMETHOD""C""ADJUSTMENT""0""CONTRACTOR""NAME""contractor1""AMOUNT""2.563""RATE""2.3""BENEFICIARY""AMOUNT""20.569""RATE""2.147', 'AL32UTF8'),
      DBMS_CRYPTO.HASH_SH256
    )
  )
) AS receipt_uuid
FROM DUAL;

关键调整点：

1. 编码统一：用UTL_I18N.STRING_TO_RAW将字符串转为UTF-8编码的RAW类型，确保与官方要求的编码一致
2. 明确哈希算法：用DBMS_CRYPTO.HASH指定SHA256算法，避免STANDARD_HASH因数据库字符集差异导致的结果偏差
3. 大小写匹配：用LOWER将结果转为小写，与官方预期的十六进制字符串格式一致
4. 文本格式校验：确认拼接的规范化文本完全符合官方要求的字段顺序、引号格式及空值处理，无多余或缺失内容

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