从int到char和ASCII值的类型转换 [英] Typecasting from int to char and ASCII values

问题描述

int a1 = 65535;

char ch2 = (char) a1;

System.out.println("ASCII value corresponding to 65535 after being typecasted : "+ch2);// prints?
char ch3 = 65535;
System.out.println("ASCII value corresponding to 65535 : "+ch3);// again prints?

我引用Herbert Schildt第3章：数据类型，变量和数组：

I quote from Herbert Schildt Chapter 3 : Data types, Variables and Arrays :

char的范围是0到65535.没有负的字符。名为ASCII的
标准字符集一如既往地保持在0到127
之间，扩展的8位字符集ISO-Latin-1从0到255的范围是
。由于Java旨在允许程序在全球范围内使用
编写，因此使用Unicode来表示
代表字符是有道理的。
只要一个整数在范围内，也可以为整数赋值。

The range of a char is 0 to 65535. There are no negative chars. The standard set of characters known as ASCII still ranges from 0 to 127 as always, and the extended 8-bit character set, ISO-Latin-1, ranges from 0 to 255. Since Java is designed to allow programs to be written for worldwide use, it makes sense that it would use Unicode to represent characters. An integer can also be assigned to a char as long as it is within range.

//char ch33 = 65536; compilation-error, ofcourse since out of char range (which is 0 - 65535)

int a11 = 65536;  
  char ch22 = (char) a11;   
System.out.println("ASCII value corresponding to 65536 after being typecasted : "+ch22);
  // non-printing character(appearance of a small square like figure in eclipse console)

问题是：为什么此行的没有编译错误： char ch22 =（char）a11 ，即使 char ch33 = 65536 不起作用？还有一件事，当 int a1 = 65535 被采取时，情况并非如此？

The question is: why is there no compilation error for this line: char ch22 = (char) a11, even though char ch33 = 65536 does not works? One more thing, this was not the case when int a1 = 65535 was taken?

推荐答案

好的，那里有几个截然不同的问题。

Okay, you have a couple of quite distinct questions there.

我认为第一个问题是：

因为你'重新输出无效字符。 Java字符代表UTF-16代码点，而不是实际的字符。一些Unicode字符（UTF-16）需要两个 Java char 来存储。有关UTF-16 此处的Unicode常见问题解答的更多信息。在UTF-16中，值 0xFFFF （这是你的 ch2 和 ch3 contains）作为独立值无效;即使它是，也没有Unicode U + FFFF字符。

Because you're outputting an invalid character. Java characters represent UTF-16 code points, not actual characters. Some Unicode characters, in UTF-16, require two Java chars for storage. More about UTF-16 here in the Unicode FAQ. In UTF-16, the value 0xFFFF (which is what your ch2 and ch3 contain) is not valid as a standalone value; even if it were, there is no Unicode U+FFFF character.

重新输出 ch22 ：你看到一个小盒子的原因是你'重新输出字符 0 （（字符）65536 的结果是 0 ，见下文），这是一个控制角色（所有字符都低于32 —正常空格字符 —是各种控制字符）。字符 0 是null字符，对于该字符，我没有普遍接受的字形。

Re the output of ch22: The reason you're seeing a little box is that you're outputting character 0 (the result of (char)65536 is 0, see below), which is a "control character" (all the characters below 32 — the normal space character — are various control characters). Character 0 is the "null" character, for which there's no generally-accepted glyph that I'm aware of.

因为这就是Java的缩小基元转换。没有错误;相反，只使用相关的位：

Because that's how Java's narrowing primitive conversions are defined. No error is thrown; instead, only the relevant bits are used:

将有符号整数的变窄转换为整数类型T只会丢弃除n之外的所有值顺序位，其中n是用于表示类型T的位数。除了可能丢失有关数值大小的信息之外，这可能导致结果值的符号与输入值的符号不同。

A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T. In addition to a possible loss of information about the magnitude of the numeric value, this may cause the sign of the resulting value to differ from the sign of the input value.

这篇关于从int到char和ASCII值的类型转换的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！