QA@IT
«回答へ戻る

5599
 
 あと確認してないので間違ってるかもしれませんが、
 reader.closeの後に再オープン出来るかどうかが気になります。
+
+---
+
+charsetの件は、html 4だとそのままで正しいですね。失礼しました。html 5の charset属性しか考えてませんでした。

例外であるUnsupportedEncodingExceptionの意味するところは単純に
「サポートされていないエンコード」です。

つまりは第二引数のnextEncodingの文字列が、エンコードとして正しくないということです。
方法が正しいかどうかの前の話ですね。わかりにくい例外もありますが例外が報告してくれている内容に注目しましょう。

現状ではcharset属性から文字を抽出するときに+8としているから最初の二重引用符が入ってしまっているのが一因な気がしますが(多分+9が正しいんじゃないかな)、
そもそもjavaとHTMLのcharsetで指定できる文字列が同じなのか、
それ以外にも単一引用符だった場合や引用符が省略されていた場合charsetが無い場合なども想定しないといけません。

最初から全部は対応できないですが、取れなかった時にどうするか(ログ出すとかエラーにするとか)
は何かしかけておかないと、エラーが区別できなくなると思いますよ。

あと確認してないので間違ってるかもしれませんが、
reader.closeの後に再オープン出来るかどうかが気になります。


charsetの件は、html 4だとそのままで正しいですね。失礼しました。html 5の charset属性しか考えてませんでした。

例外であるUnsupportedEncodingExceptionの意味するところは単純に
「サポートされていないエンコード」です。

つまりは第二引数のnextEncodingの文字列が、エンコードとして正しくないということです。
方法が正しいかどうかの前の話ですね。わかりにくい例外もありますが例外が報告してくれている内容に注目しましょう。

現状ではcharset属性から文字を抽出するときに+8としているから最初の二重引用符が入ってしまっているのが一因な気がしますが(多分+9が正しいんじゃないかな)、
そもそもjavaとHTMLのcharsetで指定できる文字列が同じなのか、
それ以外にも単一引用符だった場合や引用符が省略されていた場合charsetが無い場合なども想定しないといけません。

最初から全部は対応できないですが、取れなかった時にどうするか(ログ出すとかエラーにするとか)
は何かしかけておかないと、エラーが区別できなくなると思いますよ。

あと確認してないので間違ってるかもしれませんが、
reader.closeの後に再オープン出来るかどうかが気になります。

---

charsetの件は、html 4だとそのままで正しいですね。失礼しました。html 5の charset属性しか考えてませんでした。

5599
 「サポートされていないエンコード」です。
 
 つまりは第二引数のnextEncodingの文字列が、エンコードとして正しくないということです。
+方法が正しいかどうかの前の話ですね。わかりにくい例外もありますが例外が報告してくれている内容に注目しましょう。
 
-
 現状ではcharset属性から文字を抽出するときに+8としているから最初の二重引用符が入ってしまっているのが一因な気がしますが(多分+9が正しいんじゃないかな)、
 そもそもjavaとHTMLのcharsetで指定できる文字列が同じなのか、
 それ以外にも単一引用符だった場合や引用符が省略されていた場合charsetが無い場合なども想定しないといけません。
 
-最初から全部は対応できないとしても、取れなかった時にどうするか(ログ出すとかエラーにするとか)
+最初から全部は対応できないですが、取れなかった時にどうするか(ログ出すとかエラーにするとか)
 は何かしかけておかないと、エラーが区別できなくなると思いますよ。
 
 あと確認してないので間違ってるかもしれませんが、

例外であるUnsupportedEncodingExceptionの意味するところは単純に
「サポートされていないエンコード」です。

つまりは第二引数のnextEncodingの文字列が、エンコードとして正しくないということです。
方法が正しいかどうかの前の話ですね。わかりにくい例外もありますが例外が報告してくれている内容に注目しましょう。

現状ではcharset属性から文字を抽出するときに+8としているから最初の二重引用符が入ってしまっているのが一因な気がしますが(多分+9が正しいんじゃないかな)、
そもそもjavaとHTMLのcharsetで指定できる文字列が同じなのか、
それ以外にも単一引用符だった場合や引用符が省略されていた場合charsetが無い場合なども想定しないといけません。

最初から全部は対応できないですが、取れなかった時にどうするか(ログ出すとかエラーにするとか)
は何かしかけておかないと、エラーが区別できなくなると思いますよ。

あと確認してないので間違ってるかもしれませんが、
reader.closeの後に再オープン出来るかどうかが気になります。

例外であるUnsupportedEncodingExceptionの意味するところは単純に
「サポートされていないエンコード」です。

つまりは第二引数のnextEncodingの文字列が、エンコードとして正しくないということです。
方法が正しいかどうかの前の話ですね。わかりにくい例外もありますが例外が報告してくれている内容に注目しましょう。

現状ではcharset属性から文字を抽出するときに+8としているから最初の二重引用符が入ってしまっているのが一因な気がしますが(多分+9が正しいんじゃないかな)、
そもそもjavaとHTMLのcharsetで指定できる文字列が同じなのか、
それ以外にも単一引用符だった場合や引用符が省略されていた場合charsetが無い場合なども想定しないといけません。

最初から全部は対応できないですが、取れなかった時にどうするか(ログ出すとかエラーにするとか)
は何かしかけておかないと、エラーが区別できなくなると思いますよ。

あと確認してないので間違ってるかもしれませんが、
reader.closeの後に再オープン出来るかどうかが気になります。

回答を投稿

例外であるUnsupportedEncodingExceptionの意味するところは単純に
「サポートされていないエンコード」です。

つまりは第二引数のnextEncodingの文字列が、エンコードとして正しくないということです。

現状ではcharset属性から文字を抽出するときに+8としているから最初の二重引用符が入ってしまっているのが一因な気がしますが(多分+9が正しいんじゃないかな)、
そもそもjavaとHTMLのcharsetで指定できる文字列が同じなのか、
それ以外にも単一引用符だった場合や引用符が省略されていた場合charsetが無い場合なども想定しないといけません。

最初から全部は対応できないとしても、取れなかった時にどうするか(ログ出すとかエラーにするとか)
は何かしかけておかないと、エラーが区別できなくなると思いますよ。

あと確認してないので間違ってるかもしれませんが、
reader.closeの後に再オープン出来るかどうかが気になります。

例外であるUnsupportedEncodingExceptionの意味するところは単純に
「サポートされていないエンコード」です。

つまりは第二引数のnextEncodingの文字列が、エンコードとして正しくないということです。


現状ではcharset属性から文字を抽出するときに+8としているから最初の二重引用符が入ってしまっているのが一因な気がしますが(多分+9が正しいんじゃないかな)、
そもそもjavaとHTMLのcharsetで指定できる文字列が同じなのか、
それ以外にも単一引用符だった場合や引用符が省略されていた場合charsetが無い場合なども想定しないといけません。

最初から全部は対応できないとしても、取れなかった時にどうするか(ログ出すとかエラーにするとか)
は何かしかけておかないと、エラーが区別できなくなると思いますよ。

あと確認してないので間違ってるかもしれませんが、
reader.closeの後に再オープン出来るかどうかが気になります。