stringtranslate.com

Nombre del archivo

Captura de pantalla de un shell de comandos de Windows que muestra nombres de archivos en un directorio
Lista de nombres de archivos, con nombres de archivos largos que contienen comas y espacios como aparecen en la pantalla del software.

Un nombre de archivo o nombre de archivo es un nombre utilizado para identificar de forma única un archivo de computadora en un sistema de archivos . Los diferentes sistemas de archivos imponen diferentes restricciones sobre la longitud de los nombres de archivos.

Un nombre de archivo puede (según el sistema de archivos) incluir:

Los componentes necesarios para identificar un archivo mediante utilidades y aplicaciones varían según el sistema operativo, al igual que la sintaxis y el formato de un nombre de archivo válido.

Los caracteres permitidos en los nombres de archivos dependen del sistema de archivos. La mayoría de los sistemas de archivos permiten las letras de la A a la Z y los dígitos del 0 al 9; Muchos sistemas de archivos admiten caracteres adicionales, como las letras a–z, caracteres especiales y otros caracteres imprimibles, como letras acentuadas, símbolos en alfabetos no romanos y símbolos en escrituras no alfabéticas. Algunos sistemas de archivos permiten que incluso caracteres no imprimibles, incluidos Bell , Null , Return y Linefeed , formen parte de un nombre de archivo, [ cita necesaria ] aunque la mayoría de las utilidades no los manejan bien.

Los nombres de archivos pueden incluir elementos como un número de revisión o generación del archivo, como un código de computadora , un número de secuencia numérica (ampliamente utilizado por las cámaras digitales a través del estándar DCF ), una fecha y hora (ampliamente utilizada por el software de la cámara de los teléfonos inteligentes y para capturas de pantalla ), y/o un comentario como el nombre de un tema o una ubicación o cualquier otro texto para facilitar la búsqueda de los archivos.

Algunas personas usan el término nombre de archivo cuando se refieren a una especificación completa de dispositivo, subdirectorios y nombre de archivo, como Windows C:\Program Files\Microsoft Games\Chess\Chess.exe . El nombre del archivo en este caso es Chess.exe . Algunas utilidades tienen configuraciones para suprimir la extensión como ocurre con MS Windows Explorer. [ no verificado en el cuerpo ]

Historia

Durante la década de 1970, algunas computadoras centrales y minicomputadoras tenían sistemas operativos donde los archivos del sistema se identificaban por un nombre de usuario o número de cuenta.

Por ejemplo, en los sistemas operativos TOPS-10 y RSTS/E de Digital Equipment Corporation , los archivos se identificaban por

En los sistemas operativos OS/VS1 , MVS y OS/390 de IBM , un nombre de archivo tenía hasta 44 caracteres y constaba de letras mayúsculas, dígitos y un punto. Un nombre de archivo debe comenzar con una letra o un número, un punto debe aparecer al menos una vez cada 8 caracteres, no pueden aparecer dos puntos consecutivos en el nombre y debe terminar con una letra o un dígito. [1] Por convención, las letras y números antes del primer período eran el número de cuenta del propietario o del proyecto al que pertenecía, pero no era necesario utilizar esta convención. [2]

En el sistema MUSIC/SP de la Universidad McGill , los nombres de archivos consistían en

El sistema operativo Univac VS/9 tenía nombres de archivos que consistían en

En 1985, RFC  959 definió oficialmente un nombre de ruta como la cadena de caracteres que un usuario debe ingresar en un sistema de archivos para identificar un archivo. [3]

En las primeras computadoras personales que usaban el sistema operativo CP/M , los nombres de archivos siempre tenían 11 caracteres. Esto se denominó nombre de archivo 8.3 con un nombre de un máximo de 8 bytes y una extensión máxima de 3 bytes. Las utilidades y aplicaciones permitían a los usuarios especificar nombres de archivos sin espacios finales e incluir un punto antes de la extensión. En realidad, el punto no se almacenó en el directorio. El uso de solo caracteres de 7 bits permitió incluir varios atributos de archivo en el nombre de archivo real mediante el uso del bit de orden superior; estos atributos incluían Sólo lectura, Archivo y Sistema. [4] Con el tiempo, esto resultó demasiado restrictivo y aumentó el número de caracteres permitidos. Los bits de atributos se movieron a un bloque especial del archivo que incluye información adicional. [ cita necesaria ]

