4

inspect出力を書き込んで を介してロードすることで情報を外部ファイルに保存するという考えに誰かが言及するevalと、多くの人がその考えを批判し、代わりに YAML の使用を推奨することがわかります。の出力を書く際の問題は何inspectですか? また、YAML が好まれるのはなぜですか? inspect人間の可読性については、YAML よりも ruby​​ やppformat の方が優れていると思います。

4

3 に答える 3

4

何もオーバーライドしないと仮定するとinspect、これは何の役に立ちますか?:

#<Foo:0xa34feb8 @bar="wat">

これと比較すると：

--- !ruby/object:Foo
bar: wat

YAML は、重要な状況下で有用な出力を生成する可能性が高くなります。また、移植性があり、異なるシステム間でシリアル化されたデータを送信するためのより信頼性の高い方法として使用できます。

于 2012-01-28T13:53:51.227 に答える
4

セキュリティが主な関心事です。は渡されたコードを実行するためeval、悪意のあるハッカーがデータ ファイルにコードを挿入し、プログラムを制御する可能性があります。これは自分用の小さなスクリプトでは重要ではないかもしれませんが、Ruby on Rails サーバーではセキュリティが重要になります。次のコードがあるとします。

f=File.new("foobar.txt")
f.puts Foo.new.tap {|foo| foo.bar="bork"}.inspect

Fooこれは、が上書きされていないと仮定すると、inspect次のようになります。

#<Foo:0xff456a5 @bar="bork">

明らかに、これは有効な Ruby 構文ではありません。奇妙なことに、evalエラーはスローされませんが、単に返されますnil。これは、これを悪い考えにするだけです。変数であると予想していた変数が、Fooただのnil(悪名高いNoMethodError: undefined method 'bork' for nil:NilClassエラー) になっているからです。

これに関するもう 1 つの大きな問題は、セキュリティの問題です。コードがデータをファイルに保存するとします。たとえばfoo.txt、inspected ハッシュ マッピングbars をそれぞれのbazes に保存します。FOO 規則を計画するためにこれらのマッピングを知る必要がある別のプログラムは、evalこのファイルを読み取って s します。このファイルは、ハッカーがアクセスできる場所にあると想像してください (考えると、ほとんどどこにでもあります)。これらのプログラムが、foo のすべての財務データも格納する RoR サーバーで実行されている場合、ハッカーは大規模な混乱を引き起こす可能性があります。このハッカーが にコードを挿入した場合foo.txt、つまり、悪意のあるウイルスをシステムにダウンロードしてインストールしたものの、元のプログラムのハッシュが最後に残っていた場合、気付かれずに実行されます。をeval使用してデータを取得しても、$SAFE=4、ハッカーはエラーをスローするなどして、foo プレーニングプログラムの安定性を損なう可能性があります。

全体として、アプローチは、 、 などinspectの基本クラスで機能しますが、それ自体の正確な構文表現を提供するクラスに依存します。すべてではないにしても、ほとんどのアプリケーションでは、-を使用するのは悪い考えです。YAML はdataの構文が定義されているため、優先されます。つまり、実行可能コードが混在すると、無意識に実行されるのではなく、エラーが発生します。また、多くの開発者はデバッグに使用しており、オブジェクトがそれ自体のファイル ダンプを提供することを期待していません。evalHashStringArrayinspectevalinspect

YAML のその他の利点は、複雑なオブジェクトを簡単にシリアル化できることです。foo と bar の複雑なオブジェクト ツリーは YAML で簡単に作成できますが、YAML を使用inspectすると非常に複雑になります。最終的な分析では、これは JSON 問題 (使用されたために実行されたデータ内の実行可能コード) と考えることができますeval。inspect自分用の小さなユーティリティには問題ないかもしれませんが、製品コードや、非常に平均的な広い世界に開かれたコードでは決してありません。

于 2012-01-28T14:49:21.267 に答える