Establecer reglas de nombres de archivos para el equipo y comprobarlos con Python
Define una convención sencilla de nombres de archivo para el equipo, pruébala en una carpeta sintética y crea un informe de revisión sin renombrar ni eliminar nada. El comprobador separa errores estructurales, fechas no válidas y extensiones no admitidas.
Contenido revisado 2026.09.20Incluye archivos de ejemplo
Ver el índice
La traducción se ha realizado con IA. Comprueba el código, las unidades y los valores junto con el original. La revisión por hablantes nativos de cada idioma aún no se ha completado. English
Para quién esEsta guía está dirigida a equipos que quieren nombres de archivo predecibles y una comprobación automática sencilla antes de compartir o archivar archivos.
Preparación
Python 3.12 y un comando de terminal que inicie esa versión.
Una carpeta de trabajo donde los scripts puedan crear carpetas dentro de outputs.
Acuerdo sobre los project codes, document labels, version format y allowed extensions que utilizará el equipo.
Solo se requiere la biblioteca estándar de Python: csv, datetime, pathlib y re.
01Escribir la convención de nombres antes de crear el comprobador
Este ejemplo utiliza el formato YYYYMMDD_project_document_vNN.ext. La date tiene ocho dígitos y debe ser una fecha real del calendario. project y document utilizan letras minúsculas o dígitos, opcionalmente separados por guiones. La version es v seguida de exactamente dos dígitos. Las allowed extensions son pdf, docx, xlsx, csv y txt.
Usa la fecha de trabajo relevante del archivo como YYYYMMDD.
Utiliza project y document tokens en minúsculas.
Usa underscores únicamente entre las cuatro partes principales del filename.
Utiliza v01, v02, etc. para versions en lugar de final, latest, new o revised.
Conserva la file extension original y restríngela a una lista acordada.
02Crear una carpeta sintética con nombres válidos e inválidos
Los filenames siguientes son sintéticos y fueron creados específicamente para este artículo. Guarda el script de preparación como create_file_naming_demo.py. Crea ocho archivos vacíos; cuatro siguen la regla y cuatro la incumplen deliberadamente.
python
from pathlib import Path
SOURCE = Path("outputs") / "file_naming_demo"
FILENAMES = [
"20260920_alpha_test-plan_v01.pdf",
"20260920_alpha_results_v02.csv",
"20260921_beta_meeting-notes_v03.txt",
"20261001_beta_budget_v01.xlsx",
"2026-09-20_alpha_notes_v01.txt",
"20260920_Alpha_notes_v01.txt",
"20260920_alpha_notes_final.txt",
"20260230_beta_results_v01.csv",
]
SOURCE.parent.mkdir(parents=True, exist_ok=True)
SOURCE.mkdir() # Stop if the synthetic source already exists.
for filename in FILENAMES:
target = SOURCE / filename
with target.open("xb"):
pass
Se espera que los primeros cuatro names pasen. El quinto utiliza una hyphenated date en lugar de YYYYMMDD. El sexto contiene un uppercase project token. El séptimo utiliza final en lugar de vNN. El octavo tiene la forma correcta, pero contiene la fecha imposible 2026-02-30.
03Clasificar manualmente los ocho nombres
Filename
Status esperado
Motivo
20260920_alpha_test-plan_v01.pdf
PASS
Coincide con la estructura y la date es válida
20260920_alpha_results_v02.csv
PASS
Coincide con la estructura y la date es válida
20260921_beta_meeting-notes_v03.txt
PASS
Coincide con la estructura y la date es válida
20261001_beta_budget_v01.xlsx
PASS
Coincide con la estructura y la date es válida
2026-09-20_alpha_notes_v01.txt
FAIL
STRUCTURE_ERROR
20260920_Alpha_notes_v01.txt
FAIL
STRUCTURE_ERROR
20260920_alpha_notes_final.txt
FAIL
STRUCTURE_ERROR
20260230_beta_results_v01.csv
FAIL
INVALID_DATE
Por tanto, los totales esperados son 8 files checked, 4 passes y 4 failures. Tres failures son structural y uno tiene un filename estructuralmente válido pero una calendar date no válida.
04Comprobar filenames sin renombrarlos
Guarda el script siguiente como check_file_names.py. Solo lee filenames y escribe un informe CSV en una output folder separada. No renombra, mueve, edita ni elimina ningún source file.
python
import csv
import re
from datetime import datetime
from pathlib import Path
SOURCE = Path("outputs") / "file_naming_demo"
OUTPUT_DIR = Path("outputs") / "file_naming_result"
REPORT = OUTPUT_DIR / "file_naming_report.csv"
ALLOWED_EXTENSIONS = {"pdf", "docx", "xlsx", "csv", "txt"}
NAME_PATTERN = re.compile(
r"^(?P<date>[0-9]{8})_"
r"(?P<project>[a-z0-9]+(?:-[a-z0-9]+)*)_"
r"(?P<document>[a-z0-9]+(?:-[a-z0-9]+)*)_"
r"(?P<version>v[0-9]{2})\."
r"(?P<extension>[a-z0-9]+)$"
)
def check_filename(filename: str) -> tuple[str, str]:
match = NAME_PATTERN.fullmatch(filename)
if match is None:
return "FAIL", "STRUCTURE_ERROR"
extension = match.group("extension")
if extension not in ALLOWED_EXTENSIONS:
return "FAIL", "UNSUPPORTED_EXTENSION"
try:
datetime.strptime(match.group("date"), "%Y%m%d")
except ValueError:
return "FAIL", "INVALID_DATE"
return "PASS", ""
def main() -> None:
if not SOURCE.is_dir():
raise FileNotFoundError(f"Source folder not found: {SOURCE}")
if OUTPUT_DIR.exists():
raise FileExistsError(f"Output folder already exists: {OUTPUT_DIR}")
files = sorted(path for path in SOURCE.iterdir() if path.is_file())
results = []
for path in files:
status, issue = check_filename(path.name)
results.append({
"filename": path.name,
"status": status,
"issue": issue,
})
OUTPUT_DIR.parent.mkdir(parents=True, exist_ok=True)
OUTPUT_DIR.mkdir()
with REPORT.open("x", encoding="utf-8", newline="") as stream:
writer = csv.DictWriter(
stream,
fieldnames=["filename", "status", "issue"],
)
writer.writeheader()
writer.writerows(results)
passed = sum(row["status"] == "PASS" for row in results)
failed = len(results) - passed
print(f"Files checked: {len(results)}.")
print(f"Passed: {passed}; failed: {failed}.")
print(f"Report: {REPORT.as_posix()}")
if __name__ == "__main__":
main()
text
python check_file_names.py
05Comparar el informe esperado
El report debería contener una fila por cada source file. Como los filenames se ordenan alfabéticamente antes de comprobarlos, el output order sigue los sorted names en lugar de la lista del setup script.
Recuento esperado
Valor
Files checked
8
PASS
4
FAIL
4
STRUCTURE_ERROR
3
INVALID_DATE
1
La salida de consola esperada que aparece a continuación se obtuvo manualmente a partir de los synthetic filenames y el checker. No es un execution log capturado.
Confirma que los cuatro valid names previstos reciban PASS.
Confirma que 20260230_beta_results_v01.csv se rechace aunque su text shape coincida con la regex.
Decide quién puede renombrar shared files antes de corregir nada.
Comprueba links, scripts, CAD references, document references o shared-drive shortcuts que puedan depender de los filenames actuales.
Ejecuta de nuevo el checker sin cambiar OUTPUT_DIR. Debería detenerse con FileExistsError en lugar de sustituir el report anterior.
Problema
Qué comprobar
Muchos resultados STRUCTURE_ERROR
Confirma que la team rule escrita coincida con la naming practice que realmente utiliza la gente.
Uppercase o spaces aparecen con frecuencia
Decide si prohibirlos de forma coherente o revisar la rule en lugar de corregir files de forma improvisada.
Una date aparentemente válida falla
Comprueba si el texto YYYYMMDD representa una calendar date real.
Los users siguen escribiendo final o latest
Utiliza version numbers explícitos y define por separado cuándo un file pasa a ser approved o released.
Renaming rompe references
No automatices renaming hasta haber evaluado los dependent systems y links.
07Mantener las reglas de nombres útiles y no excesivamente complejas
Una filename convention no puede sustituir proper version control, document management ni metadata. Que un file se llame v03 no demuestra que su content sea más reciente que v02, que esté aprobado por la persona correcta ni que esté vinculado al project correcto.
El ejemplo comprueba únicamente files directamente dentro de una carpeta. No realiza recursive scan de subfolders, no impone uniqueness entre varios shared drives, no comprueba file contents ni verifica que el project token corresponda a un project real.
Cuando un equipo cambia su convention, registra la effective date y decide si los old files se mantienen sin cambios o se renombran. Una rule práctica debe ser lo bastante estable para que la gente la recuerde y lo bastante estricta para que los automated checks produzcan resultados útiles.
Registro de ejecución y verificación
2026-09-20 · ejemplo revisado manualmente · objetivo: Python 3.12 · biblioteca estándar: csv, datetime, pathlib, re · sin ejecución
Se clasificaron manualmente 8 synthetic filenames como 4 valid y 4 invalid.
Se identificaron tres structural failures: hyphenated date, uppercase project token y final version label.
Se confirmó mediante razonamiento de calendario que 2026-02-30 es inválida aunque 20260230 coincida con la forma de ocho dígitos.
Se obtuvieron manualmente los totales esperados de 4 PASS, 4 FAIL, 3 STRUCTURE_ERROR y 1 INVALID_DATE.
Se revisó el script para full filename matching, allowed-extension checking, calendar-date validation, output collision protection y ausencia de operaciones rename o delete.
Se obtuvo manualmente la salida de consola esperada.
Límites de la verificación
El código no fue ejecutado por el autor de esta respuesta; no se crearon files ni reports.
No se probaron recursive folders, shared-drive links, case-insensitive filesystem behavior, cross-project uniqueness ni dependent application references.
La naming convention es un ejemplo de team policy y debe adaptarse al workflow real.
Las URL de la documentación oficial se proporcionaron a partir de ubicaciones de documentación conocidas, pero no se comprobaron en línea.
Las explicaciones y los ejemplos son de elaboración propia. Puedes consultar los comportamientos y conceptos relacionados en las siguientes fuentes oficiales.
En lugar de quedarse en otro resumen de la reunión, separa el trabajo acordado de los asuntos abiertos. Convierte notas sintéticas de reunión en una lista con responsables, fechas límite, entregables y evidencias de finalización, y redacta una solicitud para IA que ayude con la misma tarea.
Gestiona cada artículo como una fila y separa redacción, revisión, aprobación y publicación. Incluye la importación de un CSV local, listas desplegables, vistas de filtro, permisos de uso compartido e historial de versiones, y establece un flujo para actualizar manualmente los archivos del sitio después de la aprobación.
Convierte notas de versión sin procesar en una entrada de changelog que separe los cambios de las acciones necesarias del usuario y de los pasos de verificación. Una actualización sintética de software muestra cómo hacer que una nota de versión sea útil para alguien que no realizó el cambio.
Convierte las notas de traspaso de un proyecto en una lista estructurada que registre qué debe transferirse, quién es responsable, dónde está almacenado y qué sigue sin resolverse. Un pequeño ejemplo sintético muestra cómo detectar responsables, ubicaciones y detalles de asuntos abiertos que faltan antes del traspaso.