MSLibrary。 iOSなどの正規表現を使用した電話番号のキャプチャと検証...パート1

一連の記事が表示される理由は、iOSライブラリのMSLibraryでの作業中に蓄積された多くの分析的で実用的な資料でした。 MSLibraryライブラリには多くのクラスが含まれており、開発者のルーチン作業を簡素化し、開発時間とコードサイズを大幅に削減するために設計されたさらに多くの関数とマクロが含まれています。 しかし、すべてには時間があります。ライブラリについては後で説明します。

そのため、正規表現を使用して電話番号をキャプチャして検証します。 どういう話があるのでしょうか？ 誰が自分自身の書き方を知っているのか、そして誰がWorld Wide Webの広大さに散らばっている多くの既成のソリューションの1つをコピーするのか知らないのです。 唯一の質問は、彼が何を書くのか、何をコピーするのか、そしてこのコードは現在の国際基準、業界基準、企業基準だけでなく、タスクセットにどの程度対応するのかということです。 最も単純なソリューションであっても、開発者が自分の作業を十分に認識しており、作業に絶対に自信がある場合にのみ、適切なソリューションです。

最も単純なソリューションであっても、開発者が自分の作業を十分に認識しており、作業に絶対に自信がある場合にのみ、適切なソリューションです。

実際、記事のトピックはすでにタイトル自体に2つに分かれています。 キャプチャとは、テスト対象の数字と記号のセットが電話番号になる可能性があることを理解する機能です。 そして、検証は、このセットが特定の事前設定条件を満たしているかどうかのチェックです。 上記の例を見ると、これらのタスクが異なることを簡単に確認できます。

 + 1（408）-996-10-10 = 1234
 +14089961010; ext = 1234

最初のケースでは、だれかが慣れ親しんだ方法で電話を録音しようとし、2番目のケースでは、電話は国際標準RFC 3966に従って録音されました。 問題は、これらのエントリの両方を使用して、たとえばiOSアプリケーションで電話番号をダイヤルしようとすると、残念ながら、何も得られないことです。 前者の場合、システムはまったく何も理解しません。後者の場合、内線番号「1234」の代わりに、システムは完全に異なる番号をダイヤルします（これは非常に説得力のある実験です。試してみてください。コードは以下に示します）。


基本的に、両方のタスク（キャプチャーと検証）は同じ方法で解決されますが、適用される正規表現のみが違います。

最初のステップは、この問題を管理するRFC 3966で書かれていることを確認することです。 そして、以下は非常に単純化された形式で書かれています：

RFC 3966に準拠した簡易電話URI構造

  telephone-uri = "tel："電話加入者 

•  電話加入者=グローバル番号 

•  グローバル番号=グローバル番号桁*パー 

•   par =拡張|  isdn-subaddress | パラメータ 

•   isdn-subaddress = "; isub =" 1 * uric 

•   extension = "; ext =" 1 * phonedigit 

•   global-number-digits = "+" * phonedigit DIGIT * phonedigit 

•  パラメータ= ";"  pname ["=" pvalue] 

•   pname = 1 *（alphanum | "-"） 

•   pvalue = 1 * paramchar 

•   paramchar = param-unreserved | 予約なし|  pctエンコード 

•  未予約= alphanum | マーク 

•  マーク= "-" |  「_」|  「。」  |  「！」  |  「〜」|  「*」「 '」|  「（」|「）」 

•   param-unreserved = "[" |  「]」|  「/」|  「：」|  「＆」|  「+」|  「$」 

•   phonedigit = DIGIT |  [ビジュアルセパレーター] 

•   visual-separator = "-" |  「。」  |  「（」|「）」 

•   alphanum = ALPHA | 桁 

•  予約済み= ";"  |  「/」|  「？」  |  「：」|  「@」|  「＆」|  "=" |  「+」|  「$」|  「、」 

•   uric =予約済み| 予約なし 

ここで、ALPHAおよびDIGITは、別のドキュメントから次のようにRFC 2396です。

•   DIGIT = "0" |  「1」|  「2」|  「3」|  「4」|  「5」|  「6」|  「7」|  「8」|  「9」 

•   ALPHA = lowalpha | アップアルファ 

•   lowalpha = "a" |  「b」|  「c」|  「d」|  「e」|  「f」|  「g」|  「h」|  「i」|  「j」|  「k」|  「l」|  「m」|  「n」|  「o」|  「p」|  「q」|  「r」|  「s」|  「t」|  「u」|  「v」|  「w」|  「x」|  「y」|  「z」 

