[Pxr-commits] cambios en read.px --- cleanDat

[Oscar Perpiñan Lamigueiro]

Hola!

>Hola, ¿qué tal?
>
>Hacía días que estaba retirado de este asunto. Esencialmente, desde
>que se me rompió el ordenador. Ahora escribo desde el nuevo.
>
>Y respondo abajo.
>>> Estuve trabajando un poco en maneras de leer partes DATA cuando
>>> vienen especificadas las KEYS (una especie de formato "sparse"). En
>>> tal caso, scan dejaría de funcionar pero cleanDat podría
>>> modificarse para aceptar ese tipo de datos. (Aunque tengo tamibén
>>> dudas de si el formato "sparse" se usa realmente: ni Francisco ni
>>> yo creemos haberlo visto por ninguna parte fuera de las
>>> especificaciones del formato).
>>>
>> Ok. Pero creo que podríamos hacer que scan también lo leyese...en
>> todo caso, busquemos algún fichero que nos sirva para trastear.
>
>Yo creo que podríamos dejar esto sin implementar hasta que vamos un
>fichero "de verdad" con dicho formato. Me da la impresión de que no se
>usa. Ninguno de los ficheros que he revisado en los últimos tiempos
>utiliza ese formato. ¡Para qué ponernos la venda antes que sufrir la
>herida!
>

Totalmente de acuerdo.

>La solución que propongo es la siguiente:
>
>1) Codificar todas las cadenas de entrada en el "encoding" nativo (sea
>el que sea) de la plataforma cuanto antes (en el primer scan).
>
>2) Operar siempre en el "encoding" nativo (de nuevo, sea cual sea
>porque da igual realmente) de la plataforma, dado que es el que
>esperan las funciones de manipulación de caracteres.
>
>3) Sólo en las salidas (write.px) recodificar las cadenas al formato
>que espere el usuario.
>
>En las especificaciones del formato PC-Axis no son particularmente
>precisos, pero parecen asumir que DOS/Windows son las únicas
>plataformas que existen. Luego si asumen un "encoding" determinado,
>sólo sabemos que no es UTF-8.
>
>He subido una implementación alternativa de read.px (read.px.alt.R en
>drafts) que:
>
>1) Lee el fichero así:
>
>a <- scan( filename, what = "character", sep = "\n", quiet = TRUE,
>fileEncoding = encoding )
>
>donde "encoding" es un parámetro con "default" "latin1". Por lo tanto,
>el objeto a tiene el "encoding" nativo: será una cadena latin1 en
>Windows y utf-8 en Linux.
>
>2) Como consecuencia de lo anterior, la representación en pantalla de
>las cadenas es la "esperada" (sin símbolos raros) en ambas
>plataformas.
>
>3) No es necesaria la llamada a iconv (que está comentada).
>
>4) He quitado todos los useBytes. ¡No son necesarios! La función
>strsplit funciona correctamente sin esa opción "peligrosa".
>
>La he probado con el fichero problemático EPOB_es_6.px tanto en
>Windows como en Linux y funciona correctamente. Pero no la he probado
>con más ficheros.
>
>Si no hay objeciones al respecto, ¿la damos por buena?
>

Perfecto!! Tiene todo el sentido. Desde luego scan es una función a
estudiar a fondo. Tiene muchos argumentos realmente útiles.

Acabo de probar la función con más ficheros, tanto en Linux como en
windows y funciona a las mil maravillas. Por mí adelante!

Saludos.

Oscar.