le numéro de téléphone doit être une chaîne ou un type numérique pouvant enregistrer le numéro de téléphone?
Nous voulons stocker le numéro de téléphone mobile à 10 chiffres, c'est-à-dire 9999999999. Doit-il s'agir d'un type de données numérique ou chaîne? Nous ne voulons faire aucune opération de calcul ou de manipulation sur ce
Quelle est la meilleure mémoire et les meilleures performances?
Recommandation UIT-T E.164 indique que vous avez besoin de 3 chiffres pour le code du pays et jusqu'à 15 chiffres pour le numéro d'annuaire dans le plan de numérotation du pays.
Et, beaucoup de gens ajoutent de la ponctuation. Par exemple:
+1.212.555.1212 est un numéro nord-américain. Il pourrait également être rendu (212) 555-1212 dans une application centrée sur l'Amérique du Nord.
32 caractères de texte devraient faire l'affaire dans le monde entier.
N'utilisez PAS de numéro, sinon vous serez désolé. J'étais: deux choses.
- Nous avons perdu des affaires européennes pour une entreprise parce que nous supposions que tous les numéros de téléphone étaient conformes au NANP numéros à dix chiffres.
- Une exportation de feuille de calcul a rendu les nombres en notation scientifique
2.12555E+09C'est presque aussi stupide que SIRI me dit vous avez appelé de deux milliards, cent vingt cinq millions ....
Les numéros d'annuaire téléphonique ne sont pas des types de données numériques. Jetez un œil à ceci: Les programmeurs des faussetés croient aux numéros de téléphone .
Il doit s'agir d'un string, car le numéro de téléphone dépassera la limite de int ou même long. Donc, pour gérer ces scénarios, string est toujours préférable.
Quelques choses qu'il est bon de garder à l'esprit:
En général, un nombre sur lequel vous ne prévoyez pas de faire de calculs doit être stocké sous forme de chaîne. Si vous avez besoin du numéro pour pouvoir commencer par un zéro (comme vous le faites, car certains numéros de téléphone le font), cela est essentiel.
Ergo, même si (ou quand) vous êtes en mesure de stocker un numéro de téléphone sous la forme d'un énorme entier (vous pouvez le faire avec des entiers 64 bits), vous ne devriez pas. Vous perdrez des données dès qu'un nombre commence par un zéro.
Lorsque vous enregistrez un numéro de téléphone, n'oubliez pas que le code de pays est un type spécial d'informations. Vous feriez mieux de le séparer du reste du nombre lorsque vous le stockez. De cette façon, vous pouvez facilement interroger les numéros de téléphone par pays et vous n'aurez pas à analyser le numéro plus d'une fois (avant de le stocker, plutôt qu'à chaque fois que vous le récupérez). De plus, si vous stockez un numéro de téléphone avec le code du pays, vous devrez valider la chose pour vous assurer que vous toujours stockez le code du pays, car deux numéros de deux pays différents pourraient potentiellement être identique si l'un a un code de pays et l'autre pas.
N'oubliez pas non plus que la ponctuation est une méthode de présentation et n'a donc rien à voir avec la façon dont vous stockez les données. Vous pouvez toujours choisir de présenter les données comme vous le souhaitez, et la façon dont vous voulez dépendra dans tous les cas d'un certain nombre de facteurs. Par exemple, quel type de données vous présentez, à qui vous les présentez, et dans certains cas même quand vous présentez les données. Dans le cas des numéros de téléphone, vous devez stocker le numéro sous forme de chaîne, sans aucune ponctuation.
Je vous recommande de consulter la bibliothèque de Google pour analyser, formater et valider les numéros de téléphone internationaux ( https://github.com/googlei18n/libphonenumber ). Vous pouvez fournir à cette bibliothèque votre numéro de téléphone et votre code de pays, et cela vous donnera beaucoup d'informations utiles à ce sujet, comme si le numéro est possible et valide, à quelle région il appartient, de quel type de numéro il s'agit, etc. .
Astuce Pro I: Fournissez à vos utilisateurs un moyen de sélectionner le pays auquel le numéro appartient, plutôt que de les faire taper le code du pays. Mieux pour vous et mieux pour vos utilisateurs.
Astuce Pro II: Il existe rarement une "application centrée en Amérique du Nord" ou "insérer une application centrée ici", surtout si votre application est disponible sur le Web. Cela arrive, mais c'est rare, il serait donc sage de préparer votre application pour le monde, plutôt qu'une petite partie de celle-ci.