Ir al contenido principal

Regex en .NET con C sharp

¿Qué es Regex?

Regex (abreviatura de Regular Expressions) es una herramienta para procesar texto basándose en patrones predefinidos. Es especialmente útil para implementar validaciones en los datos que recibimos, ya sea de otros sistemas o de los usuarios a través de la interfaz de la UI. Su uso nos permite identificar, extraer, reemplazar o validar datos de manera eficiente, como números, correos electrónicos (emails), fechas, entre otros.

En C#, es posible validar ya sea un teléfono, un correo electrónico o cualquier input digitado por un usuario para evitar inconsistencias en nuestro modelo o base de datos, por ejemplo, desde Visual Studio. 

Para esto vamos a utilizar la operación IsMatch(param1, param2) de la clase Regex de la librería System.Text.RegularExpressions.

¿Qué nos devuelve esta operación? Este método devuelve un valor booleano (true o false) indicando si hay coincidencia o no.

Parámetros

  • input (param1): La cadena que se desea validar o buscar coincidencias.
  • pattern (param2): La expresión regular que define el patrón contra el cual se evaluará la cadena.

Retorno

  • Devuelve true si la cadena cumple con el patrón especificado.
  • Devuelve false si no hay coincidencia.

La biblioteca RegularExpressions es nativa, lo que significa que está incluida en el Framework de .NET o .NET Core/5+ sin necesidad de instalar paquetes adicionales o de terceros. 

Si se utiliza Visual Studio como entorno de desarrollo, no es necesario descargar o configurar nada extra; simplemente se debe usar el espacio de nombres al inicio del archivo y de esa forma ya es posible trabajar con expresiones regulares directamente.

Using:

    using System.Text.RegularExpressions;

Una vez que hicimos el using, podemos aplicarlo a una clase de la siguiente manera. Supongamos que tenemos la clase [Cliente] con los atributos, documento, nombre y teléfono.

Desde las propiedades de esa clase, podemos validar dichos atributos de la siguiente manera:

// Ejemplo para documento
public string Cedula
{
    get { return cedula; }
    set
    {
        if(Regex.IsMatch(value, "[0-6]{1}[0-9]{3}[0-9]{3}[0-9]{1}"))
        {
            cedula = value;
        }
        else
        {
            throw new Exception("La cédula del cliente no es válida.");
        }   
    }
}

Observemos el patrón que le indicamos a la operación IsMatch() en el segundo parámetro.

Lo que estamos especificando entre los paréntesis rectos o corchetes [0-6], es un rango de valores que el CLR de .NET deberá comparar para validar nuestra cadena. En el caso del primer corchete, tenemos valores que van del 0 al 6. Es decir que todos los enteros comprendidos entre el 0 y el 6 son permitidos. 

Seguido a los paréntesis rectos, tenemos un par de llaves {1} que reciben por valor una cantidad de lo que le precede, [0-6]{1} ->  dicho en otras palabras, admite un dígito del 0 al 6 y sólo un dígito en esa posición.

Si combinamos el resto de indicadores del patrón, podemos entonces validar una cédula (documento Uruguayo ej: 4.745.346-8) especificando valor y rango.

Tabla de referencia

    [] - Paréntesis rectos permiten definir rangos que refieren a un lugar del string.

Ejemplo con números [0-9]

Ejemplo con letras [a-z] o [A-Z] (minúsculas y mayúsculas)

Ejemplo con caracteres especiales [./%&-]

Este es un ejemplo con las posibles combinaciones para validar el atributo nombre:

// Ejemplo para nombres y apellidos
public string Nombre
{
    get { return nombre; }
    set
    {
        if(Regex.IsMatch(value, "[A-Za-z áéíóúÁÉÍÓÚñÑüÜ]{3,60}"))
        {
            nombre = value;
        }
        else
        {
            throw new Exception
            ("El nombre del cliente contiene carácteres inválidos.");
        }
    }
}

Este patrón, coincidirá con los siguientes caracteres:

  • Letra mayúscula o minúscula del alfabeto (A-Z, a-z).
  • Vocales con tilde (áéíóúÁÉÍÓÚ).
  • Letras específicas como ñÑ y üÜ.
  • Espacios en blanco, ya que se añadió un espacio dentro de los corchetes.
Hay que tener presente que no es lo mismo definir un espacio literal en el patrón o un \s.

El metacaracter \s representa cualquier tipo de carácter de espacio en blanco y no es lo mismo que un espacio literal ya que incluye:

  • Espacio en blanco ( ).
  • Tabulación (\t).
  • Retorno de carro (\r).
  • Nueva línea (\n).
  • Avance de página (\f).

No son equivalentes, ya que el espacio literal solo coincide con un espacio regular, mientras que \s es más amplio y cubre otros tipos de espacios. Dependiendo del contexto, esposible elegir entre uno u otro.

