漢字を正しく表示するためのレガシーコードを取得しようとしています。私が使用しようとしている1つの文字エンコードは、0x7Fで始まり、4バイトの長さ（0x7Fバイトを含む）です。これがどのような種類のエンコーディングであり、どこでその情報を見つけることができるかを誰かが知っていますか？ありがとう..
更新：すべての文字を0xE3で開始し、長さが3バイトの日本語エンコーディングも使用する必要がありました。Windowsで日本語ロケールを選択すると、コンピューターでは正しく表示されますが、アプリケーションでは正しく表示されません。ただし、日本語以外のロケールを選択すると、ファイル名が正しく表示されません。したがって、このエンコーディングはUnicodeではないと思います。誰もがそれが何であるか知っていますか？それはANSIですか？シフトJISですか？
中国語の場合は、UnicodeとUTF-8文字でテストしましたが、同じパターンが得られています。0x7Fの後に3バイトが続きます。UnicodeとUTF-8は同じですか？
私が使用しようとしている 1 つの文字エンコーディングは 0x7F で始まり、長さは 4 バイトです
他のバイトは何ですか？このエンコーディングにラテン語のテキストはありますか?
「0x7f 0x... 0x00 0x00」の場合、UTF-32LE を参照しています。2 つの UTF-16 (LE または BE) 文字の場合もあります。
ほとんどの東アジア エンコーディングでは、非 ASCII 文字のリード バイトとして 0x80 ～ 0xFF を使用します。先頭の 0x7F を ASCII 削除以外のものとして使用することを私が知っているものはありません。
到着予定時刻:
バイトオーダーマークがあるはずですか?
エンコーディングが「UTF-32LE」であることを知らせる帯域外の方法がある場合は、BOM は必要ありません (おそらく、到達する前に失われます)。
また、すべての文字が 0xE3 で始まり、長さが 3 バイトである日本語エンコーディングを使用する必要がありました。
それは確かにUTF-8です。シーケンス 0xE3 0x... 0x... は、ひらがな/カタカナが存在する U+3000 と U+4000 の間の文字になります。
Windows で日本語ロケールを選択すると、コンピュータでは正しく表示されますが、アプリケーションでは正しく表示されません。
その場合、あなたのアプリケーションは残念ながら非 Unicode 準拠のアプリの 1 つであり、Win32 インターフェイスの「A」(*) バージョンを「W」サフィックスの内部でまだ使用している可能性があります。実際のエンコーディングに従って文字列を読み取ることができるかどうかは議論の余地があります。Unicode に準拠していないアプリでは、東アジアの表意文字を西側のロケールで表示することはできません。
(*: 「ANSI」という名前は、「現時点でシステムのコードページが設定されているものは何でも」という Windows の誤解を招く用語です。ロケールの変更が影響したのはそのためです。)
ETA(2):
OK、クラックしました。これは私が以前に会った標準化されたエンコーディングではありませんが、Unicode コード ポイントがエンコードされているという前提を前提にすれば、比較的簡単に解読できます。
0x00-0x7E: plain ASCII
0x7F A B C: Unicode character
Unicode エスケープでエンコードされた文字は、A、B、および C のキー文字列のインデックスを取得し、それらを加算することで計算できます。
A*0x1000 + B*0x40 + C
つまり、これは base-64 文字セットですが、通常の Base64 標準ではありません。少し実験すると、次のキー文字列が得られます。
.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz
「。」および「_」文字は、投稿した文字で使用されていないため、推測です。正確な文字列を見つけるには、さらにデータが必要です。
たとえば、次のようになります。
0x7F 3 u g
A=4 B=58 C=44
4*0x1000 + 58*0x40 + 44 = 0x4EAC
U+4EAC = 京
ETA(3):
ええ、手動で各コード ポイントを吸い出し、文字として結合することで、ネイティブの Unicode 文字列を簡単に作成できるはずです。使用しているプラットフォームで何が利用できるかはよくわかりませんが、Unicode 対応のプラットフォームであれば、コードポイントから文字列を簡単に作成できるはずです (できれば、UTF-16LE バイトに手動で再エンコードする必要はありません)。
3 つの例の文字の最初のエスケープ文字が、Unicode コードポイントと同じ一般的な範囲内にあり、同じ番号順であることに気付いて、それは Unicode コードポイントに違いないと考えました。他の 2 文字はランダムに変化するように見えたので、コード ポイントのビッグ エンディアン エンコーディングである可能性が非常に高く、6 は読み取り可能な ASCII から取得できる最大ビット数であるため、おそらく base-64 エンコーディングです。
標準の Base64 自体は文字で始まります。これにより、数字で始まるものは基本多言語面に収まりきれなくなります。そこで私は、「0123456789ABCDEFG...」で推測を始めました。これは、キー文字列のもう 1 つの明らかな選択です。その結果、特定の文字のコード ポイントに近い数値が得られましたが、少し低すぎました。キー文字列の先頭に余分な文字を挿入すると (したがって、数字 '0' は数字の 0 にマップされません)、文字の 1 つが正しく、他の 2 つが非常に近くなります。正しいものには小文字がなかったので、小文字だけを変更するために、大文字と小文字の間に別の文字を挿入しました。これにより、適切な数値が得られました。
これが実際に正しいとは限りませんが、(挿入される文字の任意の選択を除けば) その可能性は非常に高いです。
chardetを試してください。これは、バイト文字列の文字エンコードを推測するのに適しています。
UnicodeとUTF-8は同じですか？
いいえ。UTF-8は、Unicode文字をバイトシーケンスとして表す1つの方法にすぎません。Unicodeは完全な標準であり、各文字に数値および人間が読める識別子を割り当て、文字に関する多くのメタデータを割り当てます。
ウィキペディアの漢字エンコーディングのページを参照してください。常に 4 バイトであることがわかるエンコーディングはUTF-32だけです。
GB 18030は現在の標準の中国語文字セットですが、1 から 4 バイトの長さにすることができます。
はい、中国語は Unicode の実装 (エンコーディング) である UTF-8 です。UTF-8 は、ASCII 文字の長さは 1 バイトで、その他の文字は最大 4 バイトです。
これは、utf-8 または UTF16 サロゲート ペアなどの有効な Unicode エンコーディングである可能性があります。