2

ANSIまたはUnicode文字列のいずれかを保持できるバッファを指す型指定されていないポインタがある場合、保持している現在の文字列がマルチバイトであるかどうかを確認するにはどうすればよいですか?

4

3 に答える 3

9

文字列自体にその形式に関する情報(ヘッダーやバイト順マークなど)が含まれていない限り、文字列がANSIまたはUnicodeであるかどうかを確実に検出する方法はありません。Windows APIにはIsTextUnicode()、文字列がANSIかUnicodeかを基本的に推測するという関数が含まれていますが、推測を余儀なくされるため、この問題が発生します。

そもそも文字列への型なしポインタがあるのはなぜですか?そもそも型付きポインタを使用するか、ANSI / Unicodeフラグなどを提供することにより、データが情報をどのように表しているかを正確に知る必要があります。バイトの文字列は、それが何を表しているのかを正確に理解していない限り、意味がありません。

于 2010-12-03T00:03:25.647 に答える
5

Unicodeはエンコーディングではなく、コードポイントから文字へのマッピングです。エンコーディングは、たとえばUTF8またはUCS2です。

また、ASCIIとUTF8エンコーディングの違いがゼロであるため、128文字未満に制限すると、実際には違いがわかりません。

ASCIIとUnicodeの特定のエンコーディングの違いを区別する方法があるかどうかを尋ねたほうがよいでしょう。そして、その答えは、不正確さの本質的な可能性を伴う統計分析を使用することです。

たとえば、文字列全体が128未満のバイトで構成されている場合、それはASCIIです(UTF8である可能性がありますが、その場合は区別する方法も違いもありません)。

主に英語/ローマ字であり、バイトの1つがゼロである2バイトのシーケンスが多数含まれている場合は、おそらくUTF16です。等々。ある種の指標(BOMなど)が実際にない限り、絶対確実な方法があるとは思いません。

私の提案は、あなたが推測しなければならない立場に身を置かないことです。データ型自体にインジケーターを含めることができない場合は、ASCIIおよびUnicodeの特定のエンコーディングに異なる関数を提供します。次に、決定作業をクライアントに強制します。呼び出し階層のある時点で、誰かがエンコードする必要があります。

または、さらに良いことに、ASCIIを完全に捨てて、新しい世界を受け入れ、Unicodeを排他的に使用します。UTF8エンコーディングでは、ASCIIにはUnicodeに勝る利点はまったくありません:-)

于 2010-12-03T00:07:06.457 に答える
2

一般的にはできません

ゼロのパターンを確認できます-最後の1つだけがおそらくansi'c'を意味し、1バイトおきにゼロはおそらくUTF16としてのansiテキストを意味し、3zerosはUTF32である可能性があります

于 2010-12-03T00:03:33.187 に答える