2 
trace(escape("д"));

この文字の正しい URL エンコードである "%D0%B4" を出力します (キリル文字で "A" に相当)。

でも、もしやったら..

myTextArea.htmlText += unescape("%D0%B4");

印刷されるものは次のとおりです。

д

これはもちろん正しくありません。ただし、上記の unescape をトレースするだけで、正しいキリル文字が返されます。この texarea の場合、「д」をエスケープすると、Unicode コードポイント「%u0434」が返されます。

これを台無しにするために正確に何が起こっているのかはわかりませんが...

UTF-16 - Web エンコーディングの場合: %FE%FF%00%D0%00%B4

一方

Web エンコーディングの UTF-16 ä は %00%D0%00%B4 です。

したがって、この値の先頭に何かを埋め込んでいます。トレースが(空の)テキストエリアへの印刷とは異なるテキストを提供するのはなぜですか? どうしたの？

問題のテキストエリアには、そのようなことが可能な場合でも、奇妙なエンコーディングプロパティが添付されていません。

4

1 に答える 1

4

問題はunescape（escape問題になる可能性もありますが、この場合は原因ではありません）。これらの関数はマルチバイトに対応していません。これは何ですかescape: 入力文字列のバイトを取り、%先頭に を付けて 16 進表現を返します。unescape反対を行います。ここで重要な点は、文字ではなくバイトで機能することです。

あなたが欲しいのはencodeURIComponent/decodeURIComponentです。両方とも、文字列エンコーディング スキームとして utf-8 を使用します (どこでもフラッシュで使用されるエンコーディング)。これは utf-16 ではないことに注意してください (フラッシュに関する限り、気にする必要はありません)。

encodeURIComponent("д"); //%D0%B4
decodeURIComponent("%D0%B4"); // д

さて、もう少し深く掘り下げたい場合は、ここで何が起こっているかを示します (これは、utf-8 の仕組みに関する基本的な知識があることを前提としています)。

escape("д")

これは戻ります

%D0%B4

なんで？

"д" は flash で utf-8 として扱われます。この文字のコードポイントは 0x0434 です。

バイナリで:

0000 0100 0011 0100

これは 2 つの utf-8 バイトに収まるため、次のようにエンコードされます (ここでeは、エンコード ビットをp意味し、ペイロード ビットを意味します)。

1101 0000 1011 0100
eeep pppp eepp pppp

これを 16 進数に変換すると、次のようになります。

0xd0  0xb4

したがって、0xd0,0xb4 は utf-8 でエンコードされた「д」です。

これは に供給されescapeます。escape2バイトを見て、あなたに与えます：

%d0%b4

これを に渡しますunescape。しかしunescape、少し脳死しているので、常に1バイトが1文字と同じであると考えています。関係する限りunescape、2 バイトがあるため、2 つの文字があります。0xd0 と 0xb4 のコード ポイントを調べると、次のように表示されます。

0xd0 -> Ð
0xb4 -> ´

そのため、2 つの文字で構成される文字列を返しunescapeます(実際には utf-8 でエンコードされた 1 つの文字だけを取得した 2 バイトを把握する代わりに)。次に、テキスト プロパティを割り当てると、実際にはд` が渡されません。これがテキスト領域に表示されます。Ð´д´ but

于 2011-03-31T02:42:44.593 に答える