Archiv

Archiv für die Kategorie ‘Programmierung’

Mein neues Spielzeug

4. November 2009 Keine Kommentare

Nachdem ich im Sommersemester 09 den Kurs “Eingebettete Prozessoren” belegte, bin ich auf den Geschmack gekommen. Diese kleinen Silizium-Wunderwerke können so einiges und das will ich ausnutzen. Daher habe ich mir ein “Arduino Duemilanove” zugelegt. Dabei handelt es sich um ein kleines Board mit einer Atmel ATmega328 CPU. Außerdem sind 14 digitale ein und Ausgänge montiert. Daran kann man nun LEDs, Schalter und so weiter anschließen und programmieren. Das tolle an der Sache ist, dass der Atmel in einem Sockel steckt. Dass heißt ich kann den programmieren, herausnehmen und auf ein selbstgefertigtes Board stecken.

Mal schauen welche lustigen Geocache-Verstecke ich damit baue. :)

 

arduino 3_turnover

RetteDeineFreieit.de

15. September 2009 Keine Kommentare

Typo3 – Probleme mit combine (ImageMagick)

27. Juni 2009 3 Kommentare

Ich experimentiere zur Zeit mit Typo3 und bin bei der Installation auf ein Problem gestoßen. Beim Setup im Bereich “Image Processing” gibt es den Bereich “Combining images“. Der Test wurde bei mir nicht korrekt durchgeführt. Eine eingabe des von Typo3 durchgeführten Befehls ergab, dass der Befehl “combine” gar nicht auf meinem System verfügbar war. Die ImageMagick Version die apt-get mir installiert hat ist 6.2.4.

Anscheinend existiert der Befehl combine in der Version nicht mehr und wurde durch den Befehl composite ersetzt. Ich habe also erst eine Kopie der Date composite angelegt und diese combine genannt. Das hat allerdings fehlerhafte Bilder verursacht.

Dann habe ich in der Datei localconf.php folgende Zeile eingefügt:

"$TYPO3_CONF_VARS['GFX']['im_combine_filename']='composite'; // manually inserted"

Nun wusste Typo3 dass es anstatt combine, den Befehl composite benutzen muss und siehe da, es klappt:

Erfolgreiches Kombinieren mit composite

Erfolgreiches Kombinieren mit composite

PHP, MySQL und Charsets

26. März 2009 5 Kommentare

Heute habe ich mich ziemlich lange damit rumgeplagt, dass die Einträge bei einem einfachen Gästebuch nicht ordentlich ausgelesen/eingetragen wurden.

Die Website war zuvor in einem Mischmasch aus verschiedenen Charsets erstellt worden. Hauptsächlich ISO-8859-1. Ich habe gestern meinen Webserver neu installieren lassen und anschließend die Seite wieder aufgesetzt. Dann gabs da haufenweise schäbbige Zeichenfehler bei den Umlauten.

Ich habe dann die problematischen Seiten mit Notepad++ in das Format UTF-8 gewandelt und wieder hochgeladen. Dann hat sich zumindest schonmal der W3 Validator nicht mehr beschwert das im Header kein UTF-8 angegeben ist. Die Ganzen alten ISO Zeichen mussten erstmal ersetzt werden, sonst wollte der gar nicht anfangen zu parsen. Der Rest war dann fleißarbeit.

Problematisch wurde es dann bei der Datenbank. Die paar Einträge die ich aus dem alten SQL-Dump wieder rausgeholt habe, wurden halbwegs gut wieder importiert (Import Charset war Ascii). Die Sonderzeichen habe ich ersetzt und im PHPMyAdmin sah das ganze auch gut aus.

Auf der Webseite allerdings nicht. Dort gab es immer noch diese hässlichen Rauten mit Fragezeichen drin. Mit viel gegoogle habe ich dann letztendlich die Lösung gefunden. Das Problem stellte sich als wie folgt heraus. Die Webseite stand zwar auf UTF-8, lieferte aber an die Datenbank ISO Zeichen. Das habe ich daran erkannt, dass die Zeichen im PHPmyAdmin zwar unschön angezeigt wurden, auf der Webseite nachher aber wieder fehlerfrei ankamen. Letzteres ließ letztendlich auch den Schluss zu, dass die Buchstaben die aus der Datenbank kamen auch wieder in UTF-8 umgewandelt wurden.

Wenn man Umlaute per PHPmyAdmin in die Datenbank (auch mit UTF-8 Zeichensatz wohlgemerkt) schrieb waren die auf der Webseite wieder falsch.

Etwas anschaulicher:

Website (UTF-8): äää → Datenbank(UTF-8): ~~~

Datenbank : ~~~ → Website: äää

Datenbank: äää → Website: ~~~

Obwohl also sowohl die DB als auch die Seite UTF-8 verwenden, fand trotzdem immer noch eine Umwandlung statt. Eine Lösung fand ich durch folgende SQL Query:

SET NAME 'UTF8'

Der Befehl legt fest, welchen Datensatz der Client zum Senden an den Server verwendet. Fortan hatte ich also diesen Fall:

Website: äää → Datenbank: äää → Website: ~~~

Die Datenbank lieferte die Daten aus mir unersichtlichen Gründen wieder als ISO-8859-1. Das konnte man dann letztendlich mit einem einfachen PHP Befehl lösen:

utf8_encode($String)

Endlich lief es so wie ich wollte. Vielleicht hat ja noch wer das Problem und findet hier die Lösung oder hat einen Vorschlag für mich, wie ich’s besser lösen kann.