Utf..

Ich brauche mal etwas technischen Rat..
Im Zuge von möglicher Internationalisierung und das für mich so aussieht, als würde alles irgendwie zu UTF werden überlege ich, ob man nicht auch mitziehen sollte.. Mysql arbeitet bereits (kann) mit UTF (UTF-8 ), die Ausgaben (z.b. XML-Feeds) auch.. also?
1. Frage: Was spricht im Groben gegen eine Umstellung, was im Groben für eine Umstellung?
2. Frage: Daraus folgt: Was muss ich umstellen, was sollte ich nicht umstellen?
Zu 2: Datenbanktabellen, (PHP-)Scripts (zB kann ich jetzt, ich nehme meine persönliche IDE zu Rate, die Datei als Unicode-UTF8 speichern), Templates, CSS, JS, ... zumindestens letzteres weiß ich aber auswendig gar nicht, wo man das dem Client mitteilen kann (bei CSS geht das ja).
Frage 2 zielt so darauf hinaus, das die Frage ist, ob man nur die Ausgaben UTF formatiert, oder aber auch intern damit arbeitet (und damit die Ausgabe implizit mit setzt).
Das schließt natürlich ein, dass man bereits auf einer XHTML.XML-Basis arbeitet. Das setze ich als Basis jetzt voraus, um irgendwelche Problemen aus dem Weg zu gehen.
[Mein Slash reagiert nicht, deshalb ein paar Fehler.. -.-]

soo
Gegen umstellugn auf UTF-8 spricht eingtlich nur die faulheit der Programmierer
Man muss beachten das man die orndeltichen Charsets in die HTml File schreibt per und evtl auch im Header mitsenden
eine umstellugn sollte so gut wie garnicht schwierig sein nur umlaute die als plaintext geschrieben wurnde sollten probleme bereiten

Also programmiertechnisch ändert sich erstmal rein gar nichts, außer Du parst irgendwo Text byteweise, dann mußt Du das natürlich ändern und wirklich zeichenweise (statt byteweise) einlesen.
Für eine Umstellung spricht IMHO gar nichts, sofern Du nur ISO-8859-1(5) Zeichen verwendest. Möchtest Du irgendwelche anderen Zeichen verwenden (Kyrillisch, Griechisch, whatever), kommst Du an einer Unicode-Codierung wohl kaum vorbei.
Wenn Du die Codierung Deiner Files (js, css...) änderst, dann mußt Du auch dafür sorgen, daß der Webserver die Codierung im HTTP Header sowie Du selber die angegebene Codierung im HTML bzw. XML Header richtig angibst.

Naja, sowohl CSS: charset, als auch HTML Chartset sind geschenkt.. das sollte man schon wissen. Und eigentlich.. schon heute mit dem entsprechenden ISO gesetzt haben.
Würdest du also alles in UTF speichern? Also, Format als UTF-8, entsprechende Header setzen und "fertig"?
Oder gibt es irgendwelche Problemfälle? Mir sind keine bekannt, eben deshalb frage ich mal nach Praxiserfahrungen
Wenn ich mich jetzt nicht stark irre, entfallen dann auch die meisten HTMLEntities, oder würfele ich jetzt etwas durcheinander?

Mir persönlich sind keine Schwierigkeiten aufgefallen.
Vielleicht mir irgendwelchen exotischen oder Retro-Browsern?
(Hatte gestern tatsächlich nen Besucher auf meiner Homepage mit Netscape 4.0)

Wenn ich mich jetzt nicht stark irre, entfallen dann auch die meisten HTMLEntities, oder würfele ich jetzt etwas durcheinander?

Ja, wobei solche Sachen wie spitze Klammern etc. natürlich immer noch kodiert werden müssen. Aber halt alles, was nicht in Latin-1 enthalten ist, kannst Du dann einfach durch das entsprechende UTF-8 Zeichen kodieren.

Oder gibt es irgendwelche Problemfälle? Mir sind keine bekannt, eben deshalb frage ich mal nach Praxiserfahrungen

Mein Browser auf dem Handy (Nokia 6670) mag z.B. kein UTF-8. Ich glaube der IE 5 hat damit auch noch so seine Probleme (nicht sicher). Die gängigsten Browser in den aktuellen Versionen jedoch verarbeiten es ohne Probleme.

