stringtranslate.com

Charla:8.3 nombre de archivo

¿Soporte Unicode?

Si la compatibilidad total con Unicode no llegó hasta Windows 2000, ¿cómo exactamente se admitieron los nombres de archivos largos Unicode?—Kbolino 06:46 , 7 de abril de 2005 (UTC)

¿Qué quieres decir con "soporte total para Unicode"? 98 tenía algo de soporte Unicode, aunque no tenía todas las API (no tengo 95 a mano para probar, pero no me sorprendería si tuviera algún grado de soporte). NT4 era Unicode de forma nativa, aunque creo que solo admitía el plano multilingüe básico . Incluso ahora, la compatibilidad con Unicode no está exenta de peculiaridades en la mayoría de los sistemas operativos. Plugwash 20:21, 13 de junio de 2005 (UTC)
La compatibilidad total con Unicode aún está a kilómetros de distancia, aunque nos estamos acercando al modo Ms dos ( charla ) 21:35, 22 de junio de 2009 (UTC) [ respuesta ]
Windows 95+ admitía dos subconjuntos de Unicode, definidos por las páginas de códigos ANSI y OEM del sistema. IFSMGR.VXD utilizó el archivo UNICODE.BIN para realizar las conversiones requeridas. 178.49.152.66 ( charla ) 12:36, 20 de diciembre de 2014 (UTC) [ respuesta ]

Nombre de la página

Esta página solía estar en "8.3 (informática)", en mi opinión, un nombre horrible y poco informativo.

perorata vaga que nunca ha editado esta página y luego la movió a solo 8.3. Lo cual creo que es aún peor ya que da muy poca idea del tema del artículo.

si no hay objeciones aquí en aproximadamente un día. Voy a mover la página al nombre más descriptivo de limitaciones de nombre de archivo 8.3. Plugwash 20:27, 13 de junio de 2005 (UTC)

Un título más preciso podría ser "mapeo de nombres de archivos FAT 8.3" o "esquema de nombres de archivos 8.3", pero no veo qué se puede ganar con el movimiento. "8.3" es un apodo que el artículo se propone explicar, y lo hace bastante bien. Otro ejemplo similar podría ser 24 horas al día , 7 días a la semana .
- Ghakko 23:03, 13 de junio de 2005 (UTC)
Señalaré que mi cambio de página se realizó simplemente porque no había necesidad de desambiguación, ya que el artículo 8.3 no existía. No tomé en cuenta si podría haber un título mejor, solo estaba eliminando desambiguación innecesaria. No tengo ningún problema con que la página se mueva a otro lugar. Tampoco tengo ningún problema en que se quede aquí. No soy quisquilloso. - Vago | Despotricar 13:31, 16 de junio de 2005 (UTC)

¿Especulación sobre la convención de nombres?

He leído teorías sobre esto y, por lo general, las discusiones sobre esto terminan diciendo que no hay una respuesta real.

El primero de http://www.mackido.com/Innovation/FileNames.html: debido a que para hacer cosas (como copiar un archivo), tenías que escribir el nombre completo del archivo (y el nombre de la ruta), la gente usaba muchas abreviaturas. y concatenación para reducir la escritura. Es por eso que CP/M (DOS) usó 8.3 (8 caracteres + un sufijo de 3 caracteres).

Segundo: si se topó con el nombre de Gary Kildall durante su investigación, cuente las letras de su nombre. Sin embargo, esto no explica por qué no era 7.4.

Tercero: 8,3, 8 + punto + 3 = 12 caracteres, bien comprimidos con RAD50 en dos palabras. Sin embargo, CP/M no comprime nombres de archivos y RAD50 generalmente se usaba para comprimir nombres de archivos 6.3 o 9.3 (algunas computadoras eran de 6 bits en ese entonces).

Cuarto: Proviene de las 12 filas de una tarjeta de 80 columnas. Una fila para cada letra, más la fila 12 para un reloj de datos (basado en el estereotipo de perforadora IBM 029). Se marcó una sola columna en cada fila para marcar la letra del conjunto de caracteres, lo que produjo hasta 80 opciones por carácter.

