Archiv 16. Juli 2012

Montag, 16. Juli 2012

Das Kerning der Prozentzahl auf dem iPhone 4S stimmt nicht

Bin ich der einzige Mensch auf der Welt, welchen das Kerning der Prozentanzeige auf dem iPhone 4S (iOS 5.1) stört? Der horizontale Abstand zwischen den zwei Ziffern ist viel zu gross, wenn bspw. 50% oder 84% steht:

image-5151

Nachtrag: Nein, das Thema scheint bekannt zu sein:

A while ago I noticed, that on iPhone 4 sometimes the battery percentage figures looked odd. They are unevenly spaced and seem to jump off the baseline of the font. I tried to narrow it down and found out that this only occurrs on the 4, not a 3GS running the same iOS. The main font-related difference between the two devices – as far as I know – is, that the 4 uses Helvetica Neue, rather than simple Helvetica. Other than that, the increased resolution of the 4 versus the 3GS could also make a difference.

Quelle: Battery Percentage Numbers look odd on iPhone 4 and 4S

Tags: , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. Juli 2012

PHPs serialize und unserialize-Funktion mit Unicode-Problemen

Ich habe es mir angewöhnt, regelmässig in das PHP-Error-Log auf meinem privaten Web-Server zu schauen, in welches mit E_ALL jede erdenkliche Art von Fehlern aufgezeichnet werden.

Und kürzlich häuften sich durch einen Spider verursachte Fehler in der Form:

...
PHP Notice:  unserialize(): Error at offset 1573 of 20531 bytes in /var/www/sites/domain.ch/administration/inkludierung/file.php on line 1816
...

Heute hatte ich Zeit, dem Problem auf den Grund zu gehen. Die erste Aufgabe bestand einmal daraus, den serialisierten String vor der Speicherung in die Datenbank mit dem serialisierten String nach dem Extrakt aus der Datenbank zu vergleichen. Hierzu schrieb ich die beiden Zeichenketten in Dateien im Web-Root. Wie sich mit einem Blick erkennen liess, war der serialisierte String nach dem Zurücklesen aus der Datenbank um 30 Bytes grösser.

Was war die Ursache? Natürlich vermutete ich auf Anhieb Probleme mit dem Zeichensatz und Sonderzeichen, von welchen es in der deutschen Sprache halt ziemlich viele gibt (jedenfalls aus der Optik von 127 ASCII-Zeichen). Da PHP Offsets in Bytes (und nicht Zeichen) angibt, war es hilflos, den String in einem Texteditor wie TextMate anzuschauen. Stattdessen rief ich 0xED auf, und musste danach „offset 1573“ in Hex umrechnen — mit dem erstbesten Tool, welches ich im Web fand: Hexadecimal Conversion. Der Blick auf den Array-Wert bestätigte meine Befürchtung: Es handelte sich um eine Zeichenkette, welche deutsche Umlaute enthielt.

NB: Der Offset lag aber ca. 10 Zeichen hinter dem Auftreten der Sonderzeichen, aber immer noch innerhalb des Strings, welcher die Sonderzeichen enthielt.

Nach etwas Googlen realisierte ich, dass PHPs serialize() und unserialize() nicht den besten Ruf besitzen und äusserst fehleranfällig sind — besonders, wenn es um Multibyte-Strings geht. Nachdem ich kurzfristig auf json_encode() und json_decode() wechseln wollte, das Vorhaben aber abbrechen musste, weil ich mein Mega-Array mangels nicht fortlaufender Keys teilweise in Objekte umgewandelt zurückerhielt, stiess ich auf folgenden Blog-Post:

PHP Serialize() & Unserialize() Issues

Seit ich die serialisierten Zeichenketten noch durch Base64-En- resp. Dekodierung durchlaufen lasse, bleibt mein PHP-Error-Log leer:

...
$toDb = base64_encode(serialize($sitemap));
...
$sitemap = unserialize(base64_decode($fromDb));

Einziger Nachteil: Durch Base64-Encodierung setzt der String 7 Kilobytes an Länge an. Aber mir soll’s Recht sein.

Tags: , ,
Labels: Programmierung

4 Kommentare | neuen Kommentar verfassen