我们正在尝试使用Python匹配经过Oracle MD5哈希算法的哈希。根据他们的forums，在散列之前，所有内容都在AL21UTF8中编码：
-- Prior to encryption, hashing or keyed hashing, CLOB datatype is
-- converted to AL32UTF8. This allows cryptographic data to be
-- transferred and understood between databases with different
-- character sets, across character set changes and between
-- separate processes (for example, Java programs).
--
我起初认为UTF-8足够好，但如果我这样做，我的哈希仍然不匹配。因此，在进行了额外的挖掘后，我发现了article中的Oracle's Database Companion CD installation Guide：
AL32UTF8是适用于XMLType数据的Oracle数据库字符集。它等同于IANA注册的标准UTF-8编码，该编码支持所有有效的XML字符。
不要将Oracle数据库数据库字符集UTF8（无连字符）与数据库字符集AL32UTF8或字符编码UTF-8混淆。数据库字符集UTF8已被AL32UTF8取代。不要将UTF8用于XML数据。 UTF8仅支持Unicode 3.1及更早版本;它不支持所有有效的XML字符。 AL32UTF8没有这样的限制。
所以我不能使用UTF-8，我无法弄清楚如何让Python的编解码器模块区分utf-8和utf8。如果我尝试AL32UTF8，它会抛出一个错误。有没有其他人用Python在AL32UTF8编码？
我的编解码器代码如下所示：
import codecs
sourceFmt = "ascii"
targetFmt = "utf8"
utfFile = "kesa_utf8.dat"
with codecs.open(old, "rU", sourceFmt) as sourceFile:
with codecs.open(utfFile, "w", targetFmt) as targetFile:
targetFile.write(sourceFile.read())
文件本身如下：
WC000|IC |KESA |KESA | | | |2012-07-31-15.12.36 |0090| | |\c\n
WC001|100534 |W.47212-0100534 |2012-07-31-15.12.36 | 00000000001270.00|USD|\c\n
WC002|100534 |W.47212-0100534 |Sally |H |Klass |1235 14th St. W. || |Palma Sola ||FL |USA |34209 | | | | | | | | |9412587545 | | |O | | ||20800426|645858741 |SSN | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | || | | | || | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |KESAPC | | | | | |N| | | || | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |\c\n
WC999|1000000000|1000000000|4000000000|
哈希值应为86D993FA7121E3B9EE1657A23345FE21
无论如何，我使用hashlib哈希：
import hashlib
with open(path) as f:
data = f.read()
mdhash = hashlib.md5(data)
mdhash = mdhash.hexdigest()
print mdhash
导致8421877dd9cdf7235eec47765821998c
答案 0 :(得分：0)
事实证明，无论客户端做了什么导致数据本身都以这样的方式改变，即它具有“\ c \ n”行结尾，并且它还会通过填充使文件中的行大小相同（最后的空间）他们在它们之后。一旦我们让客户端停止向我们提供不良数据，我们就能够复制哈希值。谢谢你的帮助！