Joa, alle XHTML "besonderen" Zeichen wie <, >, & müssen dennoch kodiert werden.. auch in einer URL (was die meisten ja scheinbar noch immer nich wissen^^).
IE5 wäre für glaube ich kein Grund, genauso wie NN4
Wegen Handy.. ist das ein Regelfall oder können die neueren Modelle UTF?

Der Opera Mobile kanns, andere kann ich net beurteilen.
Also kann man htmlentities() durch htmlspecialchars() ersetzen.

Wenn man die PHP-Sourcen in UTF8 haben will (um vollständig mit UTF8 zu arbeiten), gibt es ein Problem:
Sobald die PHP-Dateien am Anfang ein BOM haben (3 Bytes, damit werden utf-8-Dateien) markiert, werden diese mit an den Browser ausgegeben. Die Ausgabe von Headern wird damit erschwert und per PHP generierte Bilder werden kaputt gehen.
Man kann in PHP zwar mit enable-zend-multibyte die Ausgabe der BOMs verhindern, dies kann aber nicht über die php.ini gesetzt werden, sondern nur als compile-flag. Zumindest auf meinem lokalen Windows-Test-Server hilft mir das also nicht weiter.
Bleibt also nur:
- PHP überall mit enable-zend-multibyte zu kompilieren
- Editoren und Entwicklungstools verwenden, die kein BOM schreiben und auch ohne BOM einwandfrei funktionieren
- intern auf utf-8 verzichten (so mache ich es jetzt erstmal weiterhin)

Okay, wie kann ich testen, ob mein Tool das kann?
Derzeit wird ausschließlich Eclipse (PHPEclipse) genutzt, aber ausser der umfangreichen Liste der unterstützen Charsets habe ich da noch nichts über dieses spezielle Merkmal gelesen..

Kleine Zwischenfrage: Wieso ist es notwendig, dass MySQL das kann? Ist es nicht sinnvoll für eine Internationalisierung alle Texte aus der Datenbank in Files zu schreiben und diese dann mittels einer ID oder Sonstigem einzulesen?
Gruß
Moo

Naja, in der DB werden ja nicht nur Übersetzungen der Seiten gespeichert (wobei man sich da über Sinn oder Unsinn streiten kann, ich hab keine Lust dazu ), sondern auch Mails, Foren etc. Und die sollten auch mitsamt den Sonderzeichen gespeichert werden, sofern man die nicht gleich html-codiert abspeichert.

Übersetzungsdaten in Files auslagern?
Also wenn DBMS dann wirklich DBMS und nicht "Indexhaltung im DBMS um darauf auf Files zuzugreifen".

Ein wenig Offtopic:
Ich habe eigentlich nur Zahlen in der Datenbank, bzw. rüste gerade in diese Richtung um. In einem Languagefile habe ich dann einfach ein paar Arrays und ziehe dann die Namen, Info's zu Items, Gebäuden etc. einfach über eine ID aus dem Array.
So sollten doch auch die Abfragen schneller gehen? Wenn man nurnoch Ints oder floats abfragt?
Gruß
Moo

Hmm,
begeistert bin ich nicht von der Vorstellung, dass der immer die komplette Datei nach der ID durchsuchen muss, dass ist eher viel langsamer als eine DB, schon weil die unique Indexe hat und bessere Cachemöglichkeiten hat...
die DB konkurriert da eher mit shared memory lösungen, wo du das komplette Array mit den Übersetzungen so in den Speicher jagst, dass es von allen Instanzen vom Apache aus gelesen wird, was auch die Opcode-Cacher machen.
Infos: www.php.net/manual/de/ref.sem.php
Mit Semaphoren wirst du dich wohl nicht herumschlagen müssen, weil du es ja nur 1x reinschreibst und es dann immer nur liest.

Nein, definitiv nicht. Bei einem Popelarray mit 10 Elementen vielleicht noch, aber wenn Du im PHP immer ein File laden mußt um sagen wir mal ein Array mit 1000 Elementen zu laden ist die Datenbank viel performanter.
Wie auch immer, IDs aus der DB lesen um damit in Files zu suchen bringt das Christkind zum weinen
Edit: Mit dem SHM wirds evtl. ein winzig klein wenig performanter. Aber sicher nicht um soviel, als daß ich wegen so einer Lapalie wirklich mit SHM anfangen möchte. Bei den Karten-Imagemaps bin ich ein großer Verfechter von SHM und SEM, aber hier absolut nicht.

