[opensuse-es] [OT] OpenOffice (Calc)
Hola, ¿Alguien sabe si es posible trabajar con ficheros de datos que contienen más de 20.000 filas en Calc? Cuando he abierto el fichero (csv) me ha dicho que se ha excedido en el límite y algunas filas se han eliminado... y es cierto, de 16.500 sólo hay 13.500. ¿Alguna idea? La versión de OpenOffice es la que viene con SuSE 10.1. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Jueves, 18 de Enero de 2007 14:14, Camaleón escribió:
¿Alguien sabe si es posible trabajar con ficheros de datos que contienen más de 20.000 filas en Calc?
65.536 filas máximo x 230 columnas máximo. Si no recuerdo mal esos son los límites de la versión 2.
Cuando he abierto el fichero (csv) me ha dicho que se ha excedido en el límite y algunas filas se han eliminado... y es cierto, de 16.500 sólo hay 13.500.
¿Alguna idea? La versión de OpenOffice es la que viene con SuSE 10.1.
Saludos,
-- Saludos. HP Compaq nx9420 OpenSUSE 10.2 (KDE) Linux 2.6.18.2-34-default x86_64
El 18/01/07, Doctor Nemo escribió:
65.536 filas máximo x 230 columnas máximo. Si no recuerdo mal esos son los límites de la versión 2.
Sí, eso he visto por Google, pero entonces no entiendo por qué me aparece el error y se come las filas... Como dato adicional añadir que en la última versión de OO (2.1) para Windows hace exactamente lo mismo, mismo error y mismo resultado. :-? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
tamaño maximo del archivo?
quizas te pasas en eso
----- Original Message -----
From: "Camaleón"
El 18/01/07, Doctor Nemo escribió:
65.536 filas máximo x 230 columnas máximo. Si no recuerdo mal esos son los límites de la versión 2.
Sí, eso he visto por Google, pero entonces no entiendo por qué me aparece el error y se come las filas... Como dato adicional añadir que en la última versión de OO (2.1) para Windows hace exactamente lo mismo, mismo error y mismo resultado.
:-?
Saludos,
-- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
--------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 18/01/07, Juan Gustavo Fogelman escribió:
tamaño maximo del archivo? quizas te pasas en eso
Es un archivo de 7 MB. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Camaleón escribió:
El 18/01/07, Doctor Nemo escribió:
65.536 filas máximo x 230 columnas máximo. Si no recuerdo mal esos son los límites de la versión 2.
Sí, eso he visto por Google, pero entonces no entiendo por qué me aparece el error y se come las filas... Como dato adicional añadir que en la última versión de OO (2.1) para Windows hace exactamente lo mismo, mismo error y mismo resultado.
:-?
Saludos,
Yo hice pruebas de unas 12 mil lineas y se volvia imposible el filtrar y borrar. Si quieres y puedes, pasame el fichero lo reviso y si no lo pregunto en la lista de openoffice. --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 18/01/07, admin-listas escribió:
Yo hice pruebas de unas 12 mil lineas y se volvia imposible el filtrar y borrar.
¿Pero te abría todas las filas? Con las 13.000 que me inserta va rápido pero como que me faltan unas 2.000 más :-)
Si quieres y puedes, pasame el fichero lo reviso y si no lo pregunto en la lista de openoffice.
El fichero lo puedes descargar desdes este enlace: http://ec.europa.eu/eurostat/ramon/nomenclatures/index.cfm?TargetUrl=LST_CLS_DLD&StrNom=CN_2007&StrLanguageCode=EN&StrLayoutCode=HIERARCHIC Pulsa sobre "Formato CSV" y se te abrirá un pop-up, selecciona el punto y coma (;) como separador y te descargará el fichero de 7 MB. Si descubres algo, avisa :-) Saludos y gracias, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Jueves, 18 de Enero de 2007 19:30, Camaleón escribió:
El 18/01/07, admin-listas escribió:
Yo hice pruebas de unas 12 mil lineas y se volvia imposible el filtrar y borrar.
¿Pero te abría todas las filas? Con las 13.000 que me inserta va rápido pero como que me faltan unas 2.000 más :-)
Si quieres y puedes, pasame el fichero lo reviso y si no lo pregunto en la lista de openoffice.
El fichero lo puedes descargar desdes este enlace:
Yo lo he descargado y lo he abierto en la versión 10.2 de OpenSuSE. No me ha dado ningún error y son 13.903 filas. A ver si es algún fallo del OOo del 10.1 y no hay más filas ¿Seguro que son 15.000? -- Saludos. HP Compaq nx9420 OpenSUSE 10.2 (KDE) Linux 2.6.18.2-34-default x86_64
El 18/01/07, Doctor Nemo escribió:
Yo lo he descargado y lo he abierto en la versión 10.2 de OpenSuSE. No me ha dado ningún error y son 13.903 filas.
Bueno, es que son, exactamente, 15.148, te faltan unas cuantas :-)
A ver si es algún fallo del OOo del 10.1 y no hay más filas ¿Seguro que son 15.000?
Sip, y ya he comentado que en OO 2.1 (versión Windows) me pasa lo mismo que con la 2.0 en SuSE 10.1, error al canto y 13.000 y pico filas. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-18 a las 20:30 +0100, Camaleón escribió:
El fichero lo puedes descargar desdes este enlace:
Pulsa sobre "Formato CSV" y se te abrirá un pop-up, selecciona el punto y coma (;) como separador y te descargará el fichero de 7 MB.
Si descubres algo, avisa :-)
Por lo pronto, viene en formato msdos, con retornos de carro incorrectos para unix. Si lo abres con "less", verás que lo interpreta como una única linea. El dos2unix lo convierte mal. Observa: cer@nimrodel:~/tmp> wc -l CN_2007_18-01-2007_20-57-16.csv 7 CN_2007_18-01-2007_20-57-16.csv Intento abrirlo directamente con el OO. Ve el csv, le digo que el separador es unicamente el punto y coma, que la codificación es unicode utf-8, le digo que trate las tres primeras columnas como texto, no, todas... ¿Me suena que había una manera de decirle que la primera linea eran rótulos? ... Avanti. Ha importado 13903 lineas - pero no se cuantas hay en realidad. ¿Y los otros formatos que hay, como xml, sirven? Le cambio la extensión al original a .txt, lo abro con el OO como texto plano, separación de párrafos en "CR", grabo como texto plano: cer@nimrodel:~/tmp> wc -l CN_2007_18-01-2007_20-57-16-OOo.txt 15155 CN_2007_18-01-2007_20-57-16-OOo.txt Ya dice el número de lineas correcto. Probemos a importarlo. Le cambio el nombre a .csv. Importo en OOo. Ha importado igualmente 13903, luego eso no funciona, faltan un par de miles de lineas. Hay otra posibilidad más, ahora que lo tengo en texto plano: partirlo por la mitad, importarlas por separado, y luego unirlas. cer@nimrodel:~/tmp> split --lines 10000 CN_2007_18-01-2007_20-57-16-OOo-txt.csv CN_2007_18-01-2007_20-57-16-OOo-txt-split cer@nimrodel:~/tmp> l CN_2007_18-01-2007_20-57-16-OOo-txt-split* - -rw-r--r-- 1 cer users 5086645 2007-01-18 21:31 CN_2007_18-01-2007_20-57-16-OOo-txt-splitaa - -rw-r--r-- 1 cer users 2462902 2007-01-18 21:31 CN_2007_18-01-2007_20-57-16-OOo-txt-splitab cer@nimrodel:~/tmp> mv CN_2007_18-01-2007_20-57-16-OOo-txt-splitaa CN_2007_18-01-2007_20-57-16-OOo-txt-split.aa.csv cer@nimrodel:~/tmp> mv CN_2007_18-01-2007_20-57-16-OOo-txt-splitab CN_2007_18-01-2007_20-57-16-OOo-txt-split.ab.csv cer@nimrodel:~/tmp> wc -l CN_2007_18-01-2007_20-57-16-OOo-txt-split.aa.csv CN_2007_18-01-2007_20-57-16-OOo-txt-split.ab.csv 10000 CN_2007_18-01-2007_20-57-16-OOo-txt-split.aa.csv 5155 CN_2007_18-01-2007_20-57-16-OOo-txt-split.ab.csv 15155 total Primera mitad, 10000 lineas - importa sólo 9355. Segunda mitad, 5155 lineas - importa sólo 4548. Junto las dos partes en una misma hoja, 13904 lineas incluyendo un separador entre ambas partes. Luego el problema no es un límte de tamaño, es un problema con la importación en sí misma, un bug en el OO. Iba a decir que del 10.1, pero acabo de darme cuenta que dices que la 10.2 falla igual. Tú que conoces la estructura de ese fichero podrías averiguar qué lineas le faltan, en qué falla. ¿Funcionaría un diff si grabamos un csv desde el OO? Quizás no. ¿Grabando sólo el campo indice y comparando cuales indices faltan? Por cierto, que me tarda un montón en grabarlo como .odt el OOo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFr9xWtTMYHG2NR9URAojGAJ9l0XGpGDx8tpyfI7CALN7746Lo+ACghWZe kZbvZtavO5Wnhzp7OMjKLbo= =nKmT -----END PGP SIGNATURE-----
El 18/01/07, Carlos E. R. escribió:
Ha importado 13903 lineas - pero no se cuantas hay en realidad.
15.148. Si lo abres con Kwrite se ve correctamente.
¿Y los otros formatos que hay, como xml, sirven?
No, porque necesito eliminar algunas columnas, por eso la necesidad de pasarlo a una hoja de cálculo.
Tú que conoces la estructura de ese fichero podrías averiguar qué lineas le faltan, en qué falla. ¿Funcionaría un diff si grabamos un csv desde el OO? Quizás no. ¿Grabando sólo el campo indice y comparando cuales indices faltan?
Ábrelo con Krwite, está todo correcto y verás las 15.000 líneas. Pero por algún motivo, al abrirlo, importarlo o pegarlo a Calc se pierden datos...
Por cierto, que me tarda un montón en grabarlo como .odt el OOo.
Mejor sería como .ods ¿no? Un problema raro, la verdad. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-18 a las 22:55 +0100, Camaleón escribió:
Ha importado 13903 lineas - pero no se cuantas hay en realidad.
15.148. Si lo abres con Kwrite se ve correctamente.
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.
¿Y los otros formatos que hay, como xml, sirven?
No, porque necesito eliminar algunas columnas, por eso la necesidad de pasarlo a una hoja de cálculo.
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.
Tú que conoces la estructura de ese fichero podrías averiguar qué lineas le faltan, en qué falla. ¿Funcionaría un diff si grabamos un csv desde el OO? Quizás no. ¿Grabando sólo el campo indice y comparando cuales indices faltan?
Ábrelo con Krwite, está todo correcto y verás las 15.000 líneas. Pero por algún motivo, al abrirlo, importarlo o pegarlo a Calc se pierden datos...
Eso ya lo he dicho. Necesitas un café ;-) 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é.
Por cierto, que me tarda un montón en grabarlo como .odt el OOo.
Mejor sería como .ods ¿no?
.ods, sí, así está. Tarda mucho en grabarlo. Ya sé porqué falla. Tenemos las columnas de la A (Level) a la I (Self-explanatory texts in German). Pero si te vas a la fila 478 observarás que llega hasta la columna IS !! 0302 21 10;--- Lesser or Greenland halibut (Reinhardtius hippoglossoides); fila codigo 477 '030221000010 478 '030221000080" ---- fila muy larga 479 '030341900080 El problema ocurre en la celda I478, que la interpreta como: Heilbutt Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis", frisch oder gekühlt" "6" Cuando en realidad el "6" pertenece a la fila siguiente. No veo ningún problema en el fichero .csv del cual toma esos datos, las lineas están partidas correctamente (después de convertir los retornos de carro, ojo). El problema está en las comillas que "ve" el OOo.Veamos: CSV: ;"Heilbutt "Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis", frisch oder gekühlt" OOo-calc, I478: Heilbutt Reinhardtius hippoglossoides, Hippoglossus hippoglossus, Hippoglossus stenolepis", frisch oder gekühlt" "6" .........^ 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. Este problema se repite en varias filas, son fáciles de encontrar (te posicioneas en la columna "J" y das ctrl-down para encontrar la siguiente celda llena. 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. 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. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsAK+tTMYHG2NR9URAmjYAJ9Vjwo2blDHAmkUgsA+j6ZtHuxrEgCcDTI/ 3Yl3ADKoe+EzFhQxh6oU+JI= =JI4K -----END PGP SIGNATURE-----
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.
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 :-)
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.
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!
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...
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.
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 :-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----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-----
El 19/01/07, Carlos E. R. escribió:
Y sin dividirlo, tomate otro café doble a mi salud :-p
Que he hecho varias pruebas distintas ;-)
Glop, glop, glop. A ver si ahora se me abren los ojos... ya está O_O
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 lo he bajado, y además de ser un fichero de 20 MB. no puedo trabajar con él. No por el formato, es xml estándar y limpio, pero no veo la forma de que me lo ponga como debe. Ains.
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.
Este formato ya ni lo pruebo porque no me sirve, tengo que trabajar con el fichero antes y en html sólo me empeora la situación.
Que no es eso. Ese café ;-)
Glop, glop...
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 ;-)
Bueno, como soy muy brutica estoy haciendo un "find and replace comillas por nada" en OO. A ver si me pita la placa por la temperatura del micro X-)
No lo se.
Yo sí, al menos en Excel se comporta igual y corta los campos.
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.
Los campos de texto pueden tener comillas en cualquier parte del campo, no sólo en una posición definida.
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.
Anda que no es extenso el código ascii, juver, que cojan un carácter distinto, por ejemplo ╩ (alt+458) ;-)
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.
Pasa con Excel.
Ponle a abrir el html. Tuve que matarlo para cerrarlo.
Ahora, cuando termine de reemplazar :-D
Mirando otra vez la 478...
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.
Sí, ya verás que rápido lo soluciono... cuando termine de reemplazar todas las comillas ya veremos.
Oye, ¿y tanto bacalao del pacífico, hypoglosusnosecuantos, pa'que sirve, que rayos es ese fichero? :-p
Es la nomenclatura combinada (sistema arancelario y de codificación de mercancías europeo), vamos, tan conocido como el eMule :-) Saludos, -- Camaleón =��u��y��jV���+��"�f�u맙��j7������ zϮ�˛���m�)z{.��+���j��zw�zZ� yثy�"�w�r����&jw^�y��ƣy�)z{.������^�ˬz��
2007/1/19, Camaleón:
Ahora, cuando termine de reemplazar :-D
Ondiá, Kwrite ha reemplazado todas las comillas en menos de 1 segundo :-O A ver si puedo trabajar ahora. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2007/1/19, Camaleón:
A ver si puedo trabajar ahora.
No, no sirve, las comillas tienen que estar porque separan bloques como los puntos y comas... han utilizado puntos y comas y comillas para separar campos y dentro del texto, es de locos. Nota mental: ¿quién habrá hecho este documento, con este formato...>:-)? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :) El Viernes, 19 de Enero de 2007 12:53, Camaleón escribió:
2007/1/19, Camaleón:
A ver si puedo trabajar ahora.
No, no sirve, las comillas tienen que estar porque separan bloques como los puntos y comas... han utilizado puntos y comas y comillas para separar campos y dentro del texto, es de locos.
¿awk + sed? En un correo anterior decías que tenías que eliminar determinadas columnas -> awk. Si quieres reemplazar texto/caracteres -> sed. Si no te gustan, tienes Perl. Si tienes problemas porque es un doc de MS-DOS ... dos2unix. Sé que conoces estas herramientas, pero como he visto que Carlos te aconsejaban café ... a lo mejor tanto pegarse con el ficherito ... has pasado por alto estas herramientas.
Nota mental: ¿quién habrá hecho este documento, con este formato...>:-)?
Mejor no saberlo ;) HTH Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2007/1/19, Rafa Grimán:
¿awk + sed?
¿Lo qué? :-?
En un correo anterior decías que tenías que eliminar determinadas columnas -> awk. Si quieres reemplazar texto/caracteres -> sed.
Ah. Tomo nota.
Sé que conoces estas herramientas, pero como he visto que Carlos te aconsejaban café ... a lo mejor tanto pegarse con el ficherito ... has pasado por alto estas herramientas.
No han tenido el gusto de presentarnos :-) No, en serio, no las conozco, pero ya lo tengo solucionado. De todas formas, he utilizado Kwrite para remplazar (qué rápido es), no las comillas sino la columna conflictiva, no me fio de OO. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 12:53 +0100, Camaleón escribió:
2007/1/19, Camaleón:
A ver si puedo trabajar ahora.
No, no sirve, las comillas tienen que estar porque separan bloques como los puntos y comas... han utilizado puntos y comas y comillas para separar campos y dentro del texto, es de locos.
Nota mental: ¿quién habrá hecho este documento, con este formato...>:-)?
El access, creo. A ver, hay que reemplazar estas tres cadenas solamente: ";" --> ; [czolinea]; --> [czolinea] ;[finlinea] --> [finlinea] Y efectivamente, la herramienta ideal sería sed, que se puede automatizar. En hexadecimal, son las cadenas - sí, es mejor hacerlo en hexadecimal: 22 3B 22 --> 3B 22 0D 22 --> 22 0A 22 Y dos excepciones, al principio y fin del fichero: 22 --> borrarlo. 22 0D --> 22 0A El '0D' es 'CR', y hay que cambiarlo por '0A', o sea, LF, "a la unix" (man ascii). ¿Se puede hacer eso con sed? No estoy ducho en sed. ¿Rafa? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsMDhtTMYHG2NR9URAo64AKCXFFL2hrPpi2H5zBlJ/10pftDHSQCfb+3N 6bkYf5vDpCxZHtacTVJmJ0I= =Cr/3 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 14:00 +0100, escribí:
En hexadecimal, son las cadenas - sí, es mejor hacerlo en hexadecimal:
22 3B 22 --> 3B 22 0D 22 --> 22 0A 22
Y dos excepciones, al principio y fin del fichero:
22 --> borrarlo. 22 0D --> 22 0A
El '0D' es 'CR', y hay que cambiarlo por '0A', o sea, LF, "a la unix" (man ascii).
¿Se puede hacer eso con sed? No estoy ducho en sed. ¿Rafa?
Bueno, lo he hecho en pascal: program quitacomillascsv; var c1,c2,c3: char; contador: longword; begin contador:= 0; while not eof(input) and (contador < 3) do begin c1:= c2; c2:= c3; read(c3); inc(contador); end; {variables inicializada} {Excepcion inicial tratada} while not eof(input) do begin c1:= c2; c2:= c3; read(c3); inc(contador); if (c1= char($22)) and (c2=char($3B)) and (c1= char($22)) then begin write(c2); read(c2,c3); inc(contador,2); continue; end; if (c1= char($22)) and (c2= char($0D)) and (c1= char($22)) then begin write(char($0A)); read(c2,c3); inc(contador,2); continue; end; write(c1); end; end. Uso: cat CN_2007_18-01-2007_20-57-16-original.csv | quitacomillascsv > CN_2007_18-01-2007_20-57-16-pascal.csv Y funciona, el OOo importa las 15148 lineas correctamente. :-)) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsM2GtTMYHG2NR9URAqACAJ0RDtKkZvUmYFQU565Q0Gz9hJMWRACaAmy4 ZKZqosY/HmVHcS8trVurgPM= =pyVy -----END PGP SIGNATURE-----
El 19/01/07, Carlos E. R. escribió:
Bueno, lo he hecho en pascal:
Ondiá.
Uso:
cat CN_2007_18-01-2007_20-57-16-original.csv | quitacomillascsv > CN_2007_18-01-2007_20-57-16-pascal.csv
Y funciona, el OOo importa las 15148 lineas correctamente.
Bueno, voy a probarlo. Hum. ¿hace falta algún intérprete o programa para ejecutarlo? ¿guardarlo con alguna extensión en concreto, permisos de ejecución? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 15:30 +0100, Camaleón escribió:
El 19/01/07, Carlos E. R. escribió:
Bueno, lo he hecho en pascal:
Ondiá.
Gustos raros que tiene uno O:-)
Bueno, voy a probarlo. Hum. ¿hace falta algún intérprete o programa para ejecutarlo? ¿guardarlo con alguna extensión en concreto, permisos de ejecución?
Hace falta el compilador de pascal, obviamente ;-) El fichero es un loquesea.pas, y se compila: cer@nimrodel:~/bin/pascal/quitacomillascsv> fpc quitacomillascsv.pas Free Pascal Compiler version 2.0.4 [2006/08/20] for i386 Copyright (c) 1993-2006 by Florian Klaempfl Target OS: Linux for i386 Compiling quitacomillascsv.pas quitacomillascsv.pas(9,13) Warning: Variable "c2" does not seem to be initialized quitacomillascsv.pas(10,13) Warning: Variable "c3" does not seem to be initialized Linking quitacomillascsv 39 Lines compiled, 0.4 sec Es el freepascal (http://www.freepascal.org/). Antes venía en la distro, ahora no. Te mandaré el binario del programa, acabas antes. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsN/utTMYHG2NR9URAjOKAJwKP8TRndty3KOZv83n0dU5DfxSsACgjBZY EuSY3ymbk2qJwE5xoWnBUow= =El60 -----END PGP SIGNATURE-----
El 19/01/07, Carlos E. R. escribió:
Te mandaré el binario del programa, acabas antes.
:-) Mejor Saludos agradecidos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 16:32 +0100, Camaleón escribió:
El 19/01/07, Carlos E. R. escribió:
Te mandaré el binario del programa, acabas antes.
:-) Mejor
Saludos agradecidos,
Lo tenía preparado los anexos, pero de repente me he dado cuenta que tiene errores. La primera linea la convierte bien: "Level";"Code";"Code";"Description";"Supplementary unit";"Description of supplementary unit";"Self-explanatory texts in English";"Self-explanatory texts in French";"Self-explanatory texts in German" a: Level;Code;Code;Description;Supplementary unit;Description of supplementary unit;Self-explanatory texts in English;Self-explanatory texts in French;Self-explanatory texts in German Pero a partir de ahí, falla con las celdas vacías: "1";"010011000090";"I";" SECTION I - LIVE ANIMALS; ANIMAL PRODUCTS";"";"";"LIVE ANIMALS; ANIMAL PRODUCTS";"ANIMAUX VIVANTS ET PRODUITS DU RÈGNE ANIMAL";"LEBENDE TIERE UND WAREN TIERISCHEN URSPRUNGS" convertido a: 1;010011000090;I; SECTION I - LIVE ANIMALS; ANIMAL PRODUCTS;;;LIVE ANIMALS; ANIMAL PRODUCTS;ANIMAUX VIVANTS ET PRODUITS DU RÈGNE ANI2 ¿Ves los tres puntos y comas seguidos? Lo he arreglado un poco más, pero me sigue fallando, y ahora mismo no puedo entrenerme. Por eso nunca se sabe a priori el plazo de entrega de un programa sin bugs ;-) Espera, es que soy yo el que necesita café, es mi hora de la siesta O:-) ¡El CSV está bien! Las celdas vacías se convierten en eso, en puntos y coma seguidos. EL fichero está bien tratado por mi parte en cuanto a las comillas. Es que las celdas están mal hechas por los europeanos esos. :-/ A ver, examino una que el calc pone mal, la linea 5. Original: "5";"010110100080";"0101 10 10";"-- Horses";"p/st";"DE: Anzahl Stück; EN: Number of items; FR: Nombre de pièces";"Pure-bred breeding horses";"Chevaux reproducteurs de race pure";"Zuchtpferde, reinrassig" "5";"010110900080";"0101 10 90";"-- Other";"p/st";"DE: Anzahl Stück; EN: Number of items; FR: Nombre de pièces";"Pure-bred breeding asses";"Ânes reproducteurs de race pure";"Zuchtesel, reinrassig" Convertido por mi programa a: 5;010110100080;0101 10 10;-- Horses;p/st;DE: Anzahl Stück; EN: Number of items; FR: Nombre de pièces;Pure-bred breeding horses;Chevaux reproducteurs de race pure;Zuchtpferde, reinrassig 5;010110900080;0101 10 90;-- Other;p/st;DE: Anzahl Stück; EN: Number of items; FR: Nombre de pièces;Pure-bred breeding asses;Ânes reproducteurs de race pure;Zuchtesel, reinrassig Level; Code; Code; Description; 5; 010110100080; 0101 10 10; -- Horses; ; ; Ya está, ya veo el problema. Hay puntos y comas entre las comillas originales que no son el separador de campo: Supplementary unit;Description of supplementary unit; "p/st";"DE: Anzahl Stück; EN:Number of items; FR: Nombre de pièces" que lo he traducido a: p/st;DE: Anzahl Stück; EN: Number of items; FR: Nombre de pièces por lo que tiene celdas extras. Vale, pues como tengo mi código, cambio "mis" puntos y comas por "|". Ya funciona. Te lo mando. Y me debes una siesta :-P No funciona, hay otroproblema en la linea 1123 y algunas más, pero eso sí que no lo miro ahora. ¡Mi siesta! - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsPHltTMYHG2NR9URAthhAJkBDxGsggRJgxR5pzb0iSFU7mdb2wCeL5DB TPTuYxr1MWN/oVosY4kS30E= =9qYS -----END PGP SIGNATURE-----
El 19/01/07, Carlos E. R. escribió:
Lo tenía preparado los anexos, pero de repente me he dado cuenta que tiene errores.
Tsk, tsk... (Nota mental: creo que voy a empezar a leer tus correos de abajo hacia arriba, que es donde está "la chicha" :-D)
Espera, es que soy yo el que necesita café, es mi hora de la siesta O:-)
¿Siesta? ¿Eso que es...? :-P
A ver, examino una que el calc pone mal, la linea 5.
Ya está, ya veo el problema. Hay puntos y comas entre las comillas originales que no son el separador de campo:
Pues eso decía en el correo anterior: <correo anterior> han utilizado puntos y comas y comillas para separar campos y dentro del texto, es de locos.
No funciona, hay otroproblema en la linea 1123 y algunas más, pero eso sí que no lo miro ahora. ˇMi siesta!
Carlos, en estos casos hay que decir, sencillamente: ¡que se vayan a freir espárragos!, es un formato infumable. Se supone que ponen los ficheros para facilitar el trabajo, pero ya ves... Ya lo he solucionado elimiando a lo bruto las columnas que dan error, las que llevan ";" en medio de las "" y rompen la transformación. Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 17:41 +0100, Camaleón escribió:
El 19/01/07, Carlos E. R. escribió:
Lo tenía preparado los anexos, pero de repente me he dado cuenta que tiene errores.
Tsk, tsk...
(Nota mental: creo que voy a empezar a leer tus correos de abajo hacia arriba, que es donde está "la chicha" :-D)
Es que según escribo, voy pensando, pero no borro lo anterior, es "el histórico".
Espera, es que soy yo el que necesita café, es mi hora de la siesta O:-)
¿Siesta? ¿Eso que es...? :-P
Algo que debería ser obligatorio ;-)
A ver, examino una que el calc pone mal, la linea 5.
Ya está, ya veo el problema. Hay puntos y comas entre las comillas originales que no son el separador de campo:
Pues eso decía en el correo anterior:
<correo anterior> han utilizado puntos y comas y comillas para separar campos y dentro del texto, es de locos.
Sí, lo recuerdo.
No funciona, hay otroproblema en la linea 1123 y algunas más, pero eso sí que no lo miro ahora. ¡Mi siesta!
Carlos, en estos casos hay que decir, sencillamente: ¡que se vayan a freir espárragos!, es un formato infumable. Se supone que ponen los ficheros para facilitar el trabajo, pero ya ves...
Ya lo he solucionado elimiando a lo bruto las columnas que dan error, las que llevan ";" en medio de las "" y rompen la transformación.
Pues yo tengo curiosidad. A ver, la linea 1123 original es: [Inciso: Había un tipo de letra en xterm que se llamaba "unreadable", y que ya no viene, pero que necesito para ciertos copypastes - de una tacada podría empastar la linea siguiente] "5";"040630100080";"0406 30 10"; "-- In the manufacture of which no cheeses other than Emmentaler, Gruyère and Appenzell have been used and which may contain, as an addition, Glarus herb cheese (known as Schabziger); put up for retail sale, of a fat content by weight in the dry matter not exceeding 56 %";"Processed cheese, not grated or powdered, in the manufacture of which no cheeses other than Emmentaler, Gruyère and Appenzell have been used and which may contain, as an addition, Glarus herb cheese "known as Schabziger"; put up for retail sale, of a fat content by weight in the dry matter of <= 56%";"Fromages fondus, autres que râpés ou en poudre, dans la fabrication desquels ne sont pas entrés d''autres fromages que l''emmental, le gruyère et l''appenzell et, éventuellement, à titre additionnel, du fromage de Glaris aux herbes [dit ''schabziger''], conditionnés pour la vente au détail, d''une teneur en matières grasses en poids de la matière sèche <= 56%";"Schmelzkäse, weder gerieben noch in Pulverform, zu dessen Herstellung keine anderen Käsesorten als Emmentaler, Greyerzer und Appenzeller, und gegebenenfalls als Zusatz auch Glarner Kräuterkäse "sog. Schabziger" verwendet worden sind, in Aufmachungen für den Einzelverkauf, mit einem Fettgehalt in der Trockenmasse von <= 56 GHT" Menuda parrafada en una sóla linea. Partámoslo: Level;Code;Code; "5";"040630100080";"0406 30 10"; Description; "-- In the manufacture of which no cheeses other than Emmentaler, Gruyère and Appenzell have been used and which may contain, as an addition, Glarus herb cheese (known as Schabziger); put up for retail sale, of a fat content by weight in the dry matter not exceeding 56 %"; Supplementary unit;Description of supplementary unit; "-";""; Hasta aquí el OOo lo hace bien. Self-explanatory texts in English;Self-explanatory texts in French;Self-explanatory texts in German "Processed cheese, not grated or powdered, in the manufacture of which no cheeses other than Emmentaler, Gruyère and Appenzell have been used and which may contain, as an addition, Glarus herb cheese "known as Schabziger"; put up for retail sale, of a fat content by weight in the dry ^ En ese punto y coma se corta, y pasa a la siguiente celda. ¿Eso puede ser culpa de mi programita? Pues si que lo es..: "known as Schabziger|put up for retail sale ^ Pues si que... un bug conocido. Veamos... joer: if (c1= char($22)) and (c2=char($3B)) and (c1= char($22)) {";"} Tiene que ser: if (c1= char($22)) and (c2=char($3B)) and (c3= char($22)) {";"} ¿Será posible el despiste? Fale, pues corregido. Ya importa el OOo-calc las 15148 lineas correctamente. El programita queda así: program quitacomillascsv; var c1,c2,c3: char; contador: longword; skip: word; begin contador:= 0; skip:= 0; while not eof(input) and (contador < 3) do begin c1:= c2; c2:= c3; read(c3); inc(contador); end; {variables inicializada} {Excepcion inicial tratada} while not eof(input) do begin c1:= c2; c2:= c3; read(c3); inc(contador); if skip > 0 then begin dec(skip); continue; end; if (c1= char($22)) and (c2=char($3B)) and (c3= char($22)) {";"} then begin write('|'); skip:=2; continue; end; if (c1= char($22)) and (c2= char($0D)) and (c3= char($22)) {"^M"} then begin write(char($0A)); skip:=2; continue; end; write(c1); end; end. Y no te libras, que te lo voy a mandar al privado :-P Lo que no entiendo es en qué se queda trabajando el OOo con ese fichero cuando lo abro, está un cuarto de hora con toda la cpu que puede pillar, hasta que termina nosequé y descansa. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsU/ntTMYHG2NR9URAlQfAJ4kUbYn9uQh+WeNQIDp/QMXg5w2cACfY98k A5toEeNfQS0rs1Jhe/KwuBc= =TpPm -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 12:34 +0100, Camaleón escribió:
El 19/01/07, Carlos E. R. escribió:
Y sin dividirlo, tomate otro café doble a mi salud :-p
Que he hecho varias pruebas distintas ;-)
Glop, glop, glop. A ver si ahora se me abren los ojos... ya está O_O
Je, yo en uno de esos cursos de empresa, entre pausa y pausa creo que me tomé cuatro o cinco cafes con chocolate de esos de máquina. Al día siguiente tuve que ausentarme del trabajo por causa mayor, ¡imagínate cual! ;-)
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 lo he bajado, y además de ser un fichero de 20 MB. no puedo trabajar con él. No por el formato, es xml estándar y limpio, pero no veo la forma de que me lo ponga como debe. Ains.
No se como trabajar con los xml :-(
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.
Este formato ya ni lo pruebo porque no me sirve, tengo que trabajar con el fichero antes y en html sólo me empeora la situación.
No, mi idea era abrir el html en OOo-writer, selecionarlo por completo y hacer copy paste en el OOo-calc, de forma que meta cada celda de la tabla html en una celda del calc. Si lo hace bien, funciona (yo lo he hecho con otros más pequeños), pero con este mi cacharro es demasiado lento para poder hacerlo.
Que no es eso. Ese café ;-)
Glop, glop...
X-)
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 ;-)
Bueno, como soy muy brutica estoy haciendo un "find and replace comillas por nada" en OO. A ver si me pita la placa por la temperatura del micro X-)
No son todas las comillas, te lo he puesto en otro mensaje.
No lo se.
Yo sí, al menos en Excel se comporta igual y corta los campos.
Ah, pos que bien.
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.
Los campos de texto pueden tener comillas en cualquier parte del campo, no sólo en una posición definida.
Sí y no. Pueden tenerlas, pero el significado es distinto. Una comilla detrás de un punto y coma separador de campo significa que lo que va a continuación es un string, y que terminará cuando encuentre la siguiente comilla doble pegada a otro separador de campo. El bug es que si la comilla no está pareada, no lee el punto y coma.
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.
Anda que no es extenso el código ascii, juver, que cojan un carácter distinto, por ejemplo ? (alt+458) ;-)
Sí, se puede escoger cualquiera. Y las comillas interiores pueden escaparse (\"). Supongo, no conozco las especificaciones del csv estandard, si es que existen.
Mirando otra vez la 478...
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.
Sí, ya verás que rápido lo soluciono... cuando termine de reemplazar todas las comillas ya veremos.
Je je... ya he visto que no :-p
Oye, ¿y tanto bacalao del pacífico, hypoglosusnosecuantos, pa'que sirve, que rayos es ese fichero? :-p
Es la nomenclatura combinada (sistema arancelario y de codificación de mercancías europeo), vamos, tan conocido como el eMule :-)
Ah, que guais. Vamos, la enciclopedia galactica de todos los productos :-p - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsMQWtTMYHG2NR9URAh4MAJwKnCv6iNJsLcpxasP84cCFaSS85wCfeRrl YMhJHnNFZJFfCc2KqJQF8V4= =IXRi -----END PGP SIGNATURE-----
El Jueves, 18 de Enero de 2007 15:14, Camaleón escribió:
Hola,
¿Alguien sabe si es posible trabajar con ficheros de datos que contienen más de 20.000 filas en Calc?
Cuando he abierto el fichero (csv) me ha dicho que se ha excedido en el límite y algunas filas se han eliminado... y es cierto, de 16.500 sólo hay 13.500.
¿Alguna idea? La versión de OpenOffice es la que viene con SuSE 10.1.
Saludos, Es un fallo del filtro csv, si lo importas sin separar lo hace bien estoy probando con :
Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Viernes, 19 de Enero de 2007 08:41, francisco F. escribió:
El Jueves, 18 de Enero de 2007 15:14, Camaleón escribió:
Hola,
¿Alguien sabe si es posible trabajar con ficheros de datos que contienen más de 20.000 filas en Calc?
Cuando he abierto el fichero (csv) me ha dicho que se ha excedido en el límite y algunas filas se han eliminado... y es cierto, de 16.500 sólo hay 13.500.
¿Alguna idea? La versión de OpenOffice es la que viene con SuSE 10.1.
Saludos,
Es un fallo del filtro csv, si lo importas sin separar lo hace bien estoy probando con :
Mas pruebas. No se si os disteis cuenta pero si que importa todo el documento, porque la ultima linea es la ultima (que cosas) El problema viene por el medio, que parece se deja lineas. Lo paso en la lista de OOo a ver si alguien saca algo mas en claro --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-01-19 a las 08:50 +0100, francisco F. escribió:
Mas pruebas. No se si os disteis cuenta pero si que importa todo el documento, porque la ultima linea es la ultima (que cosas) El problema viene por el medio, que parece se deja lineas. Lo paso en la lista de OOo a ver si alguien saca algo mas en claro
Mira en uno de mis correos de ayer que pongo la linea exacta en la que se traba y el porqué, y se lo dices a ellos para que vean porqué en esa linea se equivoca con una de las dobles comillas, y en cambio en otras lineas que también las tienen no tienen problemas. Una posible solución sería que interpretase el caracter de fin de linea como mandatorio aunque esté dentro de lo que cree que son comillas. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFsJowtTMYHG2NR9URAsPxAJ9LuBXeS0oYaFbjibjRh/zTEWDI+ACfezQw GDgebPgnmq7fSVkfdygDH18= =VU04 -----END PGP SIGNATURE-----
participants (7)
-
admin-listas -
Camaleón -
Carlos E. R. -
Doctor Nemo -
francisco F.
-
Juan Gustavo Fogelman -
Rafa Grimán