Java String.getBytes（“UTF-8”）不是独立于平台的吗？

我试图散列我的字符串，并得出以下代码：

import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset;
import java.security.NoSuchAlgorithmException;
import java.security.MessageDigest;
import sun.misc.BASE64Encoder;

public class JavaTest {
    public static void main (String[] args) throws UnsupportedEncodingException, NoSuchAlgorithmException {
        String rawString = "9498131529";
        System.out.println(Charset.defaultCharset());
        System.out.println(rawString);

        MessageDigest digest = MessageDigest.getInstance("MD5");
        digest.update(rawString.getBytes("UTF-8")); 
        BASE64Encoder encoder = new BASE64Encoder();
        byte hashedBytes[] = (new String(digest.digest(), "UTF-8")).getBytes();
        System.out.println(encoder.encode(hashedBytes));
    }
}

我的印象是这段代码应该是独立于平台的，因为当我试图从字符串中获取字节时，我指定了编码类型“UTF-8”

但当我在Mac、Dev环境和staging环境中运行代码时，我得到了以下结果： Mac

MacRoman
9498131529
XElaLD8UPzE/P1sWDz8/Pw==

开发人员：

登台

我的配置：

Mac

Dev

登台

我错过了什么？为什么散列算法与系统无关？我相信根据规范，MD5应该是平台独立的。我的假设错了吗

---

如果你需要更多的细节，请告诉我

为什么要通过字符串进行额外的往返？即使将“UTF-8”添加到getBytes（）中，它仍然是错误的，因为它将原始字节数组（摘要）视为UTF-8编码的字符串

将hashedBytes行更改为：

    byte hashedBytes[] = digest.digest();

---

将摘要往返于字符串（

新字符串（digest.digest（），“UTF-8”）.getBytes（）

）的步骤看起来可疑。（而且不必要——您可能应该将摘要本身base-64。）事实上，摘要可能不是有效的UTF-8，您看到的可能是不同的解码错误处理。事实上，等等，这可能正是出错的地方

.getBytes（）

不带参数以默认字符集对字符串进行编码，MacRoman和US-ASCII可能非常相似，巧合地给出了相同的结果。使用

.getBytes（“UTF-8”）

应该可以让您在任何地方都有相同的行为，但这仍然是错误的。@millimoose感谢您的输入！：）我猜Stefan比你先找到答案了。

UTF-8
9498131529
XElaLO+/vRTvv70x77+977+9WxYP77+977+977+9

> sw_vers
ProductName:    Mac OS X
ProductVersion: 10.9
BuildVersion:   13A603

> cat /proc/version
Linux version 2.6.21.7-2.fc8xen-ec2-v1.0  (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #2 SMP Tue Sep 1 10:04:29 EDT 2009

> cat /proc/version
Linux version 3.2.0-31-virtual (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #50-Ubuntu SMP Fri Sep 7 16:36:36 UTC 2012

    byte hashedBytes[] = digest.digest();