Christoph Zwerschke wrote:
I noticed that Python does not understand the codec alias names
latin7 = iso8859-13, latin9 = iso8859-15
(see http://docs.python.org/lib/standard-encodings.html).
Particularly latin9 is pretty popular here in Western Europe since it
contains the Euro symbol (contrary to latin1).
One learns new things every day, I suppose: I've always referred to it
as ISO-8859-15, using whatever combination or absence of "_" or "-"
symbols that is deemed appropriate.
According to the Wikipedia (http://en.wikipedia.org/wiki/ISO-8859), the
latin7 and latin9 aliases seem to be official, at least they are widely
used an accepted. In PostgreSQL, LATIN9 is even the name of the charset,
and iso8859-15 is the alias name:
http://www.postgresql.org/docs/8.2/s...#CHARSET-TABLE
My impression of relational databases is that they often have lots of
legacy names for things like character encodings. A different
perspective may be had by looking at the XML standards where encodings
and their naming have received a great deal of attention:
http://www.w3.org/TR/REC-xml/#NT-EncodingDecl
It may be acceptable even in XML to use latin9 as an encoding name, but
since the XML specifications appear to recommend the ISO names, and
since XML has quite possibly raised awareness and usage of encoding
declarations to previously unknown levels, there may be some benefit in
conservatively shadowing XML and the expectations of its users (and of
the wider Web page authoring community, amongst others). One would have
to look into the rationale of the standards makers to understand why
they've made those particular recommendations, however.
Is there anything speaking against adding these as aliases? If no, I
would submit a patch. (Also, Python does not support the
latin10=iso8859-16 charset. I could try to add that as well.)
I don't see any disadvantages in having aliases, provided that they're
unambiguous, but then I'm far from being any person who is going to be
making that particular call.
Paul