El sistema de archivos original File Allocation Table (FAT), utilizado por Standalone Disk BASIC-80 , tenía un nombre de archivo 6.3, con un máximo de 6 bytes en el nombre y un máximo de 3 bytes en la extensión. Los sistemas de archivos FAT12 y FAT16 en IBM PC DOS / MS-DOS y Microsoft Windows anteriores a Windows 95 usaban la misma convención 8.3 que el sistema de archivos CP/M. Los sistemas de archivos FAT admitían caracteres de 8 bits, lo que les permitía admitir caracteres no ASCII en los nombres de archivos y almacenaban los atributos por separado del nombre del archivo.

Alrededor de 1995, VFAT , una extensión del sistema de archivos FAT de MS-DOS, se introdujo en Windows 95 y Windows NT . Permitía nombres de archivos largos en mayúsculas y minúsculas (LFN), utilizando caracteres Unicode , además de los nombres clásicos "8.3".

Referencias: absoluta vs relativa

Una referencia absoluta incluye todos los niveles de directorio. En algunos sistemas, una referencia de nombre de archivo que no incluye la ruta completa del directorio toma como valor predeterminado el directorio de trabajo actual . Esta es una referencia relativa. Una ventaja de utilizar una referencia relativa en scripts o archivos de configuración de programas es que diferentes instancias del script o programa pueden utilizar archivos diferentes.

Esto crea una ruta absoluta o relativa compuesta por una secuencia de nombres de archivos.

Número de nombres por archivo

Los sistemas de archivos tipo Unix permiten que un archivo tenga más de un nombre; en los sistemas de archivos tradicionales de estilo Unix, los nombres son enlaces físicos al inodo del archivo o equivalente. Windows admite enlaces físicos en sistemas de archivos NTFS y proporciona el comando fsutilen Windows XP y mklinken versiones posteriores para crearlos. [5] [6] Los enlaces físicos son diferentes de los accesos directos de Windows , los alias clásicos de Mac OS/macOS o los enlaces simbólicos . La introducción de LFN con VFAT permitió alias de nombres de archivos. Por ejemplo, longfi~1.???con un máximo de ocho más tres caracteres había un alias de nombre de archivo " long file name.???" como una forma de cumplir con las limitaciones de 8.3 para programas más antiguos.

Esta propiedad fue utilizada por el algoritmo del comando de movimiento que primero crea un segundo nombre de archivo y luego solo elimina el primer nombre de archivo.

Otros sistemas de archivos, por diseño, proporcionan solo un nombre de archivo por archivo, lo que garantiza que la alteración del archivo de un nombre de archivo no altera el archivo del otro nombre.

Restricciones de longitud

Algunos sistemas de archivos restringen la longitud de los nombres de archivos. En algunos casos, estas longitudes se aplican a todo el nombre del archivo, como en 44 caracteres en IBM z/OS . [1] En otros casos, los límites de longitud pueden aplicarse a partes particulares del nombre del archivo, como el nombre de un archivo en un directorio o el nombre de un directorio. Por ejemplo, 9 (p. ej., FAT de 8 bits en Standalone Disk BASIC ), 11 (p. ej., FAT12 , FAT16 , FAT32 en DOS), 14 (p. ej., Unix temprano), 21 ( Human68K ), 31, 30 (p. ej., Apple DOS 3.2 y 3.3), 15 (por ejemplo, Apple ProDOS ), 44 (por ejemplo, IBM S/370), [1] o 255 (por ejemplo, los primeros Berkeley Unix) caracteres o bytes. Los límites de longitud a menudo resultan de la asignación de un espacio fijo en un sistema de archivos para almacenar componentes de nombres, por lo que aumentar los límites a menudo requiere un cambio incompatible, además de reservar más espacio.

Un problema particular con los sistemas de archivos que almacenan información en directorios anidados es que es posible crear un archivo con una ruta de acceso completa que exceda los límites de implementación, ya que la verificación de longitud puede aplicarse solo a partes individuales del nombre en lugar del nombre completo. Muchas aplicaciones de Windows están limitadas a un MAX_PATHvalor de 260, pero los nombres de archivos de Windows pueden superar fácilmente este límite. [7] A partir de Windows 10, versión 1607 , se eliminaron las limitaciones de MAX_PATH. [8]

