Jump to content
Sign in to follow this  
k00ni

Massives Zeichensatzproblem: Bei UTF-8 zerlegt er mir ö,ä und ü

Recommended Posts

Hallo,


wie kann ich dem begegnen? Ich hatte das Problem schon einmal und habe dann alle Dateien händisch angepasst und in das alte Format zurück gestellt (Name ist mir grad entfallen). Anbei, ich arbeite mit Eclipse 3.3.


Nun habe ich geänderte Dateien von jemanden bekommen und die liegen wieder im UTF-8-Format vor. Die Frage ist nun, wie man das Problem nun ein für alle mal löst. Ich denke, ich lass das Format so. Nur was mach ich mit allen Sonderzeichen im Code? Das Ö, Ü und Ä könnte man durch das HTML-Äquivalent ersetzen, nur wie siehts mit anderen aus?


Und was passiert mit Eintragungen in die Datenbank die sowas enthalten? Werden diese ebenfalls "versaut" oder bleiben diese unberührt?


Anbei, hier mal ein Beispiel:


benötigt?



Grüße

Share this post


Link to post
Share on other sites
Guest

Originaldateien erneut laden, in UTF-8 recoden (oder in Latin-9 öffnen), editieren, speichern (, eventuell zurückkodieren). Das nachträgliche Umkodieren von bereits umkodierten Dateien wird nicht funktionieren.

Share this post


Link to post
Share on other sites

Was meinst du genau mit recoden? Ich habe die Datei geöffnet und da diese Vierecke mit bspw. mit ö oder ä ersetzt, so wie es eigentlich sein sollte. Dann gespeichert. Nach dem Upload wird immer dann, wie oben geschrieben, sowas angezeigt:


benötigt?

Share this post


Link to post
Share on other sites
Guest

Dein Problem ist, dass Du inzwischen mehrere Zeichensätze miteinander vermischt hast - viele Editoren kommen damit klar, viele Browser aber nicht. Die sauberste Alternative ist, nun die Originaldatei zu nehmen, diese zu einem Zeichensatz deiner Wahl zu rekodieren (UTF-8!) und diese nach Beendigung deiner Arbeit entweder in UTF-8 zu lassen oder zu einer Kodierung deiner Wahl zu rekodieren.


Beispiel:

Die Quelltext-Dateien von Powie sind nahezu alle Latin-9 kodiert. Öffnet man so eine Datei im UTF-8-Modus, werden bestimmte Zeichenbereiche nicht korrekt rekodiert - es entstehen dann Fehler wie der von dir beschriebene (bei mehr-bytigen Zeichen - deswegen kommen bei dir auch zwei Zeichen raus - das erste Byte kodiert ein Ã, das zweite Byte ein ¶ - zusammen aber ein anderes Zeichen). Bevor ich ein Powie-Skript in mein SVN-Repository einchecke, rekodiere ich alle Nicht-binär-Dateien nach UTF-8. Publiziere ich dann einen File für irgendjemanden, rekodiere ich diesen wieder zurück zu Latin-9 (Powies Software läuft intern bei mir auch UTF-8-kodiert, auch die Daten in der Datenbank - es gibt z.B. einen UTF-8-fähigen Fork des Forums).

Öffne ich nun so eine UTF-8-rekodierte Datei im UTF-8-Modus meines Editors sind Multi-Byte-Zeichen geschützt.


recode ist ein Kommandozeilenprogramm, mit dem man die Kodierung von Dateien ändern kann:

http://www.gnu.org/software/recode/

Share this post


Link to post
Share on other sites

Das ist zum Kotzen. Eclipse unterstützt hier nur UTF-Formate (UTF-8, UTF-16, UTF-16BE, UTF-16LE,... und ISO-8859-1). Wie kann es sein, dass er dies plötzlich nicht mehr darstellen kann? Kann das an dem Up- und Download von verschiedenen FTPs liegen? (Verwendung bzw. nicht Unterstützung anderer Datei-En- und -Codierungen?) Verstehe gerade noch nicht so recht, wie es hier wieder zu sowas kommen kann. (Das Problem hatten wir schonmal...)


Ich möchte eigentlich nicht noch händisch immer die Dateien hin- und hercodieren, nur weils das Programm nicht hinbekommt. Wenn ich mich recht erinnere hatte ich früher einen Typ der nannte sich Cp-15... oder so ähnlich.

Share this post


Link to post
Share on other sites
Guest
Das ist zum Kotzen. Eclipse unterstützt hier nur UTF-Formate (UTF-8, UTF-16, UTF-16BE, UTF-16LE,... und ISO-8859-1).

Damit bist Du ja für die Zukunft gut gerüstet.


(Verwendung bzw. nicht Unterstützung anderer Datei-En- und -Codierungen?)

