ユニコードクッキー（特にFirefox）で検出される非標準の％uXXXXユニコード文字のエンコード/デコードに適したPerl XSモジュールがありますか？ユニコード％uXXXXのエンコード/デコードPerlのXSモジュール
復号：入力= ...％uXXXXという...、出力=正常UTF8のPerl列
エンコーディング：入力=正常UTF8 Perlの文字列、出力= ...％uXXXXという...
$string =~ s/%u([A-Fa-f0-9]{4})/chr(hex($1))/eg;
を、それのC-実装されたバージョンを持っていいだろう。今、私はこのコードを使用して、これらの文字列をデコードしています。
この特定の形式は、Cookie自体には関係しませんが、Cookieに適用されるアドホックエンコーディングの一般的な形式の1つです。これはJavaScript関数escape()によって生成されます。 URLエンコードによく似ていますが、互換性はありません。 JSの作者は、実際にそれを使用を停止する必要があります。
URI::Escape::JavaScriptには、unescapeアルゴリズムを再現する実装があります。これは基本的にあなたと同じアプローチですが、2桁の%xxパターンも処理します。
URLエンコーディングの拡張子としてJSエスケープエンコーディングを扱おうとするモジュールは、+文字の潜在的に異なる処理に移行する可能性があります。
私は、アプリケーションが実際にC言語で行う価値があるように、これらをデコードするのに十分な時間を費やすのではないかと疑います。
はい、私はそれがクッキーにのみ関連していないことを知っています。問題は、Firefoxがこのエンコードを使用することが好きであることです（Chromeはユニコードをエスケープバイトとして直接エンコードします）。私の場合、2桁の％xxコードはApache :: Cookie :: fetch（）によって自動的にデコードされるので、％uxxxxの場合を処理する必要があります。とにかく、あなたのメモと経験を共有してくれてありがとう。 – ArtM
Firefoxは、 'escape（）'が明示的に呼び出されたときにのみ、（他のブラウザと同様に）Cookieでエスケープしません。クッキーにraw非ASCII文字を含めると、エスケープするのではなく、途切れることになります。あなたは '％のxx'シーケンスを処理するために、標準のURLデコーダを使用している場合、URLデコーダは彼らがすることになるので、それにもかかわらず、あなたはおそらく範囲U + 0080-U + 009F（中文字と矛盾する結果が得られますUTF- 8符号化されていますが、 'escape（）'はここでISO-8859-1で符号化されたバイトを生成します）、 '+'の問題です。 – bobince
もちろん、私は間違っている可能性が高いですが、少なくともFirefoxとChromeは、クッキーの名前と値（そして多分他の場所でも）のUnicodeを扱います。恐らく 'escape（）'は舞台裏で呼ばれますが、Firebug/Firecookieと 'console'は '％uxxxx'を使ってUnicodeをエンコードします。明示的な 'encodeURI（）'が標準的な％エンコードされたコードを生成するのに対し、ここではデフォルトの動作について説明します。 – ArtM
ありがとう、それは必要とされているようです。私はURI :: Escapeを探していましたが、％uxxxxエンコーディングについてのドキュメントでは見つかりませんでした。 XSバージョンはより高度なようです。私はそれをテスト/ベンチマークしていきますが、私はすぐにこの質問に回答としてマークします。一方、他のモジュールがあれば追加することもできます。ありがとうございました。 – ArtM
URI :: Escape :: XSモジュールは必要に応じてエンコード/デコードを行っていますが、残念ながら純粋なPerl正規表現の置換よりも10倍遅く動作します。 – ArtM