Extensiones de nombre de archivo

Los nombres de archivos en algunos sistemas de archivos, como FAT y los niveles ODS-1 y ODS-2 de Files-11 , se componen de dos partes: un nombre base o raíz y una extensión o sufijo utilizado por algunas aplicaciones para indicar el tipo de archivo . Algunos otros sistemas de archivos, como los sistemas de archivos Unix , VFAT y NTFS , tratan un nombre de archivo como una sola cadena; Una convención que se utiliza a menudo en esos sistemas de archivos es tratar los caracteres que siguen al último punto del nombre del archivo, en un nombre de archivo que contiene puntos, como la parte de extensión del nombre del archivo.

Varios archivos de salida creados por una aplicación pueden usar el mismo nombre base y varias extensiones. Por ejemplo, un compilador de Fortran podría usar la extensión FORpara el archivo de entrada fuente, OBJpara la salida del objeto y LSTpara el listado. Aunque existen algunas extensiones comunes, son arbitrarias y una aplicación diferente podría usar RELy RPT. Las extensiones han estado restringidas, al menos históricamente en algunos sistemas, a una longitud de 3 caracteres, pero en general pueden tener cualquier longitud, por ejemplo, html.

Interoperabilidad de codificación

No existe un estándar de codificación general para nombres de archivos.

Los nombres de los archivos deben intercambiarse entre entornos de software para la transferencia de archivos en red, el almacenamiento del sistema de archivos, el software de copia de seguridad y sincronización de archivos, la gestión de la configuración, la compresión y el archivado de datos, etc. Por lo tanto, es muy importante no perder la información de los nombres de los archivos entre aplicaciones. Esto llevó a una amplia adopción de Unicode como estándar para codificar nombres de archivos, aunque es posible que el software heredado no sea compatible con Unicode.

Interoperabilidad de indicación de codificación

Tradicionalmente, los nombres de archivos permitían cualquier carácter en sus nombres siempre que fueran seguros para el sistema de archivos. [9] Aunque esto permitió el uso de cualquier codificación y, por lo tanto, permitió la representación de cualquier texto local en cualquier sistema local, causó muchos problemas de interoperabilidad.

Un nombre de archivo podría almacenarse usando diferentes cadenas de bytes en distintos sistemas dentro de un solo país, como si uno usara codificación Shift JIS japonesa y otra codificación EUC japonesa . La conversión no fue posible ya que la mayoría de los sistemas no exponían una descripción de la codificación utilizada para un nombre de archivo como parte de la información extendida del archivo. Esto obligó a adivinar costosas codificaciones de nombres de archivos con cada acceso al archivo. [9]

Una solución fue adoptar Unicode como codificación para los nombres de archivos.

Sin embargo, en el Mac OS clásico, la codificación del nombre del archivo se almacenaba con los atributos del nombre del archivo. [9]

Interoperabilidad Unicode

El estándar Unicode resuelve el problema de determinación de codificación.

No obstante, persisten algunos problemas de interoperabilidad limitados, como la normalización (equivalencia) o la versión Unicode en uso. Por ejemplo, UDF está limitado a Unicode 2.0; El sistema de archivos HFS+ de macOS aplica la normalización NFD Unicode y, opcionalmente, distingue entre mayúsculas y minúsculas (no distingue entre mayúsculas y minúsculas de forma predeterminada). La longitud máxima del nombre de archivo no es estándar y puede depender del tamaño de la unidad de código. Aunque es un problema grave, en la mayoría de los casos es limitado. [9]

En Linux, esto significa que el nombre del archivo no es suficiente para abrir un archivo: además, se necesita la representación exacta en bytes del nombre del archivo en el dispositivo de almacenamiento. Esto se puede resolver a nivel de aplicación, con algunas llamadas de normalización complicadas. [10]

La cuestión de la equivalencia Unicode se conoce como "colisión de nombres normalizados". Una solución es el reconocimiento de composición Unicode no normalizado que se utiliza en las comunidades técnicas de Subversion y Apache. [11] Esta solución no normaliza las rutas en el repositorio. Las rutas solo se normalizan con fines de comparación. Sin embargo, algunas comunidades han patentado esta estrategia, prohibiendo su uso por otras comunidades. [ se necesita aclaración ]