Quinto: Hay evidencia de que Gary era uno de esos raros individuos con influencias tanto de DEC como de IBM en su trayectoria. DEC había establecido la extensión de archivo de 3 caracteres como estándar en sus sistemas, y los mainframes IBM de la época tenían 8 caracteres como tamaño de espacio de nombres común. Si juntamos los dos obtenemos 8,3.

Sexto: el RT-11 de DEC usó nombres de archivos 8.3 y CP/M se desarrolló usándolo como guía. Sin embargo, esto no explica de dónde obtuvo RT-11 8.3.

Séptimo: Kildall eligió 8,3 porque le gustaba.

http://www.techspot.com/vb/all/windows/t-10133-83-Naming-Convention-Why-was-it-chosen.html

Creo que la implementación de FAT32 en Mac OS X utiliza un paso de hash similar al que figura como paso 4 del "algoritmo", pero no estoy completamente seguro de esto. Puede que valga la pena mencionar si alguien con más conocimientos puede verificar esto. 71.245.115.135 02:26, ​​21 de enero de 2007 (UTC) [ respuesta ]

DOS 8.3

Generalmente se llama DOS 8.3. Si el artículo no va a tener ese nombre oficial, ciertamente debería redirigir a aquí desde allí y debería mencionar el término desde el principio. *** La discusión sobre el punto quizás debería agregar más antecedentes tecnológicos. El punto no existe en la representación interna; simplemente hay un lugar para las 8 letras y un lugar para las 3 letras. Entonces, el punto siempre está implícitamente presente. Y también es engañoso decir que 8,3 nombres están en mayúsculas. Es un sentido técnico que puede ser cierto, pero en otro sentido generalmente se definen como sin mayúsculas y se pueden representar arbitrariamente como mayúsculas o minúsculas. Todo una fuente de infinitos problemas potenciales. 69.87.203.84 19:26, 21 de enero de 2007 (UTC) [ respuesta ]

Siempre pensé que los nombres de archivos de ocho puntos y tres siempre estaban en mayúsculas/mayúsculas. Como la verdadera forma de 8.3, los nombres de archivos están en mayúsculas.
wmic enumera todos los nombres de archivos y carpetas en minúsculas:
C:\>wmic datafile where name="C:\\0\\Doc\\Web\\Site\\n\\_b_ - _ z _ 8.html" list/format:list
[...]
EightDotThreeFileName=g:\0\doc\web\site\n\_b_-_z~1.htm
dir enumera todos los nombres de archivos y carpetas 8.3 en mayúsculas:
C:\0\Doc\Web\Site\n>dir /x/r
[...] _B_-_Z~1.HTM[...]
También se generan 8.3 nombres para las carpetas, para su información. --User123o987name ( discusión ) 06:45, 9 de noviembre de 2020 (UTC) [ respuesta ]

se necesita más información

Hay infinitas complicaciones con DOS 8.3/LFN. Este es un tema tecnológico central. Es patético que este artículo sea tan limitado y no tenga enlaces a recursos externos relevantes. 69.87.203.84 20:12, 21 de enero de 2007 (UTC) [ respuesta ]

Muévete.. otra vez

Estoy de acuerdo con la discusión anterior en que un título simple de "8.3" es vago. Según la documentación de MSDN, esto se denomina "nombre de archivo 8.3" (los espacios son intencionales, aunque podría optar por "nombre de archivo" para mantener la constancia dentro de Wikipedia). ¿Podríamos aceptar moverlo al nombre de archivo 8.3 o al nombre de archivo 8.3 ? + mwtoews 17:38, 22 de marzo de 2007 (UTC) [ respuesta ]

Movido. Elegí usar "nombre de archivo" en lugar de "nombre de archivo", ya que parece que Wikipedia tiene más coherencia con esa ortografía. + mwtoews 21:58, 24 de marzo de 2007 (UTC) [ respuesta ]

Traducción de LFN a SFN