Además, en las llaves esta vez tenemos una cantidad mínima requerida (3) y máxima (60) con la especificación {3,60}. Esto se traduce a que los nombres admitidos serán los comprendidos entre 3 y 60 carácteres máximo.

Patrón Número de teléfono

Aca tenemos algunos otros ejemplos de validaciones más comunes:

// Ejemplo para números de teléfono de Uruguay
public string Telefono
{
    get { return nroTelefono; }
    set
    {
        if(Regex.IsMatch(value, "^[1-9][0-9]{7}$") ||
           Regex.IsMatch(value, "^0[1-9][0-9]{7}$"))
        {
            nroTelefono= value;
        }        else
        {
            throw new Exception("El nro. de teléfono no es válido.");
        }
    }
}

En este caso, tenemos los caracteres ^ y $ al principio y al fin de la expresión ya que definen el inicio y el final de una cadena, respectivamente. Esto asegura que el patrón coincida con toda la cadena y no solo con una parte de ella.

En este caso, la expresión del primer Regex asegura que:

  • La cadena comienza con un número entre 1 y 9.
  • Le siguen exactamente 7 dígitos numéricos ([0-9]{7}).
  • La cadena termina justo después de esos 8 caracteres.

Algunos ejemplos válidos podrían ser:

  • 22345678
  • 98765432

Ejemplos no válidos:

  • 01234567 (no empieza con 1-9).
  • 1234567 (solo tiene 7 dígitos).
  • 123456789 (tiene más de 8 dígitos).
  • 12345678abc (tiene caracteres adicionales al final).

La segunda expresión admite números celulares Uruguayos del tipo 099, 098, 091, etc.

Patrón Tarjeta de Crédito

// Ejemplo para limitar cantidad de caracteres en una tarjeta de crédito
public string NroTarjeta
{
    get { return nroTarCredito; }
    set
    {
        if(Regex.IsMatch(value, "[0-9]{4}[0-9]{4}[0-9]{4}[0-9]{4}"))
        {
            nroTarCredito=value;
        }
        else
        {
            throw new Exception("El nro. de tarjeta no es válido.");
        }
    }
}

Más patrones:

1. Un nombre de usuario que puede tener únicamente 8 caracteres de longitud:

    "^.{8}$"

El punto (.) en este caso, es un comodín que coincide con cualquier carácter, excepto los saltos de línea.

2. Un nombre especial que puede tener únicamente 10 caracteres de longitud compuesto solo de letras (minúsculas y mayúsculas) y números:

    "^[a-zA-Z0-9]{10}$"

3. Un ejemplo para email:

    "^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$"

  • [a-zA-Z0-9._-]+: Permite una o más letras (mayúsculas o minúsculas), números, puntos (.), guiones bajos (_) y guiones (-) como parte del usuario del email.
  • +@: Requiere que el símbolo @ esté presente.
  • [a-zA-Z0-9.-]+: Permite una o más letras, números, puntos o guiones en el dominio.
  • \.: Asegura que haya al menos un punto en el dominio.
  • [a-zA-Z]{2,}: Requiere que la extensión del dominio tenga al menos dos caracteres (como .com, .org, .io, .co).
En este caso puntual, estamos utilizando el cuantificador + que se aplica al carácter que le precede y quiere decir "una o más veces", pero no vacío.

Cuantificadores
  • * : Cero o más veces.
    • Ejemplo: a* coincide con "" (vacío), a, aa, aaa, etc.
  • + : Una o más veces.
    • Ejemplo: a+ coincide con a, aa, aaa, pero no con "".
  • ?: Cero o una vez.
    • Ejemplo: a? coincide con "" o a.

Herramienta en línea para Regex

Regex101.com es una herramienta en línea que te permite escribir, probar y analizar expresiones regulares de manera interactiva y en tiempo real. Es muy útil para aprender, depurar y optimizar las expresiones que estás probando.

¿Cómo se usa?

  1. Seleccionar el lenguaje en el menú desplegable.
  2. Escribí tu expresión regex en el cuadro superior.
  3. Tipear el texto que querés probar en el cuadro inferior como entrada.
  4. Ponerse a probar expresiones.
Etiquetas:
Ubicación: Uruguay

Otros artículos

Principio de Responsabilidad Única (SRP) – SOLID explicado con ejemplos

