AA_
17.04.2008, 12:12
was ich immer noch nicht so richtig verstehe, ist das handling von imports / exports in sachen addons / sprachfiles.
ich glaube auch, dass ich da einen fehler entdeckt habe, der eigentlich gar nicht passieren dürfte, da vbulletin selber die richtigen funktionen zur verfügung stellt aber nicht nutzt ;)
zunächst das problem:
unsere datenbank arbeitet mit UTF-8. exportiere ich einen addon-code, habe ich utf-encodierte strings in der datei, was erstmal korrekt ist. falsch ist hier der xml-header, der eine inhaltscodierung von iso-8859-1 vorgaukelt.
nun arbeite ich nicht mit notepad, sondern mit ide's, die u.a. automatisch die dateikodierung erkennen, allerdings unter berücksichtigung der doctypes und sonstiger meta-angaben in der datei selber. ergebnis ist, dass mir die datei in einem editor als latin1 geöffnet wird und umlaute etc. nicht wie erwartet angezeigt werden.
beispiel:
6274
dieses problem wäre leicht zu beheben, wenn beim export der daten der charset korrekt in die datei geschrieben würde und nicht immer pauschal iso-8859-1 angegeben wird. zur zeit muss ich diese datei "konvertieren" und dem editor erklären, dass er die angabe im dateiheader ignorieren soll und es sich in wahrheit um unicode-daten handelt. damit kann ich gerade noch so leben, auch wenn es schwerfällt. in der praxis ist mir soetwas auch noch nie vorgekommen und da muss man auch nicht lange drüber diksutieren. so wie derzeit ist, ist es falsch. und ich möchte nicht wissen, wieviele leute sich aufgrund dieses fehlers ihre addons / übersetzungen schon zerschossen haben.
weit schwerer wiegt aber folgendes:
halte ich mich an die unrichtige vorgehensweise beim erstellen, bearbeiten von addons oder sprachfiles und importiere ich diese über das acp wird die datei zunächst geöffnet und dann der xml-parser damit gefüttert (plugin.php, ab zeile 163):
$xmlobj = new vB_XML_Parser($xml);
(...)
if(!$arr = $xmlobj->parse())
{die methode parse() hat hier einen parameter für den charset, der aber nicht angesprochen wird (wie auch, wenn keine prüfung erfolgt vorher?):
/**
* Parses XML document into an array
*
* @param string Encoding of the inputted XML file
* @param bool Empty the XML data string after parsing
*
* @return mixed array or false on error
*/
function &parse($encoding = 'ISO-8859-1', $emptydata = true)
{oder mit anderen worten: ich lade eine utf8-codierte datei hoch, die einen falschen header hat und der xml-parser behandelt diese datei dann als iso-8859-1. das ist grottenschlecht und wahrscheinlich dem umstand geschuldet, dass vbulletin kein deutsches produkt ist und sich die entwickler ergo nicht mit umlauten herumärgern müssen und das problem nur von hörensagen kennen.
witziger weise befindet sich in der gleichen xml-klasse die "richtige" funktion! eine funktion, die sich vorher die datei ansieht, den korrekten charset ermittelt, notwendigerweise sogar konvertiert und dann an den parser schickt:
/**
* Handle encoding issues as well as parsing the XML into an array
*
* @return boolean Success
*/
function parse_xml()
{
(...)
if ($this->parse($xml_encoding))
{
(...)
statt einfach die richtige methode anzusprechen, werden in den verschiedensten foren dann haarsträubende tipps verteilt und letztlich findet sich das problem auch wieder in all den hackforen, wo einige addon-entwickler sprachfiles in 2 verschiedenen kodierungen anbieten (latin1 und unicode). das gleiche passiert übrigens auch beim import von sprachfiles: setze ich im header einer utf-8 codierten datei den utf8-charset, erlebe ich mein blaues wunder und finde dann u.U. lauter abgeschnittene phrasen in den übersetzungen wieder (ab dem ersten "ungültigen" oder inkompatiblen zeichen wird dann abgeschnitten).
vbulletin ist eine solch komplexe und durchdachte sache, aber leider mit einem totalversagen in sachen dateiexport/-import. und irgendwie fällt es mir nach so vielen jahren als programmierer schwer, einfache grundregeln zu missachten, nur damit es im produkt vbulletin halbwegs funktioniert. für nichtprogrammier in einer anderen sprache: stell dir vor, du willst kaltes wasser aus der leitung und drehst den blauen hahn auf, verbrühst dir aber ständig die hände, weil heisses wasser rauskommt. anstatt einfach die hähne auszutauschen und richtig anzuordnen, merken wir uns lieber, dass blau nicht kalt, sondern heiss ist. absurd.
und weil ich gerade beim export von daten bin: wann hört das unzulässige und chaotische vermischen von zeilenenden (LF und CRLF innerhalb einer datei) endlich mal auf?
nicht nachvollziehbare vermischung von LF und CRLF
6275
ich glaube auch, dass ich da einen fehler entdeckt habe, der eigentlich gar nicht passieren dürfte, da vbulletin selber die richtigen funktionen zur verfügung stellt aber nicht nutzt ;)
zunächst das problem:
unsere datenbank arbeitet mit UTF-8. exportiere ich einen addon-code, habe ich utf-encodierte strings in der datei, was erstmal korrekt ist. falsch ist hier der xml-header, der eine inhaltscodierung von iso-8859-1 vorgaukelt.
nun arbeite ich nicht mit notepad, sondern mit ide's, die u.a. automatisch die dateikodierung erkennen, allerdings unter berücksichtigung der doctypes und sonstiger meta-angaben in der datei selber. ergebnis ist, dass mir die datei in einem editor als latin1 geöffnet wird und umlaute etc. nicht wie erwartet angezeigt werden.
beispiel:
6274
dieses problem wäre leicht zu beheben, wenn beim export der daten der charset korrekt in die datei geschrieben würde und nicht immer pauschal iso-8859-1 angegeben wird. zur zeit muss ich diese datei "konvertieren" und dem editor erklären, dass er die angabe im dateiheader ignorieren soll und es sich in wahrheit um unicode-daten handelt. damit kann ich gerade noch so leben, auch wenn es schwerfällt. in der praxis ist mir soetwas auch noch nie vorgekommen und da muss man auch nicht lange drüber diksutieren. so wie derzeit ist, ist es falsch. und ich möchte nicht wissen, wieviele leute sich aufgrund dieses fehlers ihre addons / übersetzungen schon zerschossen haben.
weit schwerer wiegt aber folgendes:
halte ich mich an die unrichtige vorgehensweise beim erstellen, bearbeiten von addons oder sprachfiles und importiere ich diese über das acp wird die datei zunächst geöffnet und dann der xml-parser damit gefüttert (plugin.php, ab zeile 163):
$xmlobj = new vB_XML_Parser($xml);
(...)
if(!$arr = $xmlobj->parse())
{die methode parse() hat hier einen parameter für den charset, der aber nicht angesprochen wird (wie auch, wenn keine prüfung erfolgt vorher?):
/**
* Parses XML document into an array
*
* @param string Encoding of the inputted XML file
* @param bool Empty the XML data string after parsing
*
* @return mixed array or false on error
*/
function &parse($encoding = 'ISO-8859-1', $emptydata = true)
{oder mit anderen worten: ich lade eine utf8-codierte datei hoch, die einen falschen header hat und der xml-parser behandelt diese datei dann als iso-8859-1. das ist grottenschlecht und wahrscheinlich dem umstand geschuldet, dass vbulletin kein deutsches produkt ist und sich die entwickler ergo nicht mit umlauten herumärgern müssen und das problem nur von hörensagen kennen.
witziger weise befindet sich in der gleichen xml-klasse die "richtige" funktion! eine funktion, die sich vorher die datei ansieht, den korrekten charset ermittelt, notwendigerweise sogar konvertiert und dann an den parser schickt:
/**
* Handle encoding issues as well as parsing the XML into an array
*
* @return boolean Success
*/
function parse_xml()
{
(...)
if ($this->parse($xml_encoding))
{
(...)
statt einfach die richtige methode anzusprechen, werden in den verschiedensten foren dann haarsträubende tipps verteilt und letztlich findet sich das problem auch wieder in all den hackforen, wo einige addon-entwickler sprachfiles in 2 verschiedenen kodierungen anbieten (latin1 und unicode). das gleiche passiert übrigens auch beim import von sprachfiles: setze ich im header einer utf-8 codierten datei den utf8-charset, erlebe ich mein blaues wunder und finde dann u.U. lauter abgeschnittene phrasen in den übersetzungen wieder (ab dem ersten "ungültigen" oder inkompatiblen zeichen wird dann abgeschnitten).
vbulletin ist eine solch komplexe und durchdachte sache, aber leider mit einem totalversagen in sachen dateiexport/-import. und irgendwie fällt es mir nach so vielen jahren als programmierer schwer, einfache grundregeln zu missachten, nur damit es im produkt vbulletin halbwegs funktioniert. für nichtprogrammier in einer anderen sprache: stell dir vor, du willst kaltes wasser aus der leitung und drehst den blauen hahn auf, verbrühst dir aber ständig die hände, weil heisses wasser rauskommt. anstatt einfach die hähne auszutauschen und richtig anzuordnen, merken wir uns lieber, dass blau nicht kalt, sondern heiss ist. absurd.
und weil ich gerade beim export von daten bin: wann hört das unzulässige und chaotische vermischen von zeilenenden (LF und CRLF innerhalb einer datei) endlich mal auf?
nicht nachvollziehbare vermischung von LF und CRLF
6275