Perspectivas

Para limitar los problemas de interoperabilidad, algunas ideas descritas por Sun son:

Esas consideraciones crean una limitación que no permite un cambio a una codificación futura diferente a UTF-8.

Migración Unicode

Un problema fue la migración a Unicode. Para ello, varias empresas de software proporcionaron software para migrar nombres de archivos a la nueva codificación Unicode.

Mac OS X 10.3 marcó la adopción por parte de Apple de la descomposición de caracteres Unicode 3.2, reemplazando la descomposición Unicode 2.1 utilizada anteriormente. Este cambio causó problemas a los desarrolladores que escribían software para Mac OS X. [14]

Unicidad

Dentro de un único directorio, los nombres de archivos deben ser únicos. Dado que la sintaxis del nombre de archivo también se aplica a los directorios, no es posible crear un archivo y entradas de directorio con el mismo nombre en un solo directorio. Varios archivos en diferentes directorios pueden tener el mismo nombre.

El enfoque de unicidad puede diferir tanto en la distinción entre mayúsculas y minúsculas como en la forma de normalización Unicode , como NFC, NFD. Esto significa que se pueden crear dos archivos separados con el mismo nombre de archivo de texto y una implementación de bytes diferente del nombre de archivo, como L"\x00C0.txt" (UTF-16, NFC) (A mayúscula latina con tumba) y L"\x0041 \x0300.txt" (UTF-16, NFD) (A mayúscula latina, combinación de graves). [15]

Conservación de cajas de cartas

Algunos sistemas de archivos, como FAT , almacenan los nombres de archivos en mayúsculas, independientemente de la letra utilizada para crearlos. Por ejemplo, un archivo creado con el nombre "MiNombre.Txt" o "minombre.txt" se almacenaría con el nombre de archivo "MINOMBRE.TXT". Se puede utilizar cualquier variación de mayúsculas y minúsculas para hacer referencia al mismo archivo. Estos tipos de sistemas de archivos se denominan que no distinguen entre mayúsculas y minúsculas y no preservan las mayúsculas y minúsculas . Algunos sistemas de archivos prohíben por completo el uso de letras minúsculas en los nombres de archivos.

Algunos sistemas de archivos almacenan nombres de archivos en la forma en que fueron creados originalmente; estos se conocen como retentivos o preservadores de casos . Un sistema de archivos de este tipo puede distinguir entre mayúsculas y minúsculas o no . Si distingue entre mayúsculas y minúsculas, entonces "MiNombre.Txt" y "minombre.txt" pueden hacer referencia a dos archivos diferentes en el mismo directorio, y se debe hacer referencia a cada archivo con las mayúsculas exactas con las que se nombra. Por otro lado, en un sistema de archivos que no distingue entre mayúsculas y minúsculas y las preserva, sólo uno de "MiNombre.Txt", "minombre.txt" y "Minombre.TXT" puede ser el nombre de un archivo en un directorio determinado en un en un momento dado, y se puede hacer referencia a un archivo con uno de estos nombres mediante cualquier mayúscula del nombre.

Desde sus inicios, Unix y sus sistemas derivados preservaban las mayúsculas y minúsculas. Sin embargo, no todos los sistemas de archivos tipo Unix distinguen entre mayúsculas y minúsculas; de forma predeterminada, HFS+ en macOS no distingue entre mayúsculas y minúsculas, y los servidores SMB generalmente ofrecen un comportamiento que no distingue entre mayúsculas y minúsculas (incluso cuando el sistema de archivos subyacente distingue entre mayúsculas y minúsculas, por ejemplo, Samba en la mayoría de los sistemas tipo Unix), y los sistemas de archivos del cliente SMB sí distinguen entre mayúsculas y minúsculas. comportamiento insensible. La distinción entre mayúsculas y minúsculas en los sistemas de archivos es un desafío considerable para software como Samba y Wine , que deben interoperar eficientemente tanto con sistemas que tratan archivos en mayúsculas y minúsculas como diferentes y con sistemas que los tratan de la misma manera. [dieciséis]

Caracteres y palabras reservados

