文字列は、テキストを保持して操作できる最も単純なオブジェクトと見なすことができます。そのため、文字列に作用する関数は、必ずしもメソッドとしてまとめられるべきではありません。一方、javascript は主に Web プログラミング言語であり、URI を操作することは言語の文字列の非常に一般的な用途です。この場合、次のようなものlastName.encodeURIComponent()は実際には非常に便利です。
encodeURIComponent や unescape のようなものが関数であり、String オブジェクトのメソッドではないのはなぜですか? ここで何らかの CS の原則が働いているのでしょうか、それとも言語の設計者の主観的な選択でしたか?
明らかに、文字列を操作するすべての関数が文字列オブジェクトに含まれている必要はありませんが、人々はどこでどのように線を引くかを決定するのでしょうか?
それらはブラウザ環境に固有であるためです。これらは、JavaScript 言語の汎用 String オブジェクトには存在しません。
これらのメソッドは JavaScript の一部ではないと思いますがwindow、ブラウザに関連付けられたグローバル オブジェクトである から継承されています。したがって、リストした関数は文字列を処理しますが、実際にはブラウザー関数に密接にバインドされているため、Stringプロトタイプには関連付けられていません。MDN などの情報源は、これについてはやや曖昧ですが、元の JS 仕様ではこれらのメソッドについて言及していないことは確かです。
あまり意味がなかったかもしれませんが、今日では、誰かが組み込みシステムの言語として JS を使用したり、インターネットと関連のない他の何かを使用したいと考えていることは実際に考えられます。ここで、インクルードされた構文は、 のように場違いにencodeURIComponent()なりますdocument.getElementById()。
escape() 関数は文字列をエンコードします。
この関数 m*は文字列を移植可能* にするため、任意のネットワークを介して ASCII 文字をサポートする任意のコンピューターに送信できます。
この関数は特殊文字をエンコードします
現在、この機能は、ブラウザベースの環境の URL である文字列に固有のものであり、言語としての JS はそれから独立しています。
したがって、escape,unescape を文字列に入れると、ネットワークや URL に関連しないシナリオでは役に立たなくなります。
それが、それらがWindow オブジェクトの一部である理由です。
文字列にしたい場合は、文字列のプロトタイプに追加できます。
どこで止まりますか。文字列は一義的です。定義によれば、文字列を引数として取るか、または返されるメソッドは文字列クラスにある必要があります。
同様に、ストリームを取得する Encoding メソッドと、エンコードを行うストリーム メソッドを用意することも合理的です。
あなたはすぐにどこにでもいるでしょう、またはエンコーディングクラスに委譲することによって文字列を拡張するでしょう。