2012-05-11 11 views
18

最近、私はブラウザのサポートでデータの品質が原因でバグを起こしました。必要がない限り、ダブルサイズなしで文字列エスケープを適用するための安全なルールを探しています。出力でフィルタリングされるべきUnicode文字のリスト?

Unicodeデータベースで完全に有効な文字であるUTF-8バイトシーケンス "E2-80-A8"(U + 2028、ラインセパレータ)。ただし、そのシーケンスは行区切り文字を表します(「はい」、「0A」以外)。

ひどく、多くのブラウザ(Chrome、Firefox、Safariを含む、私は他人をテストしませんでした)は、そのUnicode文字を含む文字列を持つJSONPコールバックの処理に失敗しました。 JSONPは私が何もコントロールしていない非Unicode HTMLに含まれていました。

ブラウザは、デバッグツールとすべてのテキストエディタから有効と思われるこのようなJavaScriptで、INVALID CODE /構文エラーを単に報告しました。私が推測するところは、 "E2-80-A8"をBIG-5に変換してJS構文を破ってしまうかもしれないということです。

上記は、予期せぬことにシステムを壊すUnicodeの例です。私が知る限り、いくつかのハッカーは、RTLと他の制御文字を使うことができます。また、Unicode仕様では、 "引用符"、 "スペース"、 "シンボル"、 "コントロール"が多数あります。

QUESTION:

は、我々は我々のアプリケーションでそれらを効果的たくない場合があります隠された機能(とバグ)について知っているすべてのプログラマのためのUnicode文字のリストがあります。 (たとえば、WindowsではfilenameでRTLを無効にする)。

EDIT:

私はJSONもJavaScriptを求めていません。私は、すべてのプログラムでUnicodeのハンドリングの一般的なベストプラクティスを求めています。文字列がそれらに改行を持つことができないので

+1

ためICU projectを見てください。ブラウザがエンコーディングが明確にUTF-8であるJSONを別のエンコーディングとして誤って解釈すると、そのエラーはブラウザにあります。 *それらは修正する必要があります。 Gimping JSONは解決策ではありません。 – daxim

答えて

3

文字プロパティのデータベースがありますそしてそれを記述する報告書、UNICODE CHARACTER DATABASEは、ブラウザがどのようにコードポイントを扱うべきかを知っています。私はその言葉が大好きです。最も安全なものはホワイトリストになるでしょうが、おそらくL | M | N | S、レター、マーク、または数字またはシンボルで行けます。 JSONは、**何も**フィルターれてはならないUnicodeの一般的なシリアル化形式であるか、相互運用壊すので

は、ライブラリ

+0

質問にお答えいただきありがとうございます –

8

それはJavaScriptを壊す:

var myString = "
"; 

//Syntax Error 

var myString = " 

"; 

//SyntaxError: Unexpected token ILLEGAL 

今、UTF-8シーケンス"E2-80-A8"はJavaScriptで改行するために同様に処理されたUnicodeのコードポイントU+2028にデコードします

書くこと、しかし安全です

var myString = "\u2028"; 
//you can now log myString in console and get real representation of this character 

これは正しくエンコードされたJSONが持つものです。安全でない文字のブラックリストを保持するのではなく、JSONを正しくエンコードする方法を検討します。 (これはU + 2028とU + 2029 AFAIKです)。 PHPで

echo json_encode(chr(0xe2). chr(0x80).chr(0xA8)); 
//"\u2028" 
+0

JSONはほんの一例です。 XMLエンコード、HTMLテキスト、HTML属性、SQL、URIエンコーディング、ファイル名、電子メールアドレス、ドメイン名などがあります。上記の例では、フレームワークから提供されたエンコーディングメソッドを使用しています。明らかにバグがあります。 APIを使用すると、文字のエスケープが常に正しいことが保証されておらず、壊れたときにDIYする必要があるかもしれません。 –

+0

より具体的には、JSONPはSpring MVC APIによって生成されました。 –

+0

@DennisCheung JSONPはjavascriptコードとして実行されますが、他のデータは単なるデータですが、どうやってこれと関係があるのか​​わかりません。説明した問題は、JSONPにのみ適用されます。 – Esailija

3

A-Z、Z-及び0-9は、一般的に安全です。これらの62文字以外では、システムによっては問題が発生します。誰もあなたに与えることができる他の答えはありません。

たとえば、ドメイン名が挙げられます。 Unicodeドメイン名を扱う唯一の方法は、RFC 3454とRFC 5890-5893に従い、その方法でデータを処理することです。ほとんどのUnixファイルシステムのファイル名は、/または\ 0を含まない任意のバイト列です。 Unixのファイル名を機能的にUnicode文字列として扱うことは、何も壊すことなく、それ自体の問題です。 Windowsファイル名はA-Zセーフではないことに注意してください。 NULやPRNのようなものは予約された名前です。それぞれのドメインは独自の小さな問題や癖に直面しており、簡単な要約はどこにも充分ありません。

+0

私には意味がありません。 A-Z0-9のみを使用できるのであれば、UTF-8は何のためですか?それは、7ビットのBBSネットワークへの日帰りのように聞こえるし、Base64にはすべてが必要です。 Unicodeにはあまりにも多くの設計された機能があり、無視しなくてはなりません。 –

+0

私はUnicodeを使わないと言っているわけではありません。私はあなたがドメインネームシステムについて質問したと言っています。それらのRFC3454と5890-5893を見る必要があります。あなたはファイル名について尋ねました。 POSIXファイル名は、\ 0または\ x2Fを含まない任意のバイト列です。 Windowsのファイル名は大文字と小文字を区別しないUTF-16で、ASCIIの予約名を除外する必要があります。それらの中に入ることができるものに対する正式な答えは類似していません。 – prosfilaes

+0

Windowsファイル名が良い例です。 RTLはファイル名の指定で有効です(ウイルスがそれを使用していました)が、実際にブロックする必要があります。仕様/ RFCからそれを読むことはできません。 RFCを書いた人でも、その危険な文字を除外リストに入れる前にUnicodeを知っている必要があります。 –

4

ユニコードチャートを見てください。印刷できない文字のリストがあります。これらは潜在的なトラブルメーカーになるものです。あなたの友人U + 2028にはたくさんの友人がいます:http://www.unicode.org/charts/PDF/U2000.pdfそしてそれは2000年の範囲だけではありません。

あなたはなど、(U + 2028のような9月の文字が\ nまたは適切にエスケープになってきて)それらすべてをNUKE、または異なるカテゴリにそれらを分離可能性のいずれか

HTH

+1

私の2日間の問題を修正しました、ありがとうございます。 – eabates

関連する問題