0

私はUTF-8エンコーディングを処理するものに取り組んでおり、次の質問をしていることに気付きました:

  • UTF-8エンコードされた文字列内で決して発生しないバイトに遭遇した場合、どうすればよい ですか?

すなわち0x1111111X

たとえば、バイト ストリーム内の現在の場所を調べて、ストリーム内のその場所のコード ポイントを表すために使用されているバイト数を示す小さなコード スニペットを書いています。

  • 0x0XXXXXXXちょうど1
  • 0x10XXXXXXおっと、私たちは継続バイトにいます。上流を検索して先頭のバイトを見つけます
  • 0x11XXXXXX先頭の 1 の数を数えます。それが答えです
  • 0x1111111Xエラー、これはできませんUTF-8!!! 何をすべきか！？！？

エラー値を返すことを考えていますが、副作用として、より予測可能なエラーグリフ (グリフを表すコードポイントを意味します) に置き換える必要があるかどうか疑問に思っています。そして後で、文字列をジャンプして、先頭のバイトにその後の継続バイトの正しい数がないことがわかったなど、もっと複雑なことをすると...私もそれを「修正」する必要があると考えています。

間違ってエンコードされた文字列を壊れたままにしておくこと、またはそれらを変更して間違ったものにすることは標準的な慣行ですか?

4

1 に答える 1

0

最も一般的な方法は、入力が正しくない場合に意味のあるエラーをスローして停止することです。

そうするのには多くの正当な理由があります：

  • 速度: エラーを修正しようとすると、入力が正しい場合でも関数が遅くなることがよくあります
  • シンプルさ: エラーを修正しようとすると、コードが非常に複雑になる可能性があります
  • 保守性と正確性: 入力が作業中の仕様と一致しない場合に停止したときに、関数が正しく機能することを確認する方が簡単です。仕様通りに入力をチェックすればいいので。

  • 目的: このようなポイントに到達するたびに、次のことを考える必要があります: 関数の目的は何ですか? なぜ私はそれを書くという考えを思いついたのですか？

    また、uft8を修正する関数fixcodeは他の場所でも使用できるため、修正を分離することは完全に理にかなっています（目的、単純さ、保守性、および正確性の議論）。

    エラーが予想される場合でも、外部コンテキストで修正コードを再利用できるため、エンコードと修正コードを分離することをお勧めします。

エンコード中に utf8 コードを修正することを本当に考えている場合は、次のようなパターンを使用します。

try {
  q = encode(s);
} catch(encodingerror) {
  log(encodingerror);
  t = fixcode(s);
  q = encode(t);
}
于 2013-02-15T09:37:53.627 に答える