Los sistemas de archivos no siempre han proporcionado el mismo juego de caracteres para componer un nombre de archivo. Antes de que Unicode se convirtiera en un estándar de facto, los sistemas de archivos utilizaban principalmente un juego de caracteres dependiente de la configuración regional. Por el contrario, algunos sistemas nuevos permiten que un nombre de archivo esté compuesto por casi cualquier carácter del repertorio Unicode, e incluso algunas secuencias de bytes que no sean Unicode. Las limitaciones pueden ser impuestas por el sistema de archivos, el sistema operativo, la aplicación o los requisitos de interoperabilidad con otros sistemas.

Muchas utilidades del sistema de archivos prohíben que aparezcan caracteres de control en los nombres de archivos. En los sistemas de archivos tipo Unix, elEl carácter nulo [17] y el separador de ruta /están prohibidos.

Personajes problemáticos

Las utilidades del sistema de archivos y las convenciones de nomenclatura en varios sistemas prohíben que determinados caracteres aparezcan en los nombres de archivos o los hacen problemáticos: [7] Salvo que se indique lo contrario, los símbolos en la columna Carácter , " y < , por ejemplo, no se pueden usar en nombres de archivos de Windows.

Nota 1: Si bien están permitidos en los nombres de archivos y carpetas de Unix, la mayoría de los shells de Unix requieren caracteres específicos como espacios, <, >, |, \ y, a veces, :, (, ), &, ;, #, así como comodines. como ? y *, para citar o escapar :

five\ and\ six\<seven(ejemplo de escape)
'five and six<seven'o "five and six<seven"(ejemplos de cotización)

El carácter å ( 0xE5) no estaba permitido como primera letra en un nombre de archivo en 86-DOS y MS-DOS/PC DOS 1.x-2.x, pero se puede utilizar en versiones posteriores.

En las utilidades de Windows, el espacio y el punto no están permitidos como carácter final de un nombre de archivo. [18] El punto está permitido como primer carácter, pero algunas aplicaciones de Windows, como Windows Explorer , prohíben crear o cambiar el nombre de dichos archivos (a pesar de que esta convención se usa en sistemas tipo Unix para describir archivos y directorios ocultos ). Las soluciones alternativas incluyen agregar un punto al cambiar el nombre del archivo (que luego se elimina automáticamente), usar administradores de archivos alternativos , crear el archivo usando la línea de comando o guardar un archivo con el nombre deseado desde una aplicación. [19]

Algunos sistemas de archivos en un sistema operativo determinado (especialmente los sistemas de archivos implementados originalmente en otros sistemas operativos) y aplicaciones particulares en ese sistema operativo pueden aplicar restricciones e interpretaciones adicionales. Consulte la comparación de sistemas de archivos para obtener más detalles sobre las restricciones.

En sistemas tipo Unix, DOS y Windows, los nombres de archivo "." y ".." tienen significados especiales (directorio actual y principal respectivamente). Windows 95/98/ME también utiliza nombres como "...", "...." y así sucesivamente para indicar directorios abuelos o bisabuelos. [20] Todas las versiones de Windows prohíben la creación de nombres de archivos que constan únicamente de puntos, aunque los nombres que constan de tres puntos ("...") o más son legales en Unix.

Además, en las utilidades de Windows y DOS, algunas palabras también están reservadas y no pueden usarse como nombres de archivos. [19] Por ejemplo, archivos de dispositivo DOS : [21]

CON, CONIN$, CONOUT$, PRN, AUX, RELOJ$, NULCOM0, COM1, COM2, COM3, COM4, ​​COM5, COM6, COM7, COM8, COM9 [7]
LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 [7]
LST (sólo en 86- DOS y DOS 1.xx)KEYBD$, SCREEN$ (sólo en multitarea MS-DOS 4.0 )$IDLE$ (solo en DOS concurrente 386 , DOS multiusuario y DR DOS 5.0 y superior)CONFIG$ (sólo en MS-DOS 7.0-8.0)

Los sistemas que tienen estas restricciones provocan incompatibilidades con algunos otros sistemas de archivos. Por ejemplo, Windows no podrá manejar o generar informes de error para estos nombres de archivos UNIX legales: aux.c, [22] q"uote"s.txt o NUL.txt.

Los nombres de archivos NTFS que se utilizan internamente incluyen:

$Mft, $MftMirr, $LogFile, $Volumen, $AttrDef, $Bitmap, $Boot, $BadClus, $Secure,$Upcase, $Extend, $Quota, $ObjId y $Reparse

