問題タブ [invalid-characters]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
302 参照

php - 配列要素へのアクセス方法「Array ( [#text] =>」

並べ替えるために配列に変換した XML がありましたが、もう一度 XML として保存したいと思います。次のものがなければ、これは問題になりません。[caseid] => Array ( [#text] => 885470 ...

私は欲しい:<caseid> 885470 </caseid>

フィールド名「caseid」の DOM の書き込みは問題ありませんが、フィールド値は「#text」というタイトルの配列であり、解析方法がわかりません。

「#」記号をグーグルで検索できないので、検索はかなり大変でした。

0 投票する
1 に答える
10845 参照

c++ - cin.clear() は cin オブジェクトをリセットしません

次のループがあります。EndOfFile、またはユーザー入力 -999まで数字を読み取る必要があります

ユーザーが s などの無効なものを入力すると、エラー状態になったり停止したりすることcharなく、このループが永遠に繰り返されます。clear

0 投票する
4 に答える
50273 参照

javascript - ◎ͫ◎と☺のJavaScript変数名が有効でないのはなぜですか?

0 投票する
1 に答える
212 参照

php - Kohana 3 - In View ® に無効な文字が表示される

サイト全体を UTF-8 に変換しています。ほとんどの場合、問題はありませんでしたが、現在、® 記号は無効な文字としてビューに表示されますが、コントローラーで値を出力すると正しく表示されます。

メイン ビューに meta 属性を含めるようにしました。

不足している設定はありますか?

0 投票する
1 に答える
1547 参照

git - 名前に無効な文字が含まれるブランチを削除するにはどうすればよいですか?

誤ってブランチ「サンドボックス」を作成しました(これらの「サンドボックス」を使用)。これを削除しようとすると、次のメッセージが表示されます。

urxvtをutf8端末として使用してみました。

bitbucket.orgでgithostingを使用しています

ありがとうZopper

0 投票する
2 に答える
832 参照

javascript - IIS7フォルダ名-「+」文字は有効ですか?

このようなGooglePlusリダイレクトを作成しようとしています...www.domain.com/+

単純なdefault.htmlファイルを含む「+」という名前のフォルダーを作成しました。Default.htmlはデフォルトのドキュメントであり、単純なJSリダイレクトが含まれています。フォルダのような404が表示され、ファイルが存在しません。非常に奇妙な!

プラス文字はフォルダ名に有効であるように見えるので、私は困惑しています。何か案は?

ありがとう

0 投票する
4 に答える
2041 参照

php - PHP を使用して MySQL に HTML を格納する際のエンコードの問題

HTML をデータベースに保存できる CMS を構築しました。それはすべて非常に単純なことから始まりました。htmlspecialchars を使用して HTML をテキストエリアに表示し、フォームが壊れないようにしました。次に、html_specialchars_decode を使用して保存しました。誰かが入力する代わりに HTML をシステムに貼り付けるまで、すべて正常に動作しているように見えました。この時点では問題なく保存されていましたが、空白のほとんどが失われていたため、すべての美しいインデントを最初から行う必要がありました。

それを修正するために、utf-8 エンコーディングですべてを指定しようとしました。

PHPヘッダーにutf-8を指定しています

HTML ページで utf-8 を指定しています

HTML形式でutf-8を指定する

次に、投稿された値を(基本的に)次のように読み取ります。

私の理解では、PHP はすべてを utf-8 で行っていたので、この段階で gobbledegook が発生することに少し驚いています。

したがって、この段階では、動作します。私は素敵なインデントをすべて失いますが、空白のすべてではありません. utf8 以外の文字が取り除かれているようです。奇妙なことに、私はChromeを使用していますが、Firefoxでは問題ないようです

私は今、自分を縛っているだけだと思います。エレガントな提案はありますか?ハッキングして機能させるのではなく、この問題の根底に到達する必要があります。

0 投票する
2 に答える
3957 参照

.net - 無効な文字を挿入する .net Xml シリアライゼーションを停止する方法

0x20 未満のもの (0x09、0x0a、0x0d、つまりタブ、キャリッジ リターン、ライン フィードを除く) は、XML ドキュメントに含めることはできません。

データベースから出てくるデータがあり、Web サービス要求への応答として渡されます。

Soap フォーマッタは 0x12 文字 (Ascii 18、Device Control 2) を喜んでエンコードしますが、 16 進値 0x12&#12;のクライアントで応答が失敗し、無効な文字です。

<rant>私が非常にイライラしているのは、これらが同じコインの表裏であり、クライアントとサービスの両方が .net アプリであることです。何も読み取れない場合、soap フォーマッタが不適切な xml を書き込むのはなぜですか?</rant>

どちらかにしたい

  1. これらの奇妙な文字を正しく処理する Xml シリアライザーを取得するか、
  2. Web サービスでリクエストを失敗させる

私はグーグルで検索しましたが、a)「入力をサニタイズする」またはb)「ドキュメント構造を変更する」以外に、これについて多くを見つけることができませんでした。

a) このデータの一部は 20 年以上前のものであるため、ランナーでは
ありません。b) 独自のフロント エンド以外に、Web サービスに対して直接コーディングするクライアントがあるため、選択肢はあまりありません。

