-
-
Save gerardorochin/5718313 to your computer and use it in GitHub Desktop.
/^([A-Z,Ñ,&]{3,4}([0-9]{2})(0[1-9]|1[0-2])(0[1-9]|1[0-9]|2[0-9]|3[0-1])[A-Z|\d]{3})$/ |
^([A-ZÑ\x26]{3,4}([0-9]{2})(0[1-9]|1[0-2])(0[1-9]|1[0-9]|2[0-9]|3[0-1]))((-)?([A-Z\d]{3}))?$
Basado en el que publicó @unjordi
Mucha gente escribe un guión entre el rfc y la homoclave
Valida:
ORP830422DI6
ORP830422-DI6
ORP830422
según un documento publicado por el SAT, hay ciertas consideraciones, tanto los 2 dígitos de la homonimia, como el dígito verificador que solo tiene 3 opciones, una de ellas es que solo puede ser la letra A.
en fin, anexo el regex que actualmente utilizo en 2018
'^([A-ZÑ\x26]{3,4}([0-9]{2})(0[1-9]|1[0-2])(0[1-9]|1[0-9]|2[0-9]|3[0-1])([A-Z]|[0-9]){2}([A]|[0-9]){1})?$';
las empresas utilizan rfc solamente 3 letras al inicio con un total de 12 caracteres, como puedo codificarla para dicho funcionamiento?
muchas gracias
Probad esta otra:
^(([ÑA-Z|ña-z|&]{3}|[A-Z|a-z]{4})\d{2}((0[1-9]|1[012])(0[1-9]|1\d|2[0-8])|(0[13456789]|1[012])(29|30)|(0[13578]|1[02])31)(\w{2})([A|a|0-9]{1}))$|^(([ÑA-Z|ña-z|&]{3}|[A-Z|a-z]{4})([02468][048]|[13579][26])0229)(\w{2})([A|a|0-9]{1})$
Fuente: http://www.regexlib.com/REDetails.aspx?regexp_id=3455
El codigo alfanumerico de 3 letras no incluye la ñ, esta es solamente para los nombres/apellidos, por lo tanto podría quedar como:
/^[ña-z]{3,4}[0-9]{6}[0-9a-z]{3}$/i
# | Nombre 3/4 |fecha 6| code 3 |
El codigo alfanumerico de 3 letras no incluye la ñ, esta es solamente para los nombres/apellidos, por lo tanto podría quedar como:
/^[ña-z]{3,4}[0-9]{6}[0-9a-z]{3}$/i # | Nombre 3/4 |fecha 6| code 3 |
gracias!
Hola, yo tengo varias Expresiones regulares, las explico en mi entrada de blog, pero te dejo acá los ejemplos:
Versión oficial del SAT
^[A-Z&Ñ]{3,4}[0-9]{2}(0[1-9]|1[012])(0[1-9]|[12][0-9]|3[01])[A-Z0-9]{2}[0-9A]$
Versión reducida de la versión oficial del SAT
^[A-Za-zñÑ&]{3,4}\d{6}\w{3}$
Versión siguiendo al pie de la letra las instrucciones del SAT, esta versión no permite la entrada de fechas incorrectas ni de años bisiestos erróneos , de igual manera impide un RFC con palabras altisonantes, el problema es que en la práctica, existen RFC con palabras altisonantes y con fechas mal formadas.
^(((?!(([CcKk][Aa][CcKkGg][AaOo])|([Bb][Uu][Ee][YyIi])|([Kk][Oo](([Gg][Ee])|([Jj][Oo])))|([Cc][Oo](([Gg][Ee])|([Jj][AaEeIiOo])))|([QqCcKk][Uu][Ll][Oo])|((([Ff][Ee])|([Jj][Oo])|([Pp][Uu]))[Tt][Oo])|([Rr][Uu][Ii][Nn])|([Gg][Uu][Ee][Yy])|((([Pp][Uu])|([Rr][Aa]))[Tt][Aa])|([Pp][Ee](([Dd][Oo])|([Dd][Aa])|([Nn][Ee])))|([Mm](([Aa][Mm][OoEe])|([Ee][Aa][SsRr])|([Ii][Oo][Nn])|([Uu][Ll][Aa])|([Ee][Oo][Nn])|([Oo][Cc][Oo])))))[A-Za-zñÑ&][aeiouAEIOUxX]?[A-Za-zñÑ&]{2}(((([02468][048])|([13579][26]))0229)|(\d{2})((02((0[1-9])|1\d|2[0-8]))|((((0[13456789])|1[012]))((0[1-9])|((1|2)\d)|30))|(((0[13578])|(1[02]))31)))[a-zA-Z1-9]{2}[\dAa])|([Xx][AaEe][Xx]{2}010101000))$
Versión de validación caracter por caracter, esta ER es recomendable cuando se quiera validar mientras el usario tipea
^[A-Za-zñÑ&]{1,2}([A-Za-zñÑ&]([A-Za-zñÑ&](\d(\d(\d(\d(\d(\d(\w(\w(\w)?)?)?)?)?)?)?)?)?)?)?$
Fuente: https://luisenriquech.blogspot.com/2022/04/expresion-regular-de-rfc-mexico.html
Fuente: https://luisenriquech.blogspot.com/2022/04/expresion-regular-de-rfc-mexico.html
Vaya de expresión regular!,
La verdad yo veo la expresión regular como un mecanismo de validar el formato del string.
Para una validación mas compleja del año/mes/día o si es bisiesto creo que hay varias librerías que te permiten hacer esto.
Meter una expresión regular que hardcodea esta lógica a un proyecto desde mi punto de vista es meter un monolito en forma de regex
.
Dicho esto creo que una mejor solución es desde una regex, extraer cada parte que conforman el RFC para analizarla cada parte de estas.
- 3 o 4 caracteres el nombre o razón social (
([a-z]{3,4})
). - 2 dígitos año de nacimiento(o conformación de la empresa) (
\d{2}
). - 2 dígitos mes de nacimiento(o conformación de la empresa)(
\d{2}
). - 2 dígitos día de nacimiento(o conformación de la empresa)(
\d{2}
). - 3 caracteres que conforman la homoclave (
[0-9a-z]{3}
).
Definiendo la expresión regular /^([a-z]{3,4})(\d{2})(\d{2})(\d{2})([0-9a-z]{3})$/i
con el método match
podemos extraer cada parte para ser analizada cada una por su parte.
De esta forma en el resultado en la posición 1 tendríamos la parte del nombre, el cual podríamos validar para ver si no es una palabra altisonante.
Un ejemplo famoso es el caso del RFC del ex-presidente Enrique Peña Nieto.
Aqui quisiera tratar el punto de:
6.- Si de las cuatro letras resulta una palabra altisonante, la segunda letra será sustituida por una "X".
Si lo pensamos este RFC debería empezar con PENE.
const rfc = "PENE660720DI6"
const reg = /^([a-z]{3,4})(\d{2})(\d{2})(\d{2})([0-9a-z]{3})$/i
rfc.match(reg)
Resultado:
[
'PENE660720DI6',
'PENE',
'66',
'07',
'20',
'DI6'
]
Ahora lo siguiente sería validar cada parte, como comentaba lo de las fechas es algo trivial en el sentido que hay múltiples soluciones del mismo.
Respecto a las palabras anti-sonantes se puede definir un diccionario de estos(si existe uno oficial favor de compartir) y si la parte que se conformo con el nombre/razón social pertenece a esta lista tendríamos que remplazar el segundo carácter por una X, como lo muestro a continuación:
'PENE'.replace(/^(\w)\w/, '$1X') // resultado PXNE
Dicho todo esto, hice una función denominada metaRFC que para un RFC especifico devuelve la información siguiente:
const rfc = "PENE660720DI6"
metaRFC(rfc)
Resultado
{
rfc_input: 'PENE660720DI6',
nombre_parte: 'PXNE',
fecha_nacimiento_anio: '66',
fecha_nacimiento_mes: '07',
fecha_nacimiento_dia: '20',
homoclave: 'DI6',
tipo_persona: 'física',
valido: false,
longitud: 13,
msg: 'Error de formato'
}
De momento metí una lista negra de malas palabras, faltaría validar las fechas y demás opciones, pensaría en agregar las demás características y como la lógica es mas compleja que la de una expresión regular, decidí crear un propio issue ojala se puedan sumar a la discusión por ahí.
👉 https://gist.github.com/fitorec/02638492300d361cd2451a8a03d99522
^([A-ZÑ\x26]{3,4}([0-9]{2})(0[1-9]|1[0-2])(0[1-9]|1[0-9]|2[0-9]|3[0-1]))([A-Z\d]{3})?$
Cuales son las ventajas de esta regex en comparacion con la que está en xsd del sat:
Permite el ingreso del caracter ampersand (&) correctamente.
Valida desde 00 hasta 99 años
Valida meses de 01 a 12
Valida dias de 01 a 31
Opcional el ingreso de la homoclave.
Desarrollada por InvoiceOne.com.mx
encontrada en http://validacfd.com/phpbb3/viewtopic.php?t=1978