Created
June 6, 2013 00:00
-
-
Save gerardorochin/5718313 to your computer and use it in GitHub Desktop.
Expresion regular para validar RFC
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| /^([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})$/ |
Hola (Después de 2 años), realmente tiene sus pros y contras meter estas
validaciones como bien dices, tal vez sí es un poco más complejo entender
las ER, pero en tiempo de ejecución llega a ser mucho más veloz, ya que
sólo es 1 validación con Match, ya no tienes que escribir:
IF CumpleConLasPrimeras4Letras
IF EsUnaFechaVálida(ParseandoEnFecha)
IF LasPrimeras4LetrasNoEstanEnElDiccionario
IF....
Y eso sólo para validar el caso de un RFC, o sea, sí puede haber quien
prefiera hacerlo con varias validaciones en Back, y quien quiera sólo
hacerlo con una ER desde Back.
De igual manera, esto se puede usar en Front con sólo el siguiente código:
<form>
<label for="codigo">Ingresa un código:</label>
<input type="text" id="codigo" name="codigo"
pattern="[A-Za-z0-9]{6,10}" <!--ER para
validar------------------------------------------------------->
title="El código debe tener entre 6 y 10 caracteres
alfanuméricos."
required>
<input type="submit" value="Enviar">
</form>
Esto a su vez minimiza código en front y Back reduciendo tantos ifs como a
sólo 1 línea de código. Pero igual siento que ambas formas son válidas para
resolverlo.
Lo único que sí, sólo quiero compartir esta información para quien necesite
utilizarla.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Libre
de virus.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
El dom, 13 oct 2024 a las 22:27, Jonathan Hinojos ***@***.***>)
escribió:
… ***@***.**** commented on this gist.
------------------------------
Hola, entiendo tu punto, en realidad esta ER la hice en mi trabajo, en una
empresa de facturación electrónica, la idea era hacer más eficientes las
validaciones desde el FrontEnd y quitar mucha lógica en el Back
(Demasiada), como resultado es la ER que viste en mi gist, el cual ya
actualicé con la lista de palabras altisonantes oficial de parte del
Gobierno (Página 62):
http://www.gobernacion.gob.mx/work/models/SEGOB/Resource/231/1/images/InstructivoParaLaCurp_v2008.pdf?fbclid=IwAR3h6pqrEAO41nh2y83myemDbNkAkKl0dBz0kp37gAru3KGfa0QTm8-a5r0
Después de probar la ER en Producción nos topamos con 2 errores (Tanto en
RFCs y CURPs) que ambos tienen palabras altisonantes y fechas como 30 de
Febrero... (Entre otros errores en RFC reales que encontramos de clientes
que emitían comprobantes). Espero que esta información sea la que deseabas.
Saludos. El jue, 28 abr 2022 a las 14:58, Miguel Angel *@*.
*>) escribió:… ***@***.***** commented on this gist.
------------------------------ 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 — Reply
to this email directly, view it on GitHub
https://gist.github.com/5718313#gistcomment-4148595, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHZCQ3HMOCDPGMYLXIY44IDVHLUVBANCNFSM5COT6NBA
. You are receiving this because you commented.Message ID:
<gerardorochin/rfc *@*.***>
-- *ICC: Luis Enrique Carbajal Hernández*
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
Libre de virus. www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
A caray, quitarle lógica al back? Y si hago el request desde postman?
—
Reply to this email directly, view it on GitHub
<https://gist.github.com/gerardorochin/5718313#gistcomment-5233513> or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHZCQ3A675CZXSKRRIF723DZ3NB2LBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFU42TOMJYGMYTHJ3UOJUWOZ3FOKTGG4TFMF2GK>
.
You are receiving this email because you commented on the thread.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>
.
--
*ICC: Luis Enrique Carbajal Hernández*
*Cel: 2224384055 *
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A caray, quitarle lógica al back? Y si hago el request desde postman?