Kodierungen sind FTP üblicherweise egal. Da geht es eher darum, ob ASCII oder Binär übertragen wird. Die meisten FTP-Clients erkennen das aber selbstständig.


Wenn ich mich recht erinnere hatte ich früher einen Typ der nannte sich Cp-15... oder so ähnlich.

Codepage 1252 enthält Latin-1 (ISO-8859-1).


Problematisch wird es eben nur, wenn man die Kodierungen mischt. Hättest Du die Dateien konsequent als Latin-1 geöffnet und gespeichert, hättest Du nun kein Problem.

Share this post


Link to post
Share on other sites

Ich habe das Problem immer noch. Zur Zeit arbeite ich zur Abwechslung unter Linux (openSUSE). Habe dort sowohl mal Eclipse als auch gVim angetestet. Er zeigt mir den Kauderwelch immer noch an.


Filezilla ist so eingestellt, dass es automatisch den Zeichensatz setzt, je nachdem was der Server unterstützt.


Mit gVim habe ich eine Datei erstellt und hochgeladen. Dort wurden ebenfalls die Zeichen falsch dargestellt.


Ich habe kein Problem damit, die Files alle neu zu erstellen, nur würde ich dies gern mal in den Griff bekommen. Kann mir jemand einen guten Editor unter Linux empfehlen? Habe bisher nur mit Eclipse (PHPEclipse) sowie PHPEdit gearbeitet.


Würde es denn "reichen", wenn ich meinem Filezilla sage, dass er nur "Latin-1" verwenden soll?

Share this post


Link to post
Share on other sites
Guest
Ich habe kein Problem damit, die Files alle neu zu erstellen, nur würde ich dies gern mal in den Griff bekommen. Kann mir jemand einen guten Editor unter Linux empfehlen? Habe bisher nur mit Eclipse (PHPEclipse) sowie PHPEdit gearbeitet.

Im KDE-Paket gibt es kate und KDevelop. Aber nochmal: Du hast kein Problem mit Eclipse, sondern mit gemischten Kodierungen.


Würde es denn "reichen", wenn ich meinem Filezilla sage, dass er nur "Latin-1" verwenden soll?

Du solltest die verwendete Kodierung einstellen. Vorzugsweise UTF-8.

Share this post


Link to post
Share on other sites
Du hast kein Problem mit Eclipse, sondern mit gemischten Kodierungen.


Ich verstehe nur nicht, was ich falsch mache. Ich habe ja mit gVim eine einfache Datei erstellt und diese auch getestet. Dort trat das Problem auch auf. Als ich noch unter Windows gearbeitet hatte, lies ich die Dateien als ANSI speichern (bei PHPEdit) und er brachte keine Probleme.


Wo liegt nun mein Fehler? Muss ich im Editor was einstellen? Oder im Betriebssystem? Ich hab keinen Plan, was hier schief läuft. :-/



Grüße

Share this post


Link to post
Share on other sites
Guest
Ich verstehe nur nicht, was ich falsch mache. Ich habe ja mit gVim eine einfache Datei erstellt und diese auch getestet. Dort trat das Problem auch auf. Als ich noch unter Windows gearbeitet hatte, lies ich die Dateien als ANSI speichern (bei PHPEdit) und er brachte keine Probleme.

Das ist genau was ich meine: Du hast irgendwann mal dazwischen eine UTF-8-Datei als ANSI/ASCII-Datei geöffnet. Der Editor hat dann aus den beiden UTF-8-Bytes je ein Zeichen gemacht.

Share this post


Link to post
Share on other sites

So, irgendwas läuft hier richtig falsch. Ich habe nun unter Ubuntu Linux EasyEclipse am laufen. Habe eine neue Datei erstellt und dort folgendes reingeschrieben:

 




Der Zeichensatz ist laut "Text file encoding" (PHP-Datei ausgewählt => Eigenschaften) bei UTF-8 (Default: inherited from container: UTF-8).



Dann hab ichs mit Filezilla 3.0.0 hochgeladen. Dort ist auch auf UTF-8 gestellt. (Unter Servermanager => Server ausgewählt => Zeichensatz auf "Automatisch". Das bedeutet, dass er automatisch UTF-8 nimmt, wenn vorhanden.)



Eigentlich müsste es ja gehen. Nur es kommt wieder


äöü;

 

im Firefox 2.0.0.12.


:gaga: :gaga: :gaga:


[edit]Setze ich den Zeichensatz im Eclipse wieder auf "ISO-8859-1" und schreibe das Gleiche nochmal hin, lade es hoch und betrachte es im Browser, dann läuft es sauber. Es werden die Sonderzeichen alle angezeigt. Kennt UTF-8 überhaupt ÄÖÜ etc?![/edit]

Share this post


Link to post
Share on other sites

Wie ich gerade in der Wikipedia lese ist bei eingestelltem ISO-8859-1-Encoding das ä ein ä. (Zu finden weit unten)


