[翻訳]PHP ミレニアム バグ (y2k 準拠)、_PHP チュートリアル

[翻訳] PHP Y2K コンプライアンス、

時計は容赦なく 2000 年の最後の年に近づいており、翌年ドゥーム セイヤーズは考えられるあらゆる領域で前例のないコンピューター障害が発生すると予測しています。 2000 年問題、または Y2K バグとも呼ばれるこの状況は簡単に説明できます。この手順では、XX 法は 2000 年の Form XX 日付 19 から始まり、その後翌年まで続くと説明されています。あなたの誕生日が「2/2/05」なら、101年後、それとも1年後には101歳になりますか？

このバグを修正するための費用の見積もりは数十億ドルに達し、少なくともその金額は、実際の損害賠償と申し立てられた損害によって長期化する訴訟費用の再発を脅かす可能性があります。このような壊滅的なコスト予測の結果、企業や政府に対して、すべてのソフトウェアが 2000 年準拠であることが保証されているという、安全で法的拘束力のある声明を使用するよう求める圧力が高まっています。

ご想像のとおり、このプレッシャーは弁護士に慎重な保険会社から生じることが多く、保険会社は実際に被る可能性のある費用の影響よりも、訴訟による死亡を非常に恐れており、その結果、損失が発生します。法的リスクから身を守るために、世界中の組織は、このようなソフトウェアが 2000 年に準拠していることを証明するために、可能な限り急いで安全な場所に急いでいます。彼らは、避けられない混乱が襲った際に、ある種の法的保護を行使し、自らがY2K汚染から解放されていることを正当に宣言し、訴訟の方向を上記文書の署名者に向けるつもりである。

これを覚えておいてください: 誰かがあなたの 2000 ソフトウェアに欠陥がないことを保証するようにあなたに求めた場合、彼らは、たとえそれがたまたま自分のせいだったとしても、ソフトウェアを悪用した場合にあなたを訴える口実を探しているだけです。おそらくソフトウェア ライセンスの条項を忘れている可能性があり、次のような内容になる可能性があります:

作者または配布者は、このソフトウェア、ドキュメント、またはその派生物の使用から生じる直接的、間接的、特別、付随的、結果的損害について、たとえ作者がそのような可能性について警告していたとしても、いかなる当事者に対しても責任を負わないものとします。損害賠償。

著者および配布者は、商品性、特定の目的への適合性、および非侵害の暗黙の保証を含むがこれらに限定されない、すべての保証を特に否認します。このソフトウェアは「現状のまま」で提供され、作成者および配布者はメンテナンス、サポート、更新、改善、または修正を提供する義務を負いません。

自動車メーカーが反保証などの政府の監視にどれだけ耐えられるのか、立ち止まって考えたことはありますか? しかし、なぜソフトウェアメーカーは違うように見えるのでしょうか?このようなものが、今後数年間に確実に起こるであろう法廷での訴訟の混乱を乗り切ることができるかどうかは、まだ分からない。何も期待しないでください。

Y2K についての不安は、ほとんどの大規模組織でますます最高潮に達しています。数日ごとに、一般的なメディアで、ある程度の混乱を予測する別の記事を目にします。これらのレポートのほぼすべてには、曖昧な予断や技術的な混乱が散見されます。これは、ここに本当の問題がないということではなく、何も気にしていないふりをすることができます。答えはもちろん「はい」です。しかし、問題の原因とそれに対して何ができるかは、せいぜい誤解されていることが多いです。通常、嘘が3回繰り返されると状況はさらに悪化します。

Y2K に関する 3 つの人気の嘘

よく言われる最初の嘘は、歴史的に Y2K は昨年の So Dear の高価なコンピューターのメモリから来たものであるというものです。プログラマーたちは、コストを管理するために日付を 2 桁の形式で管理していました。

この発言は明らかに間違っています。考えてみてください。 2 桁の数値はどのくらい保存する必要があるのでしょうか? 2 バイト、16 ビットですか? いや、ましてや、よりコンパクトな表現がすぐに利用できるため、数値データはテキスト形式で保存されることはほとんどありません。 2 桁の年は、00 から 99 までの数値になります。わずか 7 か所で表現できます。

1985 年または 2010 年の通年を使用するのはどうでしょうか? 数値はおそらく 11 桁で表されます。ベテランのプログラマーは、1 日あたり 4 ビットという大幅な速度の節約を実際に喜んで実現しているでしょうか? たとえそうでなくても、妥当なベースからのオフセットを使用することはできます。最後の 2 桁のみが使用された場合、年の日付は絶対値ではなく、1900 年からの年数を表す可能性があります。もしそうなら、これは少なくともしばらくの間は、前述の 7 ビットに適合するでしょう。もう 1 つの点を追加すると、2156 が明らかになります。終わりの質問。メモリを節約することがこれを行う理由ではありません。

昔のユーザーは、1900 年の代わりに年 % 1900 を使用して、年を非展開的に表現することを選択できますが、これはハードウェア コストの問題にはなりません。これは依然として短絡的でソフトな設計ミスです。

2 番目の嘘は、この現象はまったく新しいもので、2000 年には無数のシステムが突然故障するということです。 1895 年に生まれた古代の老人について考えてみましょう。彼らの誕生日を「95」と読むプログラムは、彼らがまだ3歳に見える1998年以来、数か月のチェック費用を支払わない。 2000 年はこの方程式では起こりませんでした。いわゆる「2000 年問題」は流行ったものではなく、またその年に限定されたものでもありません。そうすれば、それはより明らかになるでしょう。

