Standards Mode y Quirks Mode

Gracias a haberle leido un tutorial sobre encodings en xhtml, me he enterado que los browsers tienen dos modos de visualización:

• standards mode (fiel a los estándares de la W3C)
• quirks mode

Se puede pasar de uno a otro mediante el 'doctype switching'. En otras palabras: si el documento incluye el doctype, se visualiza en 'standards'; en caso contrario se visualiza como 'quirks'.
La reglas son diferentes, y por lo tanto el resultado visual también.
Si el documento tiene una declaración ?xml antes del doctype, en el caso de IE, provoca que se visualice en quirks mode.

En la siguiente página hay mas información sobre los diferentes doctypes y como se comportan los diferentes navegadores con ellos: Activating the Right Layout Mode Using the Doctype Declaration.

En la siguiente página se detallan algunas diferencias.

HTML compatility guidelines for XHTML

Son de utilidad para cuando el xhtml es servido como html.

Ricardo Galli: por lo visto es el pollo que está detrás de meneame.

Interesante: Banda ancha para el móvil, lo mejor del 3GSM. Habrá que ver el coste...

Detección de encoding en ficheros html/xhtml

Como se indica aquí, en los ficheros html (o xhtml) el encoding debe de estar especificado. Pero la realidad es otra, y es que puede no venir (los estandares especifican uno por defecto) o incluso no corresponderse con el verdadero encoding.

Buscando en la web, no he encontrado nada para hacer la autodetección. Aunque seguire buscando...
Lo único que he encontrado de momento es este thread.
De momento y para salir del paso usaré el comando 'file' de unix.

En los fichero xhtml nos encontramos con una problematica adicional, y es que pueden venir los encodings especificados en el meta y con el este documento, dependerá de su uso, es decir de como se entreguen. Lo cual no deja de ser un problema si el documento lo tenemos en disco y no sabemos como se ha entragado.
Lo que si especifica bien claro es que el encoding de HTTP tiene prioridad (si se indica) sobre el resto.
Y otro link que todavía no he tenido tiempo de mirar...

Actualización
El siguiente tutorial de W3C es muy bueno: Character sets & encodings in XHTML, HTML and CSS.
Y los diferentes valores para el encoding: IANA registry.

Han inventado una pantalla tactil [barrapunto.com] que es la caña.
Aunque barrapunto ha estado lento. Telendro ya lo había publicado hace días.

EBITDA

Hoy me han soltado este termino en una reunión de la compañia. Por lo visto es una medida económica para comparar diferentes empresas, o la evolución de una misma en el tiempo.
Mas info en [1], [2] y [3].

Me pasa vlady esta web: genbeta. Va de actualidad sobre software. No parece estal mal. Habrá que seguirla... Curioso que lanzan busquedas a través de Noxtrum.

La caña el interfaz éste [telendro.com.es].

Un par de enlaces de barrapunto:

• Generadores de código MDA (Model Driven Arquitecture).
  
• VMware mueve ficha. VMware a liberado una versión.
  

Encoding por defecto en xml y html

