33

これは本当に問題というより好奇心です...

ScannerクラスにnextChar()メソッドがないのはなぜですか? next、nextInt、nextLineなどのメソッドがあることを考えると、そうあるべきだと思われます。

次のことが簡単にできることを理解しています。

userChar = in.next().charAt(0);
System.out.println( userChar  );

しかし、なぜnextChar()方法がないのですか？

4

5 に答える 5

15

その理由は、 Scanner クラスが空白で区切られたトークンを読み取るように設計されているためです。これは、基になる入力ストリームをラップする便利なクラスです。スキャナーが登場する前は、1 バイト単位で読み取ることしかできませんでした。単語や行を読みたい場合、これは大きな苦痛でした。Scanner を使用して System.in を渡すと、多くの read() 操作が実行され、入力がトークン化されます。1 文字の読み取りは、より基本的な操作です。 ソース

使用できます(char) System.in.read();。

于 2013-09-11T16:20:46.397 に答える
4

javadocによると、aは単一の文字Scannerを読み取るためのものではないようです。aを an (または何か他のもの) にアタッチすると、入力が解析されます。不要な文字を削除することもできます。そのため、数字や行などを簡単に読み取ることができます。入力からの文字のみが必要な場合は、たとえばInputStreamReaderを使用します。ScannerInputStream

于 2013-09-11T16:19:30.003 に答える
2

決定的な理由を得るには、その API の設計者に尋ねる必要があります。

しかし、考えられる理由の 1 つは、(仮説上の) a の意図がnextCharスキャン モデルにうまく適合しないことです。

  • nextChar()のようread()に動作しReader、単に次の未使用の文字をスキャナから返す場合、他のメソッドと一貫性のない動作をしていますnext<Type>。これらは、値を解析する前に区切り文字をスキップします。

  • nextChar()(たとえば) のように振る舞う場合nextInt:

    • 区切り文字のスキップは、一部の人々にとって「予期しない」ものであり、

    • 単一の「生の」文字を受け入れるか、 a の数値表現である一連の数字を受け入れるか、charまたはエスケープなどをサポートするかという問題があります1。

どんな選択をしても、幸せになれない人もいます。私の推測では、デザイナーはターピットから離れることを決めたのです。

1 - 生のキャラクターのアプローチに強く投票します...しかし、重要なのは、分析する必要がある代替案があることなどです.

于 2013-09-11T16:35:36.290 に答える
1

エンコーディングに関係していると思います。Acharは 16 バイトで、文字に 1 バイトを使用するエンコーディングもあれば、2 つ以上を使用するエンコーディングもあります。Java が最初に設計されたとき、Unicode 文字は 2 バイトに収まると想定していましたが、現在では Unicode 文字は最大 4 バイト (UTF-32) を必要とする場合があります。Scanner単一の で UTF-32 コードポイントを表す方法はありませんchar。

インスタンスを作成するときにエンコードを指定できます。指定しScannerない場合は、プラットフォームの文字セットが使用されます。charしかし、これでも 3 バイトまたは 4 バイトの Unicode 文字の問題は処理されません。これは、単一のプリミティブとして表すことができないためcharです (16 バイトしかないため)。そのため、一貫性のない結果が得られることになります。

于 2013-09-11T16:23:23.833 に答える