Encoding / SciTE / Subversion

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
boostpy2005
User
Beiträge: 31
Registriert: Freitag 31. März 2006, 14:15

Hallo zusammen!

die Situation ist wie folgt:
Wenn ich ein Script als cgi verwenden, muss ich #!C:\......\python.exe als ersten eintragen, unter *nix auch ähnliches.

wenn ich Coding eintragen will, gibt es # -*- coding: UTF-8 -*- auch kein Problem von Python, wenn dies als zweite Zeile angegeben wurde!

Problem:
1. SciTE versteht Umlauten nicht mehr, wenn die Coding nicht als erste Zeile eintragen wurde!
2. als CGI gibt es Fehler, wenn #!..... nicht mehr als die erste Zeile auftauscht!
3. Subversion-Diff versteht auch nicht mehr Umlauten, wenn die Coding nicht als die erste Zeile auftaucht

Bitte um Lösung oder Hinweis!
Benutzeravatar
Masaru
User
Beiträge: 425
Registriert: Mittwoch 4. August 2004, 22:17

Eher ein Hinweis, du könntest ja mal folgendes testen:

1. SciTE versteht Sonderzeichen in "UTF-8" abgespeicherten Dateien, sofern diese auch als "UTF-8" encoded abgespeichert werden. Hierfür wählt man vor dem speichern in SciTE über das Menu File -> Encoding -> UTF-8.

2. Nun kannst du das Encoding-Element in deinen Scripten weglassen und dank #!... in der ersten Zeile, klappt es ja auch wieder mit dem CGIchen.
Ist es nun schlimm, dass die Encoding-Zeile fehlt? Tja ... eigentlich nicht. Intern codiert meines Wissens nach Python eh in UTF-8, so dass in diesem Falle es nichts ausmacht, und die Funktion des CGIs vorgeht.

3. Subversion vergleicht Dateiinhalte nicht unter einem speziellen Encoding, nur weil in der ersten/zweiten Zeile etwas in einer rein für Python typischen Syntax steht.

Was viel mehr durch das Auslassen der Encoding Zeile (an erster Stelle) passiert, ist folgendes:
  • - SciTE kann bei Python-Scripten (SciTE supportet ja die Python-Language) automatisch ein Encoding für die Dateispeicherung einrichten, wenn in der ersten Zeile die "# -*- coding: bla" Angabe steht. Ist dies nicht der Fall, codiert SciTE die Datei (hat nix mit der internen Verarbeitungsformatierung von Python zu tun) in 8-Bit (SciTE Encoding Standard ... wie schonmal erwähnt über "File -> Encoding" zu finden).
    - speichert man eine Python-Datei nun ohne die Encoding-Zeile, so wird sie auch nichtmehr in UTF-8 gespeichert, was wiederrum dazu führt, das SubVersion bei Umlauten, Sonderzeichen, pp natürlich eine Veränderung zu vorherigen in UTF-8 gesicherten Revisionsscourcen anzeigt.
Aber wie gesagt, dass hat nichts mit SubVersion und der ersten Encoding-Zeile, sondern nur mit der Art der Dateispeicherung zu tun.

(Fast) jeder gute Editor kann heutzutage die verschiedensten Codepages anbieten, um den geschriebenen Inhalt entsprechend zu sichern.

Gruß,
>>Masaru<<
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Masaru hat geschrieben:2. Nun kannst du das Encoding-Element in deinen Scripten weglassen und dank #!... in der ersten Zeile, klappt es ja auch wieder mit dem CGIchen.
Ist es nun schlimm, dass die Encoding-Zeile fehlt? Tja ... eigentlich nicht. Intern codiert meines Wissens nach Python eh in UTF-8, so dass in diesem Falle es nichts ausmacht, und die Funktion des CGIs vorgeht.
Hi Masaru!

Für diese Aussage sollte man dich mit Gummibärchen bewerfen, bis es weh tut. :twisted:

Die Angabe des Codings ist WICHTIG. Python kann ohne die Angabe des Codings nicht viel mit Umlauten anfangen. Auch wenn **teilweise** alles zu funktionieren scheint.

Hier etwas Lesestoff zu diesem Thema:
http://www.python-forum.de/topic-5095.html

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

PS: an boostpy2005:

Gib das Coding an und speichere das Mudul auch wirklich in dem angegebenen Coding ab. Weitere Informationen darüber findest du über den Link des vorherigen Beitrags. Der Editor WingIDE speichert das Modul automatisch im angegebenen Coding -- das spart Neven. Scite macht das nicht automatisch.

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

SciTE nutzt eigentlich auch die coding cookie Zeile:
UTF-8 files will also be recognised when they contain a coding cookie on one of the first two lines. A coding cookie looks similar to "coding: utf-8" ("coding" followed by ':' or '=', optional whitespace, optional quote, "utf-8") and is normally contained in a comment:
# -*- coding: utf-8 -*-
For XML there is a declaration:
<?xml version='1.0' encoding='utf-8'?>

For other encodings set the code.page and character.set properties.
http://scintilla.sourceforge.net/SciTEDoc.html

Jedoch muß ich zugeben, das es bei mir anscheinend auch hin und wieder nicht klappt :( Denn es kommt oft vor, das die Umlaute plötzlich nicht mehr richtig dargestellt werden, obwohl ich immer UTF-8 nutzte... Keine Ahnung woher das kommt.
Deswegen versuche ich es zu vermeiden, Umlaute/Sonderzeichen zu benutzten (außer in Kommentare).

IMHO sollte SciTE irgendwo das benutzte Encoding anzeigen.


EDIT: Noch ein Tipp: Wenn das Encondig in der Datei falsch ist, man aber die Umlaute richtig sieht, kann man nicht einfach unter File / Encondig auf UTF-8 Cookie umschalten! Denn dabei gehen die Umlaute kaputt.
Mit einem Trick geht es aber doch:
Mit Strg-A, Strg-C den gesammten Text in die Zwischenablage, dann umschalten und mit Strg-V wieder einfügen und speichern. Dann sind die Umlaute richtig in UTF-8 gespeichert...

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Antworten