Comparación de limitaciones de nombres de archivos

Ver también

Referencias

  1. ^ abcd "Reglas de nomenclatura de conjuntos de datos". Guía del usuario de z/OS TSO/E . IBM.
  2. ^ "Convenciones de nomenclatura de conjuntos de datos". Guía del usuario de z/OS TSO/E . IBM.
  3. ^ Protocolo de transferencia de archivos (FTP). doi : 10.17487/RFC0959 . RFC 959.
  4. ^ "CPM: formato de sistema de archivos y disco CP/M".
  5. ^ "Página de descripción del comando Fsutil". Microsoft.com. Archivado desde el original el 6 de octubre de 2013 . Consultado el 15 de septiembre de 2013 .
  6. ^ "Vínculos físicos NTFS, uniones de directorios y accesos directos de Windows". Hexágono flexible . InvSoftworks. Archivado desde el original el 11 de julio de 2011 . Consultado el 12 de marzo de 2011 .
  7. ^ abcd "Nombrar archivos, rutas y espacios de nombres". 15 de diciembre de 2022 . Consultado el 8 de octubre de 2023 .
  8. ^ "Limitación de la longitud máxima de la ruta: aplicaciones Win32". 18 de julio de 2022.
  9. ^ abcdeDavid Robinson; Ienup Sung; Nicolas Williams (marzo de 2006). "Presentaciones de Solaris: sistemas de archivos, Unicode y normalización" (PDF) . San Francisco: Sun.com. Archivado desde el original (PDF) el 4 de julio de 2012.
  10. ^ "Nombres de archivos con tildes". Ned Batchelder. Junio ​​de 2011 . Consultado el 17 de septiembre de 2013 .
  11. ^ "Conciencia de composición Unicode no normalizada - Subversion Wiki". Wiki.apache.org. 21 de enero de 2013 . Consultado el 8 de octubre de 2023 .
  12. ^ "Utilidad de reparación de codificación de nombres de archivos v1.0". Soporte.apple.com. 1 de junio de 2006 . Consultado el 2 de octubre de 2018 .
  13. ^ "convmv: convierte nombres de archivos de una codificación a otra". J3e.de. _ Consultado el 17 de septiembre de 2013 .
  14. ^ "Re: git en MacOSX y archivos con nombres de archivo utf-8 descompuestos". Trampa del núcleo. 7 de mayo de 2010. Archivado desde el original el 15 de marzo de 2011 . Consultado el 5 de julio de 2010 .
  15. ^ "Convenciones de nomenclatura de rutas de archivos multiplataforma: programación general". GameDev.net . Consultado el 8 de octubre de 2023 .
  16. ^ "Nombres de archivos que no distinguen entre mayúsculas y minúsculas: la wiki oficial del vino". Wiki.winehq.org. 8 de noviembre de 2009. Archivado desde el original el 18 de agosto de 2010 . Consultado el 20 de agosto de 2010 .
  17. ^ "Las especificaciones básicas de Open Group, número 6". Norma IEEE 1003.1-2001 . El grupo abierto. 2001.
  18. ^ "Convenciones de nomenclatura de Windows". MSDN , Microsoft.com. Ver el último elemento con viñeta.
  19. ^ ab Nombrar un archivo msdn.microsoft.com (MSDN), restricciones de nombre de archivo en Windows
  20. ^ Microsoft Windows 95 README para sugerencias y trucos, Microsoft, archivado desde el original el 1 de noviembre de 2014
  21. ^ Los nombres de los controladores de dispositivos MS-DOS no se pueden utilizar como nombres de archivos, Microsoft , archivado desde el original el 20 de marzo de 2014
  22. ^ Ritter, Gunnar (30 de enero de 2007). "El cuento de" aux.c"". Proyecto de reliquia .
  23. ^ "Referencia del sistema de archivos de Apple" (PDF) . Apple Inc.
  24. ^ Lewine, Donald. Guía del programador POSIX: escritura de programas UNIX portátiles 1991 O'Reilly & Associates, Inc. Sebastopol, CA págs.63–64
  25. ^ pathchk - comprobar los nombres de las rutas
  26. ^ Hewlett-Packard Company Roseville, CA Referencia de sintaxis de HP 250 Rev 1/84 Manual Número de pieza 45260-90063

enlaces externos