0

私はCSSにコンパイルされる一連の言語の解析/トークン化に取り組んでおり、非ASCII入力をどのように処理するかについて行き詰まっています。明らかに、多くの人がこれまでこれに対処したことがあります。

一般的な経験則として、私は「UTF-8に変換し、処理して、入力として使用したエンコードに変換し直す」と読み続けています。私はそのアプローチに同意する傾向があります...

しかし、私が直接使用する句読点と数字はすべてASCII（コードポイントが127未満）であり、他の文字列はすべてハッシュテーブルに詰め込まれます（つまり、プログラムはすべきではありません）。特定の文字を表現するために必要なバイト数に注意してください）。

ここに質問があります：

  • 興味のあるコードポイント（すべて127未満）のASCII定義と競合する正式な文字セットはありますか？

  • 直接処理しないすべての文字に一致させ、ワイド文字UTF-8エンコードデコードの大失敗全体をスキップするために、big oleの文字範囲を設定する際の明らかなエラーを確認できますか？

例えば：

//A-Z, a-z and all the non-ASCII stuff
character = (0x41..0x5A) || (0x61..0x7A) || (0x80..0xFF)

//match 1 or more
identifier = character+

本当にありがとう！

4

2 に答える 2

1

忘却型のエンコーディング（PHPなど）を使用する場合は、UTF-16 IEのような入力エンコーディングをサポートできません。エンコーディングは、ビット単位でASCII互換である必要があります。文字セットのASCII互換性と混同しないでください。

データが通過するだけなので、忘却型のエンコードはうまく機能します。他の方法で文字コンテンツを処理する必要がある場合は、毎回デコードする必要があるため、最初に1回デコードすることをお勧めします。

UTF-8のコンテンツをエンコードせず（したがって、デコード、宣言、検出、およびその他の複雑さを必要とします）、パススルーするだけです。入力がUTF-8の場合、出力はUTF-8になります。入力がWindows-1252の場合、出力はWindows-1252になります。驚き最小の原則...

于 2013-03-26T21:56:40.153 に答える
0

EBCDIC。しかし、それについて心配する必要はありません。

ただし、一般的に、最も正直なアプローチは、入力として任意のエンコーディングを受け入れ、UTF-8を吐き出すことだと思います。

于 2013-03-26T21:21:03.060 に答える