•   upalpha = "A" |  「B」|  「C」|  「D」|  「E」|  「F」|  「G」|  「H」|  「私」|  「J」|  「K」|  「L」|  「M」|  「N」|  「O」|  「P」|  「Q」|  「R」|  「S」|  「T」|  「U」|  「V」|  「W」|  「X」|  「Y」|  「Z」 

回路図の電話URIは、次のように表すことができます。

 telephone-uri =    [  ] 

_{図 1}

RFC 3966から、次のようになります。

•  適切な電話番号= global-number-digits 

•  オプションの追加=拡張|  isdn-subaddress | パラメータ 

ここで：

•  内線-内線電話番号 

•   isdn-subaddress-ISDNサブアドレス 

•  パラメーター-その他のオプションのパラメーター 

実際にはモバイルアプリケーション、特にiOSアプリケーション、およびほとんどのサイトで作業する場合、内線電話番号のみがあるため、telephone-uriスキームは次のように変換されます。

 telephone-uri = global-number-digits [extension] 

_{図 2}

または、global-number-digitsおよびextensionに適切な値を代入します。

 telephone-uri = "+" *phonedigit DIGIT *phonedigit [";ext=" 1*phonedigit] 

_{図 3}

ここで、phonedigitは数字「[0-9]」と視覚的な区切り文字の限られた範囲で構成されます

  「-」|  「。」  |  「（」|「）」 

ここでは、そのように思われますが、このスキームを実装する正規表現の検討に進むことができます。 しかし...多くの著者は、数字のすべてのセットに電話番号があるわけではないことを正しく指摘しています。 電話番号の構造を定義する一般的に受け入れられている国際慣行があります。 はい、あります。実際に簡単に検討します。

国際電話番号の構造

既存の慣行に従って、次のグループを区別できます。これらのグループは、一緒にグローバル番号桁の電話番号を構成します。

グローバル番号

•   「+」-国際国コードが特定された後を示す記号 

•   country_code-1〜3桁の国コード。例：7、44または374 

•   area_code-3桁の地域コード。例：800 

•   exchange-3桁のステーション番号。例：555 

•   subscriber_number-4桁のサブスクライバー番号。例：1234 

延長

•   extension-内線番号、例：5678（オプション要素） 

この場合、電話番号の構造は次のようになります。

 telephonNumber = "+" country_code [visual-separator] area_code [visual-separator] exchange [visual-separator] subscriber_number [visual-separator] [";ext=" extension] 

_{図 4}

したがって、RFC 3966標準と電話番号の国際構造を考慮した正規表現を実装すると、言い換えると、図に示すスキームに対応します。 3および図 4、次の電話番号のエントリは完全に有効です。

 +14089961010; ext = 1234
 +1（408）996-1010; ext = 1234
 + 1-408-996-10-10; ext = 1234
 +1.408.996.1010; ext = 1234

以下は、視覚的な区切り記号が国際電話番号標準で定義されている構造の外側にあるため、RFC 3966標準に基づいてのみ有効です。

 +1（4089）96-1010; ext = 1234
 + 1-408996-10-10; ext = 1234
 +1.408996.1010; ext = 1234

実際には、ユーザーは、アプリケーションまたはWebサイトで指定されたテンプレートに従って、または適切と思われる（つまり、好みに応じて）電話番号をダイヤルできます。 そして、アプリケーションは、受信した文字列をその中に定められた標準に従って処理します。 常に一致するとは限りません。

実際には、ユーザーは、アプリケーションまたはWebサイトで指定されたテンプレートに従って、または適切と思われる（つまり、好みに応じて）電話番号をダイヤルできます。 そして、アプリケーションは、受信した文字列をその中に定められた標準に従って処理します。 常に一致するとは限りません。

企業のWEBダイヤル標準

なぜウェブ？ iOS、および他のほとんどすべてのシステム、そしてもちろんWebサイトでは、電話をかける最も簡単な方法は、よく知られているhtmlスキームを使用することです。

 <a href="tel:1-408-996-1010">1-408-996-1010</a> 

_{図 5}