Kann es also auch am Browser liegen? Oder vielleicht gar am pSys, da dort ein anderer Zeichensatz eingetragen wurde?





Ich hab den Übertäter. Ich kann mich irren, aber ich denke, die [pSys-Hauptordner]/tpl/header.tpl zerlegt mir mein UTF-8.

 

{ * INIT pSys Header * }






{if $addmeta != '' }
	{$addmeta}
{/if}
{if $page_reload != '' }

{/if}
{if $page_forward != '' }

{/if}
{if $page_keywords != '' }

{/if}
{if $pagetitle != '' }
	{$pagetitle}
{else}
	{$pset.systitle}
{/if}
{php}
	global $pdir_style;
	if ( file_exists($pdir_style."/headtag.inc.php") ) {
		include_once($pdir_style."/headtag.inc.php");
	}
{/php}
{if $page_ajax != '' }
	{$page_ajax}
{/if}


 

Ich kann also machen, was ich will, es wird immer nach ISO-8859-1 konvertiert, weshalb diese komischen Zeichen herauskommen. Würde es reichen diese Stelle

 


 

zu einfach zu entfernen oder ggf. anzupassen, damit das Problem behoben wird?





Ich würde das Problem gern schnell lösen, da ich sonst alle meine Dateien im Friends neu konvertieren muss, was ne scheiss Arbeit ist. Am liebsten wäre mir UTF-8, wenn das die Zukunft ist. Weiterhin ist bereits jede Datei im UTF-8 Format, was Eclipse automatisch beim Anlegen macht.

Share this post


Link to post
Share on other sites
Guest

Wichtig ist (erstmal) nicht, was in den Dateien steht, sondern was der Server als Encoding liefert. Es reicht bei XML-artigen Daten ausdrücklich nicht, die Angabe in der Datei an sich anzugeben - weswegen PSys auch in dieser Hinsicht broken ist.


Powie Skripte sind allerdings alle als Latin-9 kodiert. Du kannst natürlich trotzdem mit UTF-8 arbeiten, aber Du musst die Daten dann jeweils vor dem Roll-Out in Latin-9 rekodieren.

Share this post


Link to post
Share on other sites
Guest

X(HT)ML wird immer als grundsätzlich als UTF-8 angesehen, wenn es keinen entsprechenden HTTP-Header gibt, der bereits vor dem Dokument geschickt wird (-> http-equiv funktioniert also nicht). Dementsprechend sollte konsequent UTF-8 verwendet werden.

Share this post


Link to post
Share on other sites
Guest

Hab ich doch geschrieben: Konsequent UTF-8. Dabei ist es egal, was in einem File deklariert wird, da, um zu sehen was in einem File steht, die Kodierung doch schon bekannt sein muss.


Zum besseren Verständnis:

Schicke ich einen XML-File ohne expliziten Content-Encoding-Header, wird dieses immer als UTF-8 angesehen und dann auch so kodiert. Stößt der Parser dann auf eine Angabe, dass ein Dokument z.B. als Latin-9 kodiert ist, ist es schon zu spät. Hier hilft keine implizite Kodierung mehr.


Deswegen:

* Komplettes PSys auf UTF-8 umstellen,

* Datenbankdaten auf UTF-8 umstellen,

* Klarstellen, dass auch der HTTPD Seiten als UTF-8 ausliefern muss


Hier existiert hier eh noch ein ordentliches Problempotenzial, da praktisch alle Operationen im PSys davon ausgehen, dass nur Latin-9 verarbeitet wird, jedoch wird dies nirgends explizit sichergestellt. Dementsprechend kann man das PSys mit eher ungewöhnlichen Zeichensätzen ordentlich aus dem Tritt bringen, bspw. mit UTF-7 oder UCS.

Share this post


Link to post
Share on other sites

Die Datenbank auf UTF-8 anzulegen ist klar, eine existierende umzustellen ist Fleissarbeit :)


was muss man bei diesen beiden Punkten noch beachten:


* Komplettes PSys auf UTF-8 umstellen,

* Klarstellen, dass auch der HTTPD Seiten als UTF-8 ausliefern mus

Share this post


Link to post
Share on other sites
Komplettes PSys auf UTF-8 umstellen


Ich denke, dass du hier noch jede Datei als UTF-8 speichern musst sowie alle Zeichen die dann falsch dargestellt werden noch abänderst. Oder du konvertierst direkt ins UTF-8, was Statler etwas weiter vorne im Thread geschrieben hatte.



Anbei, danke dass du dir wegen mir so ne Arbeit machst. :-D:-o

Share this post


Link to post
Share on other sites
Anbei, danke dass du dir wegen mir so ne Arbeit machst.


lol..... ich denke da bist du wohl nicht der einzigste ..... ich denke das wird ehr "alle" betreffen [:o]

Share this post


Link to post
Share on other sites
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...