JavaFX，Alt+Num （0-127） 不同，Java 7u80（乱码）与 Java 8u202（普通 ASCII），两者都是默认聊天集 UTF-8

JavaFX, Alt+Num (0-127) different for Java 7u80 (gibberish) vs Java 8u202 (normal ASCII), both default chatset UTF-8

提问人：Jarred 提问时间：10/19/2023 最后编辑：Jarred 更新时间：10/19/2023 访问量：44

问：

我有一个ooold JavaFX项目（2015），我必须在其中添加扫描器功能。 扫描程序通常通过 ALT+Num 序列发送字符。 例如，ALT+（Num5 后跟 Num0） 生成表示 2 的字符。 点击键盘按钮也会发生相同的行为。 问题与扫描仪无关。我稍后会解释原因。 键盘布局贯穿整个测试和运行过程。

这在 Java 8 中编译时可以完美运行（oracle 存档，更新 202 下）。 但是在 Java 7（oracle 存档，更新 80）中返回奇怪的字符。 我不认识这些，也不认为是任何人类语言，也不认识 ascii（或扩展的 ascii https://www.asciitable.com/）。

  • 爪哇 8：1;2;3;4;5;6;7;8;23.266.007（正确）
  • Java 7： “ß|߇ß'ßß ̈ß+ß3/4ß|‡r| ̈ ̈rˆˆ+ （是错误的）

字符由事件过滤器 KeyEvent.KEY_TYPED、keyEvent.getCharacter（） 检索

使用 IntelliJ IDEA 编译。Win11的，

  • Java 7 的语言级别为“7 - Diamonds”。
  • 语言级别为“8 - Lambdas”的 Java 8。

JavaFX 2.2.3 与 Java7 与 Java8 有什么组合吗 这可能会将基本的 ASCII 表更改为其他内容？

我检查的第一件事是 Charset.defaultCharset（），但它为两个 java 版本返回了 UTF-8。 即使扫描仪仅用于扫描 Numbers，.（点）、/（斜杠）和 -（减号） 从 ASCII 最基本的 127 个前字符开始，所以不会受到代码页的影响吗？ 无论是通过设备扫描还是从键盘输入都无关紧要。

扫描器说明：无论 Java 版本如何，扫描器都会输入 （ALT + Num5 + Num5）。 但是在 Java 8 的情况下，正如预期的那样，它是 ASCII '7'。如果我没记错的话，在 Java7 中，它是一个“+”。 即使我使用键盘和 Alt+Num5+Num5 方法，我也会得到与扫描仪相同的字符， 对于每个 Java 版本。

我用 Java 7 和记事本窗口做了一个额外的测试。 记事本以正确的格式显示扫描的数字 12.345.678， 但是 Java 应用程序完全是胡言乱语。

感谢您的任何建议！

java-8 ascii javafx-2 java-7

评论

1赞 Holger 10/19/2023
较旧的软件版本存在问题，这些问题在较新版本中已修复，这是很正常的事情。因此，如果应用程序在古代 Java 8 中按预期工作，为什么还要关心它是否在更旧的 Java 版本中工作呢？
0赞 Jarred 10/19/2023
Projekt 在 JRE 7 上运行。将IS重新传递到当前的技术状态需要付出巨大的努力。如果只是告诉 JRE7+JavaFX2 以某种方式使用基本的 ASCII，那就太好了。
1赞 Holger 10/19/2023
到目前为止，没有人谈论“技术现状”。讨论是关于 Java 7 和 Java 8 的。所以，正确地理解它：这个项目在 Java 7 下运行，并且从第一天起就遇到了所描述的问题（现在已经八年了）？
0赞 Jarred 10/23/2023
是的，它从一开始就运行在 Java 7 上。领导层最近刚刚决定，使用扫描仪会很棒。因此，任务被委派给了我，我使用扫描仪发现了这种奇怪的行为。到目前为止，没有人尝试使用键盘键入 ALT+NUM，所以没有人知道:)
1赞 Holger 10/23/2023
明白了。但这对我来说听起来不是什么大问题。他们想要一个新功能，他们必须迁移到一个新的 Java 版本。这并不罕见。当然，找到一个相关的错误报告会很好，但谁愿意做那个考古学......

答： 暂无答案

上一个：zig 中的大写 ascii 字符

下一个：dirent 库提供的 scandir（） 与 python 的 os.scandir（） 有何不同？