No entiendo "seguido de 4 dígitos hexadecimales derivados de un hash indocumentado del nombre del archivo", ¿cómo, exactamente, se determinan esos cuatro dígitos por sí solo? Tal vez sea mi grave falta de comprensión de los hexadecimales...


Archivo de texto.Mino = TE 021F ~1

OFFSET HEXADECIMAL REPRESENTATION  ; ASCII REPRESENTATION

00000000h: 54 65 78 74 46 69 6C 65 2E 4D 69 6E 65  ; TextFile.Mine

00000000h: 78 74 46 69 6C 65 2E 4D 69 6E 65  ; xtFile.Mine

00000000h: 54 65 78 74 46 69 6C 65 2E  ; TextFile


Jndrline ( discusión ) 20:10, 16 de julio de 2008 (UTC) [ respuesta ]

Hex es solo una forma de expresar un número. El número está determinado por un algoritmo que no está documentado. El algoritmo varía según el sistema operativo, la versión y, a veces, el paquete de servicio. - EncMstr ( discusión ) 21:22, 16 de julio de 2008 (UTC) [ respuesta ]
Estoy seguro de haber visto SFN de este tipo, pero al mismo tiempo, estoy seguro de que también he visto SFN de ese tipo FOOBA~12.TXT(que utilizan menos de 6 caracteres y más de un dígito). El artículo no menciona eso ni nada útil sobre la variedad de 4 dígitos hexadecimales. Es un poco vago tal como está y necesita información sobre eso/aquellos. Supongo que acabo de recibir un nuevo proyecto. ಠ_ಠ Synetech ( charla ) 19:45, 21 de agosto de 2015 (UTC) [ respuesta ]
Los sistemas Windows NT usan la suma de verificación después de FOOBAR~4.TXT, pero los sistemas anteriores a NT (estoy bastante seguro de que incluye 95, pero no sé cuál fue el último sistema que no era NT) usan FOOBAR~5.TXT, que lógicamente se puede extender a números de dos dígitos ( como FOOBA~12.TXTdijiste)... Nameless6144 ( charla ) 12:58, 20 de mayo de 2018 (UTC) [ respuesta ]
Encontré una página sobre una ingeniería inversa exitosa de esta suma de verificación... Historia de dos nombres de archivos: ¿Debería incluirse o no es enciclopédico incluir información descubierta mediante ingeniería inversa? De cualquier manera, probablemente sea lo que Jndrline quería, así que lo publicaré aquí. Nameless6144 ( charla ) 12:58, 20 de mayo de 2018 (UTC) [ respuesta ]
¡Guau, Sin Nombre6144 ! Respondiste una pregunta que había olvidado que alguna vez hice. Creo que mi intención original era escribir archivos cmd/bat, y ¿cómo se puede predecir un nombre de archivo 8.3 en ciertos casos? ¡Qué gran lectura! Gracias por compartir. Jndrline ( discusión ) 19:16, 27 de septiembre de 2018 (UTC) [ respuesta ]

185.24.13.202 (discusión) 10:43, 3 de agosto de 2018 (UTC) [ respuesta ]

El ejemplo de un nombre de archivo abreviado 'OVI3KV~N' contiene el carácter 'N', mientras que el texto debajo indica claramente que el carácter después de la tilde es siempre un dígito.

La conversión al nombre corto omite detalles

La sección de conversión no cubre cómo puedo obtener manualmente el número correcto después de la tilde.

Por ejemplo, si tengo nombres de archivo abcdefgh-cat.txt y abcdefgh-dog.txt, ¿cuál será ABCDEF~1.TXT y cuál será ABCDEF~2.TXT? ¿Cómo puedo determinar el número correcto? -- 95.91.242.234 (discusión) 10:06, 18 de junio de 2022 (UTC) [ respuesta ]

Por lo general, el archivo que estuvo presente en el directorio primero será "~1" y el archivo agregado allí más tarde será "~2". Sin embargo, el propósito de este artículo no es realmente examinar los detalles del código fuente del sistema operativo... AnonMoos ( charla ) 17:56, 18 de junio de 2022 (UTC) [ respuesta ]