Verrückt mit Umlauten

[hotti]

hi,

  
$mesg  =  sprintf("%-10s %-5s\n", 'Name', 'Ort');  
$mesg .=  sprintf("%-10s %-5s\n", 'Otto', 'Hamburch');  
$mesg .=  sprintf("%-10s %-5s\n", 'Horst', 'FFM');  
$mesg .=  sprintf("%-10s %-5s\n", 'Jürgen', 'Wiesbaden');  

Es steht alles schön untereinander, jedoch
Name       Ort
Otto       Hamburch
Horst      FFM
Jürgen    Wiesbaden

Der mit dem 'ü' rückt ein Zeichen nach links. Hätte er zwei 'ü's, würde die Einrückung zwei Stellen weiter nach links verschoben. Das ist der Effekt, der mich etwas nervös macht.

Die Datei ist in UTF-8 und die Schriftart ist Courier. Ausgabe im Browser mit Content-Type: text/plain; Charset=UTF-8. Kein Kodierungsproblem. Nur etwas verrückt ;)

Und jetzt wirds spannend: Fürs PDF nehme ich utf8_decode (nach ISO-8859-1), die Zeichen sind korrekt dargestellt. Mit Font Courier steht auch alles schön untereinander ausgerichtet. Nur eben genauso verrückt wie die Ausgabe im Browser in UTF-8 text/plain.

Was verrückt hier?
Bitte mal um Hinweise,
evntl. gibts einen Wörkaraund,
Hottü

[dedlfix]

Tach!

$mesg .=  sprintf("%-10s %-5s\n", 'Jürgen', 'Wiesbaden');
Der mit dem 'ü' rückt ein Zeichen nach links.

PHPs sprintf() kann wie alle anderen Stringfunktionen (noch) nicht mit Mehr-Byte-Kodierungen umgehen.

dedlfix.

[hotti]

hi,

$mesg .=  sprintf("%-10s %-5s\n", 'Jürgen', 'Wiesbaden');
Der mit dem 'ü' rückt ein Zeichen nach links.

PHPs sprintf() kann wie alle anderen Stringfunktionen (noch) nicht mit Mehr-Byte-Kodierungen umgehen.

Das verwirrt mich umso mehr, nach meiner Logik müsste der Kram dann ja nach rechts rücken und nicht nach links.

Des Weitern: wenn utf8_decode aus dem utf-8-'ü' ein iso-'ü' macht hat das iso 'ü' auch nur ein Byte wie alle anderen Zeichen und sollte demnach auch genausoviel Platz für sich beanspruchen.

Seltsam ;)

[Der Martin]

Hallo,

$mesg .=  sprintf("%-10s %-5s\n", 'Jürgen', 'Wiesbaden');
Der mit dem 'ü' rückt ein Zeichen nach links.
PHPs sprintf() kann wie alle anderen Stringfunktionen (noch) nicht mit Mehr-Byte-Kodierungen umgehen.
Das verwirrt mich umso mehr, nach meiner Logik müsste der Kram dann ja nach rechts rücken und nicht nach links.

deine Logik ist verkehrtrum: Du hast den UTF-8-codierten String "Jürgen". Das sind 6 Zeichen, aber 7 Bytes. Nun soll sprintf() auf 10 Zeichen auffüllen - sprintf() hängt an den 7-Byte-String also nur noch 3 anstatt 4 Leerzeichen an, weil die Funktion davon ausgeht, dass Zeichen und Bytes dasselbe sind.

Des Weitern: wenn utf8_decode aus dem utf-8-'ü' ein iso-'ü' macht hat das iso 'ü' auch nur ein Byte wie alle anderen Zeichen und sollte demnach auch genausoviel Platz für sich beanspruchen.

Wo codierst du von UTF-8 nach ISO um? Nach dem Formatieren mit spintf() oder davor? Wenn du es danach erst tust, ist es zu spät, dann wird die um 1 Zeichen versetzte Ausrichtung nur transformiert, so wie sie ist.

Seltsam ;)

Eigentlich nicht.

Ciao,
 Martin

[hotti]

Oh Martin,

deine Logik ist verkehrtrum: Du hast den UTF-8-codierten String "Jürgen". Das sind 6 Zeichen, aber 7 Bytes. Nun soll sprintf() auf 10 Zeichen auffüllen - sprintf() hängt an den 7-Byte-String also nur noch 3 anstatt 4 Leerzeichen an, weil die Funktion davon ausgeht, dass Zeichen und Bytes dasselbe sind.

Danke!!
(Ich sollte vielleicht doch mal wieder plusminus gucken)

Wo codierst du von UTF-8 nach ISO um? Nach dem Formatieren mit spintf() oder davor? Wenn du es danach erst tust, ist es zu spät, dann wird die um 1 Zeichen versetzte Ausrichtung nur transformiert, so wie sie ist.

Hab alles noch am heutigen Abend geschafft, jetzt darf ich Feierabend machen ;)

