Combine el análisis de ejemplo Principio de carga de archivos ASP

Todo el tiempo, debido a las limitaciones de FileSystemObject, el mayor problema de ASP es la carga de archivos, la mayor parte de la solución es instalar componentes de carga de terceros. Hay muchos problemas con los componentes de terceros. Algunos componentes están registrados y algunos componentes tienen su información de copyright agregada al formulario. Se entiende que hay tres mecanismos para cargar archivos en HTTP: RFC1867, PUT y WebDAV. Una implementación común es aprovechar un nuevo tipo introducido en RFC 1867: objetos File y ADO Stream. Este documento analiza el método de carga y el principio de implementación anteriores y brinda soluciones específicas.

Objetos de ASP ARCHIVO

Actualmente, las aplicaciones basadas en /mode son populares. Cuando el usuario necesita transferirle el archivo, uno de los métodos comunes es ejecutar FTP y establecer el directorio predeterminado de FTP de cada usuario en el directorio de inicio del usuario, para que el usuario pueda ejecutar el cliente de FTP y cargar el archivo en el directorio web especificado. . Esto requiere que el usuario sepa cómo usar el cliente FTP. Por lo tanto, esta solución solo es factible para usuarios familiarizados con FTP y con experiencia. Si podemos integrar la función de carga de archivos con la web, para que los usuarios puedan completar la tarea de carga utilizando solo la web, será muy conveniente para ellos. Sin embargo, durante mucho tiempo, dado que el objeto del sistema de archivos solo puede transmitir las limitaciones de los archivos de texto, el mayor problema con ASP es el problema de la carga de archivos. Lo siguiente es cómo implementar la carga de archivos en páginas web basadas en el protocolo HTTP.

I. Tres mecanismos para cargar a través de HTTP

Hay tres mecanismos para cargar a través de HTTP: RFC1867, PUT y WebDAV.

PUT es un nuevo verbo HTTP introducido en HTTP 1.1. Cuando la web recibe un PUT de HTTP y un nombre de objeto, autentificará al usuario, recibirá el contenido de la secuencia HTTP y lo guardará directamente en la web. Esto puede causar daños a un sitio web y perder la mayor ventaja de HTTP: la capacidad de programación. En el caso de PUT, maneje la solicitud usted mismo: no hay espacio para que intervengan las aplicaciones CGI o ASP. La única manera de hacer que su aplicación capture PUT es operar en un nivel inferior, la capa de filtro ISAPI. Por las razones correspondientes, la aplicación de PUT es muy limitada.

Mientras que WebDAV permite la autenticación distribuida y la traducción de contenido web. Introduce varios verbos HTTP nuevos que permiten la carga a través de HTTP, el bloqueo /desbloqueo y el registro /verificación de contenido web. " Guardar en la web " en Office 2000 se implementa a través de WebDAV. Si todo lo que le interesa es subir contenido, WebDAV es una excelente aplicación y resuelve muchos problemas. Sin embargo, si necesita cargar archivos en su aplicación web, WebDAV no le sirve de nada. Al igual que HTTP PUT, esos verbos de WebDAV se interpretan en lugar de las aplicaciones web. Debe trabajar en la capa de filtro ISAPI para acceder a estos verbos de WebDAV e interpretar el contenido de su aplicación.

RFC1867 finalmente fue adoptado como un estándar recomendado antes de ser aceptado por el W3C en HTML 3.2. Es una idea muy simple pero poderosa: define un nuevo tipo en el campo de formulario.

y agrega diferentes esquemas de codificación al formulario en sí, ya no usa el típico:

pero usa:

Este esquema de codificación se usa cuando se transfieren grandes cantidades de datos. Es mucho más eficiente que el esquema de codificación de formulario predeterminado de aplicación /x-url codificado. La codificación de la URL tiene un conjunto de caracteres muy limitado. Cualquier carácter que exceda el conjunto de caracteres debe reemplazarse con '% nn', donde nn representa los 2 dígitos hexadecimales correspondientes. Por ejemplo, incluso los caracteres de espacio en blanco normales deben reemplazarse con '% 20'. RFC 1867 usa codificación MIME de varias partes, como se ve comúnmente en los mensajes de correo electrónico, sin codificación para transferir grandes cantidades de datos, pero con pocos encabezados simples pero útiles alrededor de los datos. Los principales proveedores han adoptado el botón recomendado " Examinar ... " y los usuarios pueden usar fácilmente el diálogo local " Abrir archivo ... " para seleccionar el archivo para cargar.

RFC1867 aún deja la flexibilidad de la mayoría de los archivos subidos a su aplicación web. PUT es muy limitado. WebDAV es útil para los autores de contenido, como los usuarios de FrontPage, pero rara vez es utilizado por los desarrolladores web que desean agregar cargas de archivos a las aplicaciones web. Por lo tanto, RFC1867 es la mejor manera de agregar cargas de archivos a aplicaciones web.

En la práctica, Posting Acceptor se proporciona de forma gratuita. ASP no entiende el esquema de codificación de " multipart /form-data ". En su lugar, se proporciona el Aceptador de publicación. El Aceptador de publicación es una aplicación ISAPI que acepta REPOST a una página ASP después de que se complete la carga. SA-FileUp de Software Artisans es uno de los primeros servidores activos comerciales. Después de varias mejoras, ahora existe como un ASP puro.

II. Análisis del principio de carga de archivos basado en ASP

El principio básico es: use el método BinaryRead del objeto ADO Stream para leer todos los datos en el FORMULARIO, y extraiga los datos de archivo requeridos. , guardar como un archivo binario. El siguiente es un ejemplo de carga de una página de archivo (upload.htm):

El objeto de archivo se usa en el programa, por lo que los datos sin procesar leídos en el método BinaryRead en Upload.asp no son solo el archivo seleccionado. Los datos también contienen una descripción de la ruta, el tipo y la forma de la página enviada en el disco duro del usuario, por lo que necesitamos extraer el contenido específico del archivo. De acuerdo con el análisis, el límite entre el encabezado de datos y los datos son dos pares de avances de línea de retorno de carro, y la cola también tiene información de separación. Podemos obtener datos de archivos utilizando el siguiente método.

Dim FormData.FormSize, DataStart, CLStr, DivStr FormSize = Request.TotalBytes FormData = Request.BinaryRead (FormSize) CLStr = ChrB (13) &ChrB (10) DataStart = InStrB (FormData.CLStr &CLStr &) +4 '4 es la longitud de dos pares de saltos de línea de retorno de carro DivStr = LeftB (FormData, InStrB (FormData, CLStr) -1) DataSize = InStrB (DataStart + 1, FormData, DivStr) -DataStart-2 FormData = MidB (FormData) , DataStart, DataSize) Anterior123Página siguiente Total 3 páginas