Aparte de todas las otras respuestas correctas, el almacenamiento de números de teléfono como números enteros o de otra manera excluyendo formatear puede ser una mala idea.
Aquí hay un par de consideraciones:
- Los usuarios pueden proporcionar números de teléfono internacionales que no se ajusten a sus expectativas. See these examples Por lo tanto, las agrupaciones habituales para los números estándar de EE. UU. No encajarían.
- Es posible que los usuarios NECESITAN proporcionar una extensión, por ejemplo,
(555) 555-5555 ext#343
La clave #
está realmente en el marcador/teléfono, pero no se puede codificar en un número entero. Los usuarios también pueden necesitar suministrar la clave *
.
- Algunos dispositivos le permiten insertar pausas (generalmente con el carácter
P
), que pueden ser necesarias para extensiones o sistemas de menús, o para marcar en ciertos sistemas telefónicos (por ejemplo, en el extranjero). Estos tampoco pueden codificarse como enteros.
[EDIT]
Podría ser una buena idea para almacenar tanto una versión número entero y una versión de cadena en la base de datos. Además, al almacenar cadenas, puede reducir toda la puntuación a espacios en blanco utilizando uno de los métodos mencionados anteriormente. Una expresión regular para este podría ser:
// (222) 222-2222 ext# 333 -> 222 222 2222 # 333
phoneString = Regex.Replace(phoneString, @"[^\d#*P]", " ");
// (222) 222-2222 ext# 333 -> 2222222222333 (information lost)
phoneNumber = Regex.Replace(phoneString, @"[^\d]", "");
// you could try to avoid losing "ext" strings as in (222) 222-2222 ext.333 thus:
phoneString = Regex.Replace(phoneString, @"ex\w+", "#");
phoneString = Regex.Replace(phoneString, @"[^\d#*P]", " ");
Por cierto, Int.Parse no es parte de C# –
Err, entonces ¿por qué está documentado? http://msdn.microsoft.com/en-us/library/system.int32.parse.aspx –
John Saunders simplemente está equivocado. – Timwi