Datenbanken sind einfach geil
Ich habe noch nie verstanden, wieso sich Leute freiwillig mit Textdateien rumplagen wollen - das erlebe ich noch heute, wenn wir eine PHP-Homepage abgeben müssen und die Leute, anstatt eine einfache DB, lieber simples Dateischreiben bevorzugen.. das Leben kann so einfach sein.
Wie erwähnt, befinden sich in einer Datenbank selten nur Zahlen; es kommt natürlich auch immer auf die Anwendung an. Sowohl Browsergame zu Browsergame, als auch zu komplett anderen Anwendungen unterscheiden sich da.
Selbst eine so performante, effiziente Anwendung wie eBay, die mit Sicherheit viel mit IDs arbeitet (weil eben schnell), kommt um enorme "String-Speicher" nicht drumherum.. und gerade hier ist es wichtig, wg Internationalem Geschäft auf einen großen Standard zu setzen.. deshalb wette ich einfach mal, dass eBay UTF verwendet.

Und wenn ich einfach für die verschiedenen Seite für jeweils ein oder mehrere Arrays erstelle, also Array-error, Array-texte etc.. aber alle Arrays in einem File stehen?
Gruß
Moo

Bitte vergiß Deine Arrays mit Deinen Files. Wieso liest Du das Zeug nicht mit einem SQL Query aus der DB raus sondern holst zuerst irgendwelche IDs aus der Datenbank um darauf auf irgendein Array zuzugreifen, was erstens Perfomance (die Datei muß erstmal eingelesen werden) und zweitens Speicher (für das Array) frißt?

wenn ich eine
language_file.php
habe und dann Arrays mit ca. 10 Elementen pro Array? Und auf einer Seite greife ich auf max. 2 Arrays zu.
Ist das echt so langsam?
Gruß
Moo

Nein, es ist sicher nicht viel langsamer...
Ok, ich hab alles versucht, bleib bei Deinen Files, ich geh mal mein DBMS trösten, das weint ganz bitterlich wegen Dir, das hast Du nun davon.

Gut, dann tröste es
Also wäre das ein besserer Lösungsansatz:
Datenbanktabelle:
site_id|array
und dann frage ich das Array aus der Datenbank ab?
Gruß
Moo

Gah, warum alles so verkomplizieren? Ich geh jetzt mal nicht auf Deinen Vorschlag ein, sondern Frage zurück, was gegen so eine Struktur spricht:
Tabelle "einheiten"
id|staerke|kosten
1|1|5
2|3|20
...
Tabelle "einheiten_namen"
id|de|en|fr
1|Soldat|soldier|soldat
2|Kavallerie|cavalry|chevalier
...
PHP Code
$lang = 'de';
...
mysql_query( $db, "SELECT einheiten.*, einheiten_namen.{$lang} AS name FROM einheiten INNER JOIN einheiten_namen ON einheiten.id=einheiten_namen.id" );

So eine Struktur habe ich mir auch am Anfang überlegt. Nun aber mal weitergefragt, was machst du mit dem Text der auf der Seite generiert wird, sowas wie: "Truppen kommen an..." etc. wo speicherst den?
Gruß
Moo

Das steht bei mir im Template.
Denn das wird entweder nach /tmpl/de/xx.tpl oder nach /tmpl/en/xx.tpl oder ....
Und die kann man auch extern übersetzen lassen .. Ist vielleicht etwas mehr arbeit, statt einzelne strings in einer liste zu sehen - aber so merkt man wenigstens den Kontext ...

Bin mittlerweile auch zu dem Schluss gekommen, das alles was ihr da gesagt habt, schlussendlich Käse ist
Angenommen, man normiert sich intern auf Englisch.. dann steht im Template nur noch "Soldier".. und das Language Plugin sucht sich dann raus, ob die gewählte Sprache dafür eine Übersetzung parat hat (i18n/gettext).
Da hat man weder in der DB redudante Daten (andere Sprache, GLEICHER Begriff), noch redudante Templates (bearbeiten? ieehh
)