对于正在进行的项目，我需要将字符串转换为字节数组，然后可以将其输入AES / CBC / PKCS5解密算法。在这种情况下，我需要采用可以完成工作的现有Java代码，并将其转换为.NET Core代码。
Java代码中的第一步是此行：
byte[] decodedBytes = Base64.getDecoder().decode( Utils.getBytes(masterKey) );
根据我在谷歌搜索时发现的内容，C＃中的这一行应该复制该功能。
var masterKeyBytes = Convert.FromBase64String(masterKey);
而且它们确实返回非常相似的字节数组。
c＃生成的数组的前10个字节为：68 163 160 50 213 109 12 103
Java生成的数组的前10个字节为：68 -93 -96 50 -43 109 12 103
因此它们非常相似，但是Java数组具有负数时，c＃数组具有相同的值，但添加了256。
这些差异是否足以引发以后的解密代码（Java中的AES / CBC / PKCS5Padding密码和.NET Core中的AES / CBC / PKCS7Padding AESManaged）我遇到的最终问题是Java代码返回解密后的值，我的.NET Core代码返回垃圾。因此，我逐行浏览代码以尝试查找输出差异，这是我遇到的第一个代码。
我无法控制Java代码，也无法对其进行编辑，因此任何解决方案都应仅在.NET Core方面进行。如果那是不可能的，我需要与我们的互联网安全人员一起启动整个流程，以更改该代码，这是我不希望看到的头疼问题。
参考方案
默认情况下，C＃中的字节是无符号的，因为它们倾向于表示原始二进制数据，而不是实际数字。如果要将字节视为带符号的数字，请使用sbyte类型。
在Java中，所有数字均默认使用带符号，由于我不知道的原因，没有其他选择（如果您有可靠的消息来源，请随时发表评论）。
通过将byte数组强制转换为sbyte数组，可以验证C＃中的值是否与Java中的值相同：
byte[] bytes = new byte[] { 68, 163, 160, 50, 213, 109, 12, 103 };
foreach (var b in bytes)
{
Console.WriteLine((sbyte) b);
}
印刷品：
68
-93
-96
50
-43
109
12
103
这与您在Java中的值相同。
如果您对将相同的8位解释为无符号或有符号值感兴趣，请阅读two's complement表示形式。
因此，这不是程序不正确的原因。进行调试，如果有其他问题，请随时询问其他问题。
CDI:使用@PostConstruct时@Inject不会失败 - java任何人都可以向我解释为什么第一种情况和第二种情况未能导致NullPointerException的原因，因为当第三种情况可以正常工作时，在b2的构造函数中b3和/或Bean1仍然为null。在所有情况下都具有此功能：@Stateless public class Bean2 { @Inject private Bean3 b3; public Bean2()…
java.net.URI.create异常 - javajava.net.URI.create("http://adserver.adtech.de/adlink|3.0") 抛出java.net.URISyntaxException: Illegal character in path at index 32: http://adserver.adtech.de/adlink|3.0 虽然n…
使用-source 8或更高版本来启用lambda表达式[重复] - javaThis question already has answers here: Specifying java version in maven - differences between properties and compiler plugin （3个答案） 去年关闭。 当我尝试运行Maven构建时遇到构建错误。我创建了一个包含lambda函数的简单J…
JAVA:字节码和二进制有什么区别？ - javajava字节代码（已编译的语言，也称为目标代码）与机器代码（当前计算机的本机代码）之间有什么区别？我读过一些书，他们将字节码称为二进制指令，但我不知道为什么。 参考方案 字节码是独立于平台的，在Windows中运行的编译器编译的字节码仍将在linux / unix / mac中运行。机器代码是特定于平台的，如果在Windows x86中编译，则它将仅在Win…
java:继承 - java有哪些替代继承的方法？ java大神给出的解决方案 有效的Java：偏重于继承而不是继承。 （这实际上也来自“四人帮”）。他提出的理由是，如果扩展类未明确设计为继承，则继承会引起很多不正常的副作用。例如，对super.someMethod()的任何调用都可以引导您通过未知代码的意外路径。取而代之的是，持有对本来应该扩展的类的引用，然后委托给它。这是与Eric…