私はこれしようとしています：奇妙なString.getByte（エンコード）
byte[] b = String.getBytes("ASCII") and get an UnsupportedEncodingException Exception
String fName = new String(b,"ASCII");
- got the same when used
byte[] b = String.getByte("ISO8859_1");
String fName = new String(b,"ISO8859_1");
編集：getByteは、コードがコンパイルされないことGetBytesメソッド
私はあなたがより多くのこのような何かしたいと思う：
import java.io.UnsupportedEncodingException;
public class Encoding
{
public static void main(String[] args) throws UnsupportedEncodingException
{
String s = "Hello world";
byte[] b = s.getBytes("US-ASCII");
}
}
つまり、@ andreas、問題はコードが**例外を投げているということではなく、例外ではありません。チェックされた例外を処理していないため、コードがコンパイルされませんでした。 –
@Alan M：どうやってその結論を導きましたか？コードはコンパイルされないとの質問はどこにありますか？ Andreasは、例外を「取得」しますが、実行時でもコンパイル時でもありません。 –
に変更 - それはString.getBytes()ないString.getByte()だし、それはインスタンスメソッドではありませんが静的メソッド。あなたが働いている実際のの例を切り取って貼り付けるだけの価値があります（ダミーのアプリでも）。
Charset JavaDocに記載されているようしかし、あなたはがコンパイルで同様のコードを持っていると仮定すると、あなたは、名前として"US-ASCII"と"ISO-8859-1"を使用する必要があります。
according to javadoc："US-ASCII"
this still unresolved bugを注目に値するもののを...
「実際の動作 VERSUS EXPECTED ：
奇妙なパフォーマンスの低下"US-ASCII"のエンコーディング を "ASCII"のエンコーディングと比較して使用すると、これら二つのエンコーディングのために、この コードを実行する際に、開発者は、このような 乱暴に異なるパフォーマンスプロファイルを期待すべき理由 絶対に理由はありません。」
はコメントトムのおかげで、確かに価値がない "何もない"。それに見えるだろう:) – Andreas
について**チェックされているどのようなOSあなたが質問 – akf
上で実行されています例外** – Andreas
のWindows XP上で実行している？ – dfa