OT qué tienen algunos sistemas en contra de las lineas en ficheros de texto plano con un numero impar de caracteres?
Buenas, en mi pequeña batalla de intercambio de ficheros ascii, me encuentro con un campo de un fichero en particular: Filler 1 space. As some systems have difficulty with odd length records, a filler is often used to make the length an even. Esto es, yo voy a recibir un fichero de texto plano dividido en registros formateados de una determinada manera. El ultimo caracter de estos registros puede ser un espacio para hacer que el numero total de caracteres en dicho registro sea par, debido a que ´algunos sistemas tienen dificultades con una longitud de registro impar´. Sospecho que este fichero se crea desde un NT, pero no tengo forma de confirmarlo. Alguien me puede decir si esa linea, si esa condicion es real?? A mi me suena rara-rara-rara... -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-07 a las 09:58 +0100, miguel gmail escribió:
en mi pequeña batalla de intercambio de ficheros ascii, me encuentro con un campo de un fichero en particular:
Filler 1 space. As some systems have difficulty with odd length records, a filler is often used to make the length an even.
¿Mandeeeee? ¿En un fichero _ascii_?
Alguien me puede decir si esa linea, si esa condicion es real?? A mi me suena rara-rara-rara...
Sólo tendría sentido en ficheros con campos de tamaño exacto, definido, no texto variable. Y me suena a bug, y a rodeo (hack) para solventar el bug. Tendría sentido si el programa lee words o campos, y se le mete en un "not packet record" y no queda alineado y el ultimo byte queda en el lado equivcado del word - o algo así. No se, se me ocurren algunas formas de "implementar" ese bug. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6HzntTMYHG2NR9URAqOPAJ4vTLotuMRLoc/8Q1+n/J2JWIuzzQCePBI1 PHw3j6BDMAq08gjPkhuBbSk= =6ip7 -----END PGP SIGNATURE-----
Filler 1 space. As some systems have difficulty with odd length records, a filler is often used to make the length an even.
¿Mandeeeee? ¿En un fichero _ascii_?
ascii plano, mondo y lirondo.
Alguien me puede decir si esa linea, si esa condicion es real?? A mi me suena rara-rara-rara...
Sólo tendría sentido en ficheros con campos de tamaño exacto, definido, no texto variable. Y me suena a bug, y a rodeo (hack) para solventar el bug.
El fichero tiene esos campos de tamaño exacto, definido. Pero debería dar lo mismo que fuese de longitud para o impar!
Tendría sentido si el programa lee words o campos, y se le mete en un "not packet record" y no queda alineado y el ultimo byte queda en el lado equivcado del word - o algo así. No se, se me ocurren algunas formas de "implementar" ese bug.
ascii plano, lo juro. No llega ni a csv :D Me parece que no voy a forzar a un numero par el numero de caracteres de una linea, a ver que pasa y si peta, por qué lo hace... ;-) -- Saludos, miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-07 a las 23:25 +0100, miguel gmail escribió:
Tendría sentido si el programa lee words o campos, y se le mete en un "not packet record" y no queda alineado y el ultimo byte queda en el lado equivcado del word - o algo así. No se, se me ocurren algunas formas de "implementar" ese bug.
ascii plano, lo juro. No llega ni a csv :D
Jo.
Me parece que no voy a forzar a un numero par el numero de caracteres de una linea, a ver que pasa y si peta, por qué lo hace... ;-)
Podría pensar circunstancias en que eso pasara... usando pascal y records de eso con tipos multiples solapados... pero haciendolo a propósito. O quizás es una interferencia entre litle-endian vs big-endian... Buf. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6TwStTMYHG2NR9URAj5fAJ9F/ZXH4/tRyHQxUyvK1P7yr4DOEQCfecJo UB1fRKb4fxKr9DNDehKGcvc= =8Jw2 -----END PGP SIGNATURE-----
participants (2)
-
Carlos E. R. -
miguel gmail