Umlautproblem

[GrandMarnier]

Moin,

also wenn ich das richtig verstehe ist es doch egal, ob nun z.B. Öl oder Oel geschrieben wird, oder ?

Der Fehler lag bei der Kodierung(?) der Mails und nicht bei den Umlauten an sich ?
(von Kodierung und solchen technischen Dingen habe ich keine Ahnung, aber bei mir scheint es
dann ja OK zu sein)

Gibt es denn nun noch eine Neuauswertung ? Oder wie geht es weiter ?

Gruß

Michael

Die Codierung war bei mir wie immer. So wie ich es verstanden habe, konnte diese Codierung vom Server aber wohl nicht mehr gelesen werden.

Neuauswertung hin oder her, ich denke ein Verschieben des ZAT wäre nun notwendig. Und wenn er eh verschoben wird, dann kann es auch eine Neuauswertung geben

Ich habe mit meinen Befehlen noch nicht angefangen, denn solange nicht klar ist, auf welcher Basis die neuen Befehle gemacht werden können, müsste ich ggf. eh ganz neu anfangen und würde es bis Sonntag nicht mehr auf die Reihe kriegen.
Auf der anderen Seite, wenn es keine Neuauswertung gibt, dann hilft mir das auch nichts, weil ich auch dann jetzt erst mit den Befehlen anfangen könnte und ich zusätzlich die gescheiterten Übergaben und Transporte und was weiß ich noch wieder gerade biegen muss. Das schaffe ich erst recht nicht mehr bis Sonntag :-/

[Hamilcar]

Moin,

ich habe mich entschieden, daß es eine Neuauswertung gibt. Am Sonntag, den 02.05.2015 wird die letzte Runde vom 25.04.2015 neu ausgewertet.

Gruß,

Hamilcar

[GrandMarnier]

Moin,

ich habe mich entschieden, daß es eine Neuauswertung gibt. Am Sonntag, den 02.05.2015 wird die letzte Runde vom 25.04.2015 neu ausgewertet.

Gruß,

Hamilcar

Vielen Dank

[Thalian]

Hallo GrandMarnier,

ist Dein neuer Report nun in Ordnung?

[GrandMarnier]

Hallo GrandMarnier,

ist Dein neuer Report nun in Ordnung?

Leider nicht.
Es wurden auf jeden Fall die persistenten Kommentare "//" verändert, in denen die Vorlagebefehle stehen. Mein erster Eindruck ist, dass dort Zahlen als Codierungen interpretiert wurden. So wurde z.B. aus 40 ein @ Zeichen (Hex 40 = @ ?), usw.
Tatsächlich sollten die "//" Kommentare aber eigentlich nicht verändert oder interpretiert sondern nur "durchgeschleust" werden. Veränderte und damit nicht mehr korrekte Vorlagebefehle sind bei meiner Partei der GAU.

Ich hab mal ein paar Beispiele per Mail versandt. Ich hab an der Mail auch noch mal die Originabefehle drangehängt. Einmal als Text Attachement und dann auch noch mal gezippt. Außerdem zur Sicherheit als UTF-8 versandt

[Enno]

Umlaute und Mailverarbeitung sind ein kompliziertes Thema, da habe ich auch in Eressea lange mit gekämpft. Mein Code arbeitet intern mit UTF-8, und da Fantasya in Java geschrieben ist, nehme ich mal an, dass dort intern mit den Unicode-Strings der Sprache gearbeitet wird, Umlaute also kein Problem sind, solange die Eingaben in einem bekannten Encoding sind (z.B. UTF-8).

Meine Mailverarbeitung macht das so, dass sie jede eingehende Mail als MIME-Message interpretiert (Python hat dafür sehr gute Module), und dann jeden MIME-Part untersucht, ob er Text enthält. Wenn ja, dann wird der Text über die eingebauten Konvertierungs-Funktionen in UTF-8 umgewandelt, aus welchem Eingabe-Encoding auch immer, und das Resultat landet in einer Datei auf der Platte, über die dann ECheck ausgeführt wird. Die selbe Datei wird am Ende in den Server gefüttert. Damit muss der Server selber sich nur um UTF-8 Dateien kümmern, und kennt keine anderen Encodings. Er braucht auch nichts umwandeln, weil intern alle meine Strings auch als UTF-8 kodiert sind (C ist nicht Java, wir haben nur char*, keine String-Klassen).

Falls Interesse besteht, der Code für mein Befehls-Annahme Skript findet sich im github-Repository von Eressea:
https://github.com/eressea/server/blob/ ... -accept.py

Übrigens ist iso-8859-15 genau das selbe wie iso-8859-1, außer dass es ein Euro-Zeichen enthält. Noch ein Grund, nur Unicode zu benutzen, da muß man nicht für jede neue Währung auf der Welt wieder ein weiteres Encoding standardisieren. Uff.

[Hamilcar]

Bei uns läuft es ähnlich. Die Email kommt an und aus den Metadaten wird das benutzte Enconding gelesen und dann in den Befehlsordner als UTF-8 Datei abgelegt. Genaueres kann Dir Thalian schreiben. Seit dem haben wir auch keine weiteren Probleme damit gehabt.
Z.Z. überlege ich eher, ob die Vorarbeit nicht besser mit einer genormten Befehlsdatei endet, so daß ich mir im Server dann auch Probleme wie Holzfällerhütte == Holzfaellerhütte == Holzfällerhuette == Holzfaellerhuette sparen kann. Ein Client wie Magellan kann nach diesen Regeln dann die Befehle auch normiert an den Server geben.

[Enno]

Z.Z. überlege ich eher, ob die Vorarbeit nicht besser mit einer genormten Befehlsdatei endet, so daß ich mir im Server dann auch Probleme wie Holzfällerhütte == Holzfaellerhütte == Holzfällerhuette == Holzfaellerhuette sparen kann. Ein Client wie Magellan kann nach diesen Regeln dann die Befehle auch normiert an den Server geben.

Zu der Ersetzung hat Eressea eine ganz eigene Lösung, die ich niemandem empfehlen würde (ist in umlaut.c, und versteht niemand). Generell kann man aber jedes solche Token intern erst einmal normalisieren (alle Umlaute durch Umschreibung ersetzen), und danach erst den Lookup machen, um welches Item oder welches Gebäude es sich hier handelt. Also, du hast eine Map, die von dem normalisierten Namen auf das Ding zeigt:

Code: Alles auswählen

{
    "holzfaellerhuette": {
        "name": "Holzfällerhütte",
        "size": 6
    },
    "todesstern": {
        "name": "Todesstern",
        "size": 100
    }
}

Zum Lookup normalisiert man die Eingabe des Spielers (und macht alle Buchstaben klein), zur Ausgabe im Report benutzt man das .name Attribut, damit die Umlaute schön sind.