Hotti

[Matthias Apsel]

Om nah hoo pez nyeetz, hotti!

Und jetzt schaltest du noch auf die Develansicht, damit du sehen kannst, wie sich dein fachlich-hilfreich bemerkbar macht.

Matthias

[hotti]

hi,

Und jetzt schaltest du noch auf die Develansicht, damit du sehen kannst, wie sich dein fachlich-hilfreich bemerkbar macht.

Jetzt habe ich doch nochmal ne Frage: Gibt es irgendwo Statistiken darüber, wieviele Stunden Programmierung durchschnittlich erforderlich sind zur Programmierung eines Online-Shops?

Vom DB-Design über Klassenentwurf bis zum Frontend im Browser und Backends für Artikelverwaltung und Buchhaltung sowie Schnittstellen für ERP und Webservices (Letzeres nicht komplett, aber möglich zum Nachrüsten).

Hotti

[dedlfix]

Tach!

Der mit dem 'ü' rückt ein Zeichen nach links.
Das verwirrt mich umso mehr, nach meiner Logik müsste der Kram dann ja nach rechts rücken und nicht nach links.

Nein, es wird ein Leerzeichen zu wenig eingefügt, weil ja durch das UTF-8-ü zwei Zeichen statt einem verbraucht wurden.

Des Weitern: wenn utf8_decode aus dem utf-8-'ü' ein iso-'ü' macht hat das iso 'ü' auch nur ein Byte wie alle anderen Zeichen und sollte demnach auch genausoviel Platz für sich beanspruchen.

Vor dem Formatieren umkodieren, nicht danach.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix:

nuqneH

PHPs sprintf() kann wie alle anderen Stringfunktionen (noch) nicht mit Mehr-Byte-Kodierungen umgehen.

Alle Stringfunktionen können mit Mehr-Byte-Kodierungen umgehen. Unter der Rubrik sind allerding neben den Stringfunktionen (die mit 'mb' beginnen) auch haufenweisen Funktionen aufgelistet, die keine Stringfunktionen sind.

Qapla'

[hotti]

Ok,

der gemeinsame Nenner ist die PDF Datei und da muss alles in ISO sein. Mein Billing-Modul hat bisher alles in UTF-8 zurückgegeben und ich hatte es erst zur PDF-Erstellung nach ISO umgeschossen.

Und so verrückt es jetzt nicht mehr: utf8_decode() wird bereits im Billing-Modul eingesetzt, etwa so

  
$tab =    sprintf("%-45s %-15s %-5s %14s %14s\n\n",  
	"Artikelbezeichnung", "Artikelnummer",utf8_decode("Stück"),"Netto EUR","Summe EUR");  

Ich habe den Code mal umgeschrieben, getestet und damit passt alles!

Für den Fall, dass ich den bill als text/plain im Browser sehen will, setze ich nunmehr einen Content-Type: text/plain; Charset=ISO-8859-1 und alles sieht gut aus, genauso wie auf der PDF.

Und nochewas: fpdf.php ist eine tolle Sache!!!! Im Vergleich mit Perl PDF::Create um Einiges flinker, die Dateien werden kleiner und die Handhabe im Script ist auch ein bischen einfacher.

Schönes Wochenende!

[Der Martin]

Hallo,

Mein Billing-Modul hat bisher ...
[...] bereits im Billing-Modul eingesetzt ...

meine cerebral-automatische Rechtschreibkorrektur scheint gut zu funktionieren: Ich lese andauernd "Billig-Modul".

*fg*
 Martin

[hotti]

hi,

Mein Billing-Modul hat bisher ...
[...] bereits im Billing-Modul eingesetzt ...

meine cerebral-automatische Rechtschreibkorrektur scheint gut zu funktionieren: Ich lese andauernd "Billig-Modul".

Das ist ein guter Anfang ;)
Im fortgeschrittenem Stadium wird dann _jede_ Rechnung mit Billig assoziiert. Auch gut, anders ist das Leben nicht erträglich.

Genieße jeden Tag und scheis aufs Wetter, auch wenn Du keinen Hund hast.

Horst Billing, Rechnungsleger und Vollstrecker

[Der Martin]

n'Abend,

meine cerebral-automatische Rechtschreibkorrektur scheint gut zu funktionieren: Ich lese andauernd "Billig-Modul".
Das ist ein guter Anfang ;)
Im fortgeschrittenem Stadium wird dann _jede_ Rechnung mit Billig assoziiert.

das ist nicht gut, denn es führt irgendwann zu einer negativen Bilanz zwischen gefühltem und echtem Kontostand.

Genieße jeden Tag und scheis aufs Wetter, auch wenn Du keinen Hund hast.

Oh, heute war das Wetter ja richtig angenehm. Fast 10°C am frühen Nachmittag.
Möge der Winter endlich vorbei sein. Pfui, Winter! Schleich di!

Ciao,
 Martin