記事の冒頭で、Objective-Cでこのスキームを実装するためのコードの例が既に提供されていますが、一貫性を保つために、繰り返す価値があります。

 NSString *telString =@"tel:+14089961010"; NSURL *urlString = [NSURL URLWithString: telString ]; [[UIApplication sharedApplication] openURL:urlString]; 

_{図 6}

企業標準に進みましょう。

Googleの専門家はこれについて何と言っていますか？

電話番号は常に国際ダイヤル形式（プラス記号（+）、国コード、市外局番、および番号）を使用して提供してください。 絶対に必要というわけではありませんが、読みやすく、自動検出を向上させるために、数字の各セグメントをハイフン（-）で区切ることをお勧めします。

つまり、国番号の前に「+」記号を配置し、「良いアイデアかもしれません」電話番号のセグメント（グループ）をハイフン「-」の形式の視覚的な区切り記号で区切る必要があります。 それは、一般に、RFC 3966および国際電話番号構造と非常に一貫しています。つまり、図1に示されているスキームに対応しています。 3および図 4.ただし、重要なBUTが1つあります。 視覚的な区切り文字は1文字、ハイフン「-」に制限されています。 これはもちろん、ブラウザが視覚的な区切りとして括弧やドットに不適切に応答することを意味するものではありませんが、これには慎重な検証が必要です。Googleドキュメントはハイフンのみを保証します。 さらに、マニュアルのこのセクションでは、拡張形式については何も言及していません。 この記事は主にiOSアプリケーションに焦点を当てているため、Gugolovskyソフトウェアの詳細を掘り下げることはせず、興味のある人は実験して結果について話すことができます。

アップルは、 電話リンクのセクションで、電話番号の許容される形式に関してさらに簡潔です。次のフレーズがあります。

tel URLスキームの詳細については、RFC 2806およびRFC 2396を参照してください。

正式には、すべてが正しいのですが、国際標準があるのになぜ繰り返すのですか？ しかし、実際には、Appleの企業標準とGoogleの標準は、これらの国際標準の一部にしか対応していないということです。

企業標準は、国際標準の一部にしか対応していません。これは、本来、推奨事項であることがよくあります。

iOSアプリケーションの電話番号で使用できるものと使用できないもの

実験では、RFC 3966で規制されている4種類すべての視覚的セパレータにシステムが適切に応答することが示されました。

•   visual-separator = "-" |  「。」  |  「（」|「）」 

さらに、セパレータは任意の場所に配置でき、さらにペアを解除できます。 例として、電話番号の次のレコードは、図に示すコードによって処理されます。 6、同等かつ非常に適切：

 +14089961010
 +1(408)996-1010
 + 1-408-996-10-10
 +1.408.996.1010
 +1（4089）96-1010
 + 1-408996-10-10
 +1.408996.1010
 + 1-4（0899（6-10-10
 +1.40）8996.10（10

内線番号をダイヤルする場合とは状況が異なります。 記事の冒頭で述べたように、システムは拡張コード「; ext = "RFC 3966で提案されたプレフィックス」に正しく応答しません。 ネイティブ、つまりシステムにとって自然なのは、「;」の2文字です。 および「、」。

最初のケースでは、システムが電話番号に区切り文字「;」を検出すると、ダイヤルが停止し、内線番号の数字が画面に表示されます。 それらをクリックすると、ダイヤルが続行されます。

2番目のケースでは、システムが電話番号に区切り文字「、」を検出すると、この時点でダイヤルが停止し、約2秒の短い一時停止後に自動的に続行します。 視覚的な区切り文字「、」は、「,,,,」のように単一ではない場合があります。 この場合、一時停止の期間は文字数に比例して長くなります。

RFC 3966で規制されている「; ext = "」形式の区切り記号が表示される場合、次のようになります。システムは記号「;」を取ります。 内線番号をダイヤルする前にブレークポイントごとに、「内線」記号は内線番号が始まる数字として解釈されます。

---

そのため、理論的および実用的な前提条件を検討し、記事の2番目の部分、つまり電話番号の取得と検証に適した正規表現に進むことができます。

この資料がお役に立てば幸いです。MSLibraryfor iOSチーム

その他の記事：
iOSなどの正規表現を使用した電話番号のキャプチャと検証...パート2
iOSなどで、ビットマスクを使用して複数の条件を実装する...
簡単：iOSだけでなく、文字列から不要な文字を削除します...
Xcodeでのクロスプラットフォーム（ユニバーサル）ライブラリの作成とコンパイル