En XML si no se especifica el encoding, se toma por defecto utf-8, mientras que en html (para text/*) se toma por defecto iso-8859-1.
Para otro tipos de medios, entra en juego la RFP 3023.

Mas información aquí: Determining the character encoding of a feed.

He encontrado un articulo que parece interesante (pero no he leido todavia): The Problem with the Libxml Python Bindings.

Al final del mismo hay un link muy muy interesante: Beware of strangers.
El cual me ha llevado a otros:

• La librería que usa libxml2 para los encodings: libiconv
• Y uno muy interesante sobre los encodings: Determining the character encoding of a feed.
• Un benchmarking de diferentes parser de xml. libxml2 es increiblemente rápido.
  

Parseando html con libxml2

En primer lugar tengo que comentar que no hay mucha documentación del 'binding' a python de libxml2. Básicamente las alternativas de documentarse son:

• Tirar de archivos de las listas: [1] y [2]
  
• Ver la ayuda: desde el interprete usar 'help(libxml2)' o desde la shell 'pydoc libxml2'.
• Ver ejemplos. Con la instalación viene alguno.

A continuación pongo un ejemplo que viene con la distribución (pushSAXhtml.py):


#!/usr/bin/python -u
import sys
import libxml2

# Memory debug specific
libxml2.debugMemory(1)

log = ""

class callback:
def startDocument(self):
global log
log = log + "startDocument:"

def endDocument(self):
global log
log = log + "endDocument:"

def startElement(self, tag, attrs):
global log
log = log + "startElement %s %s:" % (tag, attrs)

def endElement(self, tag):
global log
log = log + "endElement %s:" % (tag)

def characters(self, data):
global log
log = log + "characters: %s:" % (data)

def warning(self, msg):
global log
log = log + "warning: %s:" % (msg)

def error(self, msg):
global log
log = log + "error: %s:" % (msg)

def fatalError(self, msg):
global log
log = log + "fatalError: %s:" % (msg)

handler = callback()

ctxt = libxml2.htmlCreatePushParser(handler, "
chunk = " url='tst'>b"
ctxt.htmlParseChunk(chunk, len(chunk), 0)
chunk = "ar"
ctxt.htmlParseChunk(chunk, len(chunk), 1)
ctxt=None

.../...




El poco tiempo que llevo usandolo ya me ha dado para poder reseñar que:

• Internamente se trabaja con utf-8. Si el encoding viene especificado en el documento no hay problemas. En caso contrario supondrá uno por defecto (no realiza autodetección en este caso). El tema no es nada sencillo, ya que no sólo tenemos este problema, sino que se puede dar el caso de que el encoding no concuerde con lo que viene especificado en la declaración. O incluso que se use más de uno. Vamos una movida... Además en caso de estar parseando xhtml ignora el ?xml. Para xhtml se debería usar el parser xml, pero ¿y si el xhtml no está bien formado? Vamos que aqui hay miga...
  
• Desde el callback no podemos parar el parser. La parada hay que hacerla desde fuera. Lo suyo es hacerla entre el paso de un 'chunk' de datos a otro.
• Con el api de C he visto que el parser te puede notificar que ha habido un problema y que hay que parar, sin embargo esta funcionalidad no es posible en los bindings de python. Según me comenta Daniel Veillard: "The notion of fatal error where the parser stops emitting data (just more error message) exists only in the XML parser." Me parece muy bien, pero esto no explica porque existe esa funcionalidad en el api de C. En los links del post hay un ejemplo de ésto.
  

Y para acabar unos enlaces interesantes:

• htmlParseChunk loop
• SAX HTML still stuck
• htmlParseFile vs htmlParseDoc
• Aborting html sax parsing from python

Un thread en el que se indica porque python está indicado para el desarrollo de crawlers.
En dicho thread comentan sobre google-kongulo, un crawler liberado por google y que se usa en su desktop.

Tambien recomiendan como parser BeatifulSoup. Lo que hace es convertir el html a un arbol (no es SAX; ni tampoco DOM).

libxml2 y el encoding

Ando trasteando con libxml2 y ésta página es la que hay que leer con respecto a los encodings.

Ya hace tiempo puse unos cuantos links sobre encodings; y ahora van un par mas extraidos de la página anterior:

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).
• On the Goodness of Unicode.

Buscando en la web, el único thread que dice algo sobre la autodetección de los encodings para html es éste.

Actualización
Los encodings que soporta son:

• UTF-8
• UTF-16 little endian
• UTF-16 big endian
• UCS-4 little endian
• UCS-4 big endian
• EBCDIC
• UCS-4 unusual ordering (UCS4_2143)
• UCS-4 unusual ordering (UCS4_3412)
• UCS-2
• ISO-8859-1 ISO Latin 1
• ISO-8859-2 ISO Latin 2
• ISO-8859-3
• ISO-8859-4
• ISO-8859-5
• ISO-8859-6
• ISO-8859-7
• ISO-8859-8
• ISO-8859-9
• ISO-2022-JP
• Shift_JIS
• EUC-JP
• ASCII

Una noticia sobre planes de google para incorporar intersticial (vía telendro). Esta bien además de por la noticia, por el repaso a los diferentes formas de 'advertising'.

Para ver los SLDs de los diferentes paises.

Hay un post interesante en ¿Contratación de equipos de desarrollo? [barrapunto.com]

¡Vaya! Nokia usa python. De hecho han liberado código.
Vía barrapunto.

El site de Jose Miguel.