-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 08:57 +0100, Camaleón escribió:
El 19/01/07, Carlos E. R. escribió:
En otra parte del correo digo que abro las 15155 lineas como texto en OOo. El fichero aumenta por minutos, cuando te lo vuelves a bajar ha aumentado.
Ah, cuando divides el fichero logras ver el total de filas.
Y sin dividirlo, tomate otro café doble a mi salud :-p Que he hecho varias pruebas distintas ;-)
Iba a probarlo otra vez, pero no consigo bajarme el fichero xml para verlo. El html es otra posibilidad, si es una tabla se puede importar. Se queda el firefox esperando pero no lo baja, ni se me abre la ventanita.
Hace unos años escribí al webmaster de la página web, precisamente porque al intentar bajar el fichero xml no lo bajaba "completo"... This is Europe :-)
Al final me lo bajó, pero no se si completo o no. El caso es que el OOo lo abre como texto plano, no lo interpreta, con lo que no vale. ¿Este XML no será el famoso xml del word? En ese caso, no hay filtro todavía o se activa de otra forma. También bajé el html, pero es tan gordo (15 megas) que se le atraganta al OOo-writer, pero si se ve una tabla, sería importable con copy paste al calc. Sin embargo, no ha leído bien el UTF, hay caracteres acentuados mal puestos.
Eso ya lo he dicho. Necesitas un café ;-)
Sí, sí, lo he releído ahora y veo que al hacer el split logras ver las filas al completo.
Que no es eso. Ese café ;-) Veo el total de filas en el OOo-write, cuando leo el fichero original como texto, no como csv. Luego guardo el fichero de nuevo como texto, pero esta vez con los caracteres de fin de linea estilo unix bien puestos (es como si lo pasara por el kwrite). Aún así el Calc se equivoca al leer este nuevo fichero. Lo de partir el fichero en dos fué otra prueba para ver si el problema era por ser demasiadas lineas, y no lo es, porque se sigue comiendo las mismas.
Y que no es por límite de tamaño, sino porque se salta lineas. La prueba es que partiendo el fichero original en dos mitades se sigue saltando las mismas lineas: la cuestión es averiguar exactamente qué lineas son las que se salta, y entonces pensar el porqué.
Lo dices más abajo: es porque han utilizado el mismo separador de texto ("comillas dobles") dentro de los propios textos, cuando deberían haber utilizado 'comillas simples'. A ver cómo me las apaño para importarlo, ¡grrr!
Un programita que "parsifique" y se coma todas las comillas que estén justo antes o después de todos los punto y comas, dejando las interiores, más la comilla inicial y la final de cada linea. Eso lo hago yo en unas horas, y estoy oxidado ;-) Si alguien pone un punto y coma dentro de unas comillas, que haya que meter en un campo, revienta. Luego, al importar en el OO le dices que todo es texto, y borras el separador de los strings.
Ya sé porqué falla.
Sasto.
El problema está en las comillas que "ve" el OOo.Veamos:
El OO y el Excel y cualquier hoja de cálculo, digo yo...
No lo se.
Falta una comilla ahí, se la ha comido. Al comersela, se desfasa, y el campo no se cierra en el "gekühlt" sino después: tan después que sigue llenando hasta la columna "IV" y no sigue porque se ha terminado la hoja.
Ignoro como solucionarlo. Es un bug del OOo (a no ser que el formato CSV no deba llevar comillas internas). Se podría solventar creando un programa que lea el CSV y cambie las comillas de string respetando las interiores.
No, no es un bug de OO, es un "europe bug" nada más, han utilizado el mismo delimitador para varias cosas.
Pero aún así. Todas las lineas están hechas de esa forma. ¿Porqué se equivoca precisamente en la 478 y no en todas? Puede ser por algo en la codificación UTF-8, pero no se con qué herramienta verlo. Con less no puedo tratar el original. Se sabe cuales comillas son las delimitadoras de string porque están justo antes o después de los puntos y comas, no hay confusión. De esa manera también se pueden poner puntos y comas en el interior del texto, en vez de escaparlos. No se pueden usar comillas simples, porque son las mismas de los apostrofos usados en el inglés. También darían problemas. No, para mi es un bug del OOo. Pasaría con cualquier caracter que se escoja como separador de strinigs, si no se escapa el resto de ocurrencias.
Por cierto, sólo por tener el OOo abierto con el fichero .ods de este chisme, me ocupa un 55% de CPU con el OO sin hacer nada. [...] hasta pasado un buen rato que se tranquiliza.
Me has dado una idea para probar los sofocos que tiene mi micro cuando ejecutaba zen updater... a ver si con OO me pita la placa de igual forma :-)
Ponle a abrir el html. Tuve que matarlo para cerrarlo. Mirando otra vez la 478... "5";"030221000080";"0302 21";"-- Halibut (Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis)";"";"";"Fresh or Abre 1 chilled lesser or Greenland halibut "Reinhardtius hippoglossoides, Abre 2 Atlantic halibut "Hippoglossus hippoglossus" and Pacific halibut Abre 3, cierra 3 "Hippoglossus stenolepis"";"Flétans [Reinhardtius hippoglossoides, Abre 3, cierra 3. Cierra 1. Punto y coma. Problema: falta cerrar la "2". El punto y coma no se leería, pero sí se lee. El OOo falla en el último campo, no dos antes. Hippoglossus hippoglossus, Hippoglossus stenolepis], frais ou réfrigérés";"Heilbutt "Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis", frisch oder gekühlt"" Hay errores de comillas no pareadas en el texto original. Se arreglaría con un programita como el que te dije, y luego diciendole al OOo que ignore todas las comillas. O abres en el OOo ignorando todas las comillas, y luego una busqueda y reemplazamiento de todas las comillas que estén al final o principio de linea. Tu misma :-) Oye, ¿y tanto bacalao del pacífico, hypoglosusnosecuantos, pa'que sirve, que rayos es ese fichero? :-p - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsKMTtTMYHG2NR9URAo42AJwJf9pnW5zOQFr+Pc/h4ihjxtRuDACfcFyU qcBtoTNIbOe7RdORpy2Jxlo= =Ybai -----END PGP SIGNATURE-----