Y2K 問題に関する 3 つ目の、これまでで最も深刻な嘘は、コンプライアンス宣誓供述書や訴訟を取得することで、真実かどうかにかかわらず、会社は危害から身を守ることができるというものです。それはできません。法的文書に対するこの信念は、実際には空虚で危険です。最も賢明なのは、自分の欺瞞を直ちに正すことです。

問題全体の根底にある根本原因は、ハードウェアまたはソフトウェアのいずれかにあります。いいえ、それは簡単すぎます。私たちはそれを修正する方法を知っています。数百ドルを申請すれば、なんとすべてが解決されます。

残念ながら、そうではありません。本当の問題はウェットウェアです。そうです。欠陥はコンピュータやそのプログラミングにあるのではなく、私たち自身にあるのです。

ほとんどの場合、人々は日付について考えるとき、最後の 2 つの数字だけを使います。彼らはそれを小切手に書きます。彼らはそれを家族の聖書に書きました。誰かが「65年まで遡って覚えている」とか「カリブ海におけるアメリカの驚くべき失敗によって彼らの集合意識の基盤が揺るがされた98年のことを覚えている」という言葉を聞くたびに、それが何を意味するのか分かるはずだ。ちょうど65歳ですか? 議長は人生を想定しています、それは1965年かもしれません。なぜ、それはその年ではなく、スペインが新興の新世界の人々にそのみすぼらしい帝国の残骸を失ったときです。文脈から曖昧さを推測しますが、文脈がなければ、推測するしかありません。

最も恐ろしいのは、たとえコンピュータープログラムが完全に正確で動作し、明らかに「2000年対応」だったとしても、依然として大きな問題に直面しているということです。たとえば、有名な Unix Carl プログラムを考えてみましょう。今月を見てみましょう。

リーリー リーリー

ご覧のとおり、プログラムに互換性があるかどうかは問題ではありません。プログラムを使用する人間には互換性がないからです。プログラムを修正することは確かに必要なステップですが、十分ではありません。すべてのプログラムが存在することは証明できますが、それでも十分に安全ではありません。世界中の何十億人もの人々、あるいはコンピューターを使用している数百万人が平等に認証され、忘れられないことが保証される時代が来るまで、セキュリティは存在しないでしょう。そんなことは起こらないでしょう。

特定のプログラムを意図的か非意図的かを問わず悪用できないという法的拘束力のある声明を求めることは魔女狩りにほかならず、あなたとあなたのプログラムを保護するという最終目標は失敗する運命にあります。助けようがありません。常に、無知で困難を抱えたユーザーやプログラマー、さらには時折記憶喪失に陥る無知な人々も存在します。それらを見つけることも、ツールや言語のせいにすることも、自分自身を守ることもできません。 1 年を 2 桁の数字で考えるたびに、問題が再び発生します。そして誰もソフトウェアの問題を解決する方法を見つけませんでした。

パール

Perl はどうですか? Perl 2000 は「互換性」がありますか? 答えは、Perl は Pencil と同じくらい互換性があり、それ以上でもそれ以下でもありません。あなたを慰めるのはどうですか？これは本来あるべきことではありません。 Pencil で Y2K バグをコミットできるのと同じように、Perl やその他のツールでも実行できます。そして、それを行うために遠くまで行く必要はありません。Carl のデモンストレーション プロジェクトが提供する完璧な互換性を目撃してください。

Perl によって提供される日付と時刻の関数は、C プログラミング言語から派生した gmtime() 関数と localtime() 関数です。これらは、2000 年以降を判断するための十分な情報を提供します。 2038 年に危機が発生し、私たちがまだ 32 ビット マシンに依存しているという状況は、確かにまったく考えられないわけではありませんが、可能性はやや低いです。

これらの関数は、一般的な誤解に反して、2 桁の数値として定義されるのではなく、(リストのコンテキストで) 年を返します。むしろ、今がまさにその通りなのです。それは実際には、現在から 1900 年を引いたものです。これは 1900 年から 1999 年の間、10 進数で長年にわたって発生しましたが、これは長くは続きませんでした。 2000 年問題を避けるため、西暦は数字としてまったく考慮されません。言うのは簡単、壊れるのは簡単。過去 5 年間で今年がどのようになるかを調べたいので、次のようなコードを作成するとします。

リーリー

Perl には保証がなく、TPI は Perl をサポートしていません。さらに、Perl は言語であり、言語はさまざまな方法で悪用される可能性があります。しかし、それはプログラマーとユーザーの責任であり、Perl の多くの作成者ではありません。しかし、Perl がフリーソフトウェア運動の代弁者として、私たちは、Perl が同じ Y2K 互換の C 言語インターフェイスに基づいており、Perl コンパイラとインタプリタがそれ自体で書かれていることを指摘する必要があると感じています。日付情報にアクセスする Perl インターフェイスは、設計として使用すると、あらゆる意味で Y2K 互換になります。

それがあなたの弁護士やマネージャーを喜ばせるなら、彼らにお願いしてください。まだ心配することがたくさんあります。

リーリー

原文: http://www.perl.com/pub/199​​9/01/y2k.html

http://www.bkjia.com/PHPjc/852740.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/852740.html技術記事 [翻訳] PHP ミレニアム バグ (2000 年準拠)、時計は容赦なく 2000 年の最後の年に近づいており、破滅の 2 年目です セイヤーズは、考えられる限りの前例のないコンピューター障害を予測しています...