Introducción a S.O.L.I.D En esta entrada, intentaremos abordar un nuevo ciclo de conceptos que tienen que ver sobre los principios SOLID , que son fundamentales en la programación orientada a objetos o POO . Estos principios fueron formulados, en principio, por Robert C. Martin , también conocido como " Uncle Bob ", con el objetivo de mejorar la mantenibilidad y escalabilidad del código de software. SOLID es un acrónimo que representa cinco principios de diseño: Single Responsibility Principle (SRP) – Principio de Responsabilidad Única Open/Closed Principle (OCP) – Principio de Abierto/Cerrado Liskov Substitution Principle (LSP ) – Principio de Sustitución de Liskov Interface Segregation Principle (ISP) – Principio de Segregación de Interfaces Dependency Inversion Principle (DIP) – Principio de Inversión de Dependencias Estos principios nos ayudan a crear software más ...
Más entradas »

Open/Closed Principle (OCP) – SOLID explicado con ejemplos

Continuando con el repaso de los principios de S.O.L.I.D. que inició en el hilo anterior - si no lo viste hacé click acá  Principio de Responsabilidad Única (SRP) - vamos a ver el segundo en orden de aparición: Principio de Abierto/Cerrado (OCP por sus siglas en inglés). Definición Formal El principio OCP (Open/Closed Principle) establece que el código de una clase o un módulo debe estar abierto para la extensión, pero cerrado para la modificación. Esto significa que no se deben realizar cambios en el código existente cuando se requiere alterar alguna funcionalidad. En lugar de modificar el código existente, se debe crear una nueva implementación que extienda la funcionalidad. La única excepción a esto son los arreglos de bugs, donde está permitido modificar el código existente. Si se desea introducir una nueva funcionalidad, como la ordenación en un método existente, en lugar de modificar el código, se crearía una nueva implementación q...
Más entradas »

Guía Completa para Crear un README.md Profesional en GitHub

¿Qué es un README.md y por qué es importante? El archivo README.md es la primera impresión que un desarrollador obtiene al visitar un repositorio en GitHub que hayas creado. Sirve como documentación principal de un proyecto, proporcionando información sobre su propósito, estructura y uso. Un README.md bien elaborado puede mejorar la comprensión del proyecto, facilitar la colaboración y también atraer contribuyentes. Estructura recomendada de un README.md Una estructura comúnmente utilizada para hacer que tu README.md sea claro, informativo y atractivo: 1. Título y Descripción El título debe ser claro y descriptivo. Pensalo también, como un término de búsqueda que alguien podría buscar en Google. Luego, una breve explicación del proyecto: # Nombre del Proyecto Una breve descripción sobre qué hace tu proyecto. 2. Insignias (Badges) Podés agregar insignias para indicar el estado del build, cobertura de pruebas, licencias, entre otros: !...
Más entradas »

Principio de Segregación de Interfaces (ISP) – SOLID explicado con ejemplos

El Principio de Segregación de Interfaces es otro de los principios SOLID y establece que: Una clase no debería verse obligada a depender de métodos que no utiliza .  En otras palabras, en lugar de crear una interfaz grande con muchos métodos, es mejor dividirla (segregar) en interfaces más pequeñas y específicas. Pero.. ¿Por qué? Obliga a implementar métodos innecesarios Si una clase solo necesita una "parte" de la funcionalidad de una interfaz, pero esta interfaz es muy grande, se va a ver obligada a implementar métodos que no usa. Esto es casi que inevitable si no buscamos la manera de separar mejor las responsabilidades. Imaginemos una interfaz IVehiculo que tiene los siguientes métodos: public interface IVehiculo { void Conducir () ; void Volar () ; void Navegar () ; } Si una clase Auto implementa esta interfaz, se ve obligado a definir métodos como Volar() o Navegar() , aunque un auto no vuela ni navega. public c...
Más entradas »

Principio de Sustitución de Liskov (LSP) – SOLID explicado con ejemplos

¿Qué es el Principio de Sustitución de Liskov? Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base). El Principio de Sustitución de Liskov ( LSP ) es el tercer principio de SOLID , representado por la letra L y establece que: Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa. En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada. ¿Quién es Bárbara Liskov? Bárbara Liskov es una destacada científi...
Más entradas »

Principio de Inversión de Dependencia (DIP) – SOLID explicado con ejemplos

Estamos cerrando este ciclo de definiciones para SOLID , y en esta entrada vamos a dar un vistazo al último principio de la lista: DIP o Dependency Inversion Principle . El Principio de Inversión de Dependencia (DIP) establece que: Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones. Las abstracciones no deben depender de los detalles. Los detalles deben depender de las abstracciones. El Problema de la Dependencia Directa Imaginate que estás construyendo una aplicación que envía notificaciones. Para empezar rápido, decidís crear un controlador que usa directamente un servicio de correo electrónico: public class NotificationController { private EmailNotificationService _service = new EmailNotificationService (); // Acá tenemos dependencia directa } Al principio, todo parece estar bien. El controlador puede enviar correos sin problema. Pero luego surge un requisito: ta...
Más entradas »