私が見逃している明らかなものはありますか?それとも単に AscII 制御コード周辺のコードのケースですか?

ありがとう

更新
これは実際には XmlSerialiser の問題です。次のコードは無効な文字をストリームにシリアル化しますが、逆シリアル化はしません。

XmlWriter を明示的に作成し、それを に渡すことで、xml の書き込みをチョークすることができますSerialise(私自身の回答としてすぐに投稿します)。
これらの文字は重要なので、単に取り除くことはできません。送信前にエンコードし、読み取ったときにデコードする必要があります。これを行うための既存のフレームワーク メソッドがないように見えることに本当に驚いています。

0 投票する
0 に答える
178 参照

json - PHP の「T_STRING」エラーを調整するには支援が必要です

基本的に、私は当面 PHP 5.1.6 システムで立ち往生しており、json_encode() が必要なので、このコードを見つけました。ただし、無効な T_STRING について不平を言っている理由は一生わかりません。うまくいけば、それは完全に明白/単純なものです。

次のコードを使用しようとすると:

次のエラーが表示されます。

解析エラー: 構文エラー、4 行目の /var/www/html/siteadmin/includes/functions_custom.inc.php の予期しない T_STRING

明確でない場合、「4 行目」は「function json_encode($a=false)」を含む行を参照しています。以前に関数を追加しようとしましたが (パラメーターとデフォルト値の有無にかかわらず)、それらはすべて正常に動作します。ただし、このコードには何か問題があります。

0 投票する
1 に答える
813 参照

asp.net - StackExchangeはルートURLの無効な文字をどのように処理しますか?

リクエストURLでの奇抜な文字の使用に関するScottHanselmanの投稿では、IISおよびASP.Netのセキュリティ機能を回避して、無効な文字をURLで渡すことができるようにする方法について説明しています...しかし、スタック交換は彼とは異なる方法で行っていると確信しています方法論は、サイトを厄介な攻撃やバグに対して広く開放したままにします。


StackExchangeには、次のようにエンコードされたリクエストC#でWebサーバーに送信されるタグへのリンクがあります。GET

秘訣は...クエリ文字列の値としてではなく、リクエストパス値(ルートパラメータなど)として送信されることです...

Hanselmanの記事を見ると、RequestValidation以外のいくつかの他のセキュリティ機能をオフにすることによってのみ可能であると彼は示唆しています(後者はURLのクエリ文字列部分でエンコードされた文字を許可します)。

質問

  1. StackExchangeはこれをどのように達成しますか?

  2. ハンゼルマンが彼のブログで説明しているのと同じ方法で行われた場合、彼らは自分自身を守るためにどのような追加の手順を実行しますか?