Umstellung auf Unicode: Unterschied zwischen den Versionen
Enno (Diskussion | Beiträge) |
Enno (Diskussion | Beiträge) |
||
| (29 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
Am | Am 9. Dezember wird sich das Format der Reporte ändern, was für alle Tools ein Upgrade erfordert. Ich habe | ||
das mit den Entwicklern im Vorfeld besprochen, so dass sie das nicht jetzt erst überrascht. In der Woche der Umstellung ist aber zu empfehlen, dass ihr euch vergewissert von Magellan, Vorlage, usw. | das mit den Entwicklern im Vorfeld besprochen, so dass sie das nicht jetzt erst überrascht. In der Woche der Umstellung ist aber zu empfehlen, dass ihr euch vergewissert, ob euer Tool Unicode unterstützt bzw ob eine neuere Version von Magellan, Vorlage, usw. verfügbar ist. | ||
== Was wird | == Was umgestellt wird == | ||
Der CR und der NR werden in Zukunft in [http://en.wikipedia.org/wiki/UTF-8 UTF-8] kodiert. Bisher wurde [http://en.wikipedia.org/wiki/ISO-8859-1#ISO-8859-1 ISO-8859-1] verwendet. Vorteil der neuen Kodierung ist, dass es dann auch möglich ist Zeichen zu verwenden die nicht in westlichen Alphabeten vorkommen, wie z.B. aus Esperanto oder Kyrillisch. | Der CR und der NR werden in Zukunft in [http://en.wikipedia.org/wiki/UTF-8 UTF-8] kodiert. Bisher wurde [http://en.wikipedia.org/wiki/ISO-8859-1#ISO-8859-1 ISO-8859-1] verwendet. Vorteil der neuen Kodierung ist, dass es dann auch möglich ist Zeichen zu verwenden die nicht in westlichen Alphabeten vorkommen, wie z.B. aus Esperanto oder Kyrillisch. | ||
== | == Kompatible Versionen bekannter Clients == | ||
* [[CSMapFX]] ab rev. 124 | * [[CSMapFX]] ab rev. 124 (rev. 125 empfohlen) | ||
* [[Magellan]] ab Version 1.2.4 | * [[Magellan]] ab Version 1.2.5 bzw. Version 2 (getestet mit Build 108) - Achtung, nach Neuinstallation von Magellan müssen evtl. die Kartenrenderer in Extras -> Options -> Karte neu aktiviert werden (sind evtl. inaktiv) '''(HOTFIX: Magellan_1_2_5e)''' | ||
* [[Vorlage]] ab Version 1.6.2-1 (Build 524) | |||
* [[ECheck]] ab Version 4.3.2-5 | |||
* [http://www.studis.de/Eressea/Tools/ CRISPY] ab Version crispy-0.7+dev-1030 | |||
== | == Abwärtskompatibilität für alte Clients == | ||
Windows-User können zum Beispiel [http://sourceforge.net/project/downloading.php?group_id=181990&use_mirror=switch&filename=CpConverter_v0.1.3.zip&32502743 Codepage Converter], und damit das Encoding des Reports ändern (siehe Screenshot für korrekte Einstellungen). | Windows-User können zum Beispiel [http://sourceforge.net/project/downloading.php?group_id=181990&use_mirror=switch&filename=CpConverter_v0.1.3.zip&32502743 Codepage Converter], und damit das Encoding des Reports ändern (siehe Screenshot für korrekte Einstellungen). | ||
Linux-User können ihren Report einfach mit iconv in das alte Format bringen, indem sie <tt>iconv -f utf8 -t latin1 < meinreport.cr > neuer_report.cr</tt> benutzen. | Linux-User können ihren Report einfach mit iconv in das alte Format bringen, indem sie <tt>iconv -f utf8 -t latin1 < meinreport.cr > neuer_report.cr</tt> benutzen. Wenn das nicht funktioniert kann man alternativ auch das Programm <tt>piconv</tt> verwenden. Es ist normalerweise bei jeder <tt>Perl</tt> Installation mit enthalten. | ||
Mac-User können eventuell mit [http://free.abracode.com/cyclone/ Cyclone] etwas anfangen. | Mac-User können eventuell mit [http://free.abracode.com/cyclone/ Cyclone] etwas anfangen. | ||
== | 11.12.2007: Von Solthar aus dem Magellan-Team stammt ein Tool extra für die UTF-8 CRs. Es ist auf sourceforge verfügbar, [https://sourceforge.net/project/showfiles.php?group_id=174030&package_id=255398 hier]. Wähle Deinen CR oder mehere CRs, bestätige und neue CRs werden angelegt, der Dateiname automatisch um "iso" ergänzt. Verlangt java 1.4 | ||
== Schritte zur Anpassung seltbstgeschriebener Clients == | |||
Die einfachste Lösung ist, in den Code der den CR einliest einen Konverter einzubauen, der bei auffinden eines <tt>"UTF-8";charset</tt> Eintrages beginnt, die eingelesenen Daten durch einen UTF-8 -> ISO-8859-1 Konverter zu schicken. Dazu kann man entweder die [http://en.wikipedia.org/wiki/Iconv iconv]-Bibliothek benutzen oder sich einen von zahlreichen Codeschnipseln ergooglen. | Die einfachste Lösung ist, in den Code der den CR einliest einen Konverter einzubauen, der bei auffinden eines <tt>"UTF-8";charset</tt> Eintrages beginnt, die eingelesenen Daten durch einen UTF-8 -> ISO-8859-1 Konverter zu schicken. Dazu kann man entweder die [http://en.wikipedia.org/wiki/Iconv iconv]-Bibliothek benutzen oder sich einen von zahlreichen Codeschnipseln ergooglen. | ||
Zum Testen habe ich [http://enno.homeunix.net/tmp/hse-reports.zip hier] eine ZIP-Datei mit den Reporten der | Zum Testen habe ich [http://enno.homeunix.net/tmp/hse-reports.zip hier] eine ZIP-Datei mit den Reporten der letzten HSE-Partie ins Netz gestellt. | ||
== | == Was beim Versenden von Befehlen beachtet werden muss == | ||
Ich habe da bereits eine Reihe Tests durchgeführt, um sicherzustellen dass da nichts schiefgehen sollte. Falls allerdings Probleme mit Umlauten auftauchen sollten, bitte umgehend [http://eressea.upb.de/mantis/ Bugreports] machen. | Ich habe da bereits eine Reihe Tests durchgeführt, um sicherzustellen dass da nichts schiefgehen sollte. Falls allerdings Probleme mit Umlauten auftauchen sollten, bitte umgehend [http://eressea.upb.de/mantis/ Bugreports] machen. | ||
Oder anders gesagt: Man kann die Befehle sowohl in UTF-8, als auch ISO8859-1 senden. Zu beachten ist, dass die Angaben im (oftmals unsichtbaren) E-Mail-Header mit dem verwendeten Encoding der Befehle überein stimmen muss. | |||
== Externe Links == | == Externe Links == | ||
* [http://groups.google.com/group/eressea-client Eressea-Client Mailingliste] | * [http://groups.google.com/group/eressea-client Eressea-Client Mailingliste] | ||
* [http://enno.homeunix.net/tmp/hse-reports.zip HSE-Reporte in UTF8] | |||
* [http://sourceforge.net/projects/cp-converter/ Codepage Converter] | |||
[[Kategorie:Software]] | [[Kategorie:Software]] | ||
Aktuelle Version vom 7. Juni 2009, 20:53 Uhr
Am 9. Dezember wird sich das Format der Reporte ändern, was für alle Tools ein Upgrade erfordert. Ich habe das mit den Entwicklern im Vorfeld besprochen, so dass sie das nicht jetzt erst überrascht. In der Woche der Umstellung ist aber zu empfehlen, dass ihr euch vergewissert, ob euer Tool Unicode unterstützt bzw ob eine neuere Version von Magellan, Vorlage, usw. verfügbar ist.
Was umgestellt wird
Der CR und der NR werden in Zukunft in UTF-8 kodiert. Bisher wurde ISO-8859-1 verwendet. Vorteil der neuen Kodierung ist, dass es dann auch möglich ist Zeichen zu verwenden die nicht in westlichen Alphabeten vorkommen, wie z.B. aus Esperanto oder Kyrillisch.
Kompatible Versionen bekannter Clients
- CSMapFX ab rev. 124 (rev. 125 empfohlen)
- Magellan ab Version 1.2.5 bzw. Version 2 (getestet mit Build 108) - Achtung, nach Neuinstallation von Magellan müssen evtl. die Kartenrenderer in Extras -> Options -> Karte neu aktiviert werden (sind evtl. inaktiv) (HOTFIX: Magellan_1_2_5e)
- Vorlage ab Version 1.6.2-1 (Build 524)
- ECheck ab Version 4.3.2-5
- CRISPY ab Version crispy-0.7+dev-1030
Abwärtskompatibilität für alte Clients
Windows-User können zum Beispiel Codepage Converter, und damit das Encoding des Reports ändern (siehe Screenshot für korrekte Einstellungen).
Linux-User können ihren Report einfach mit iconv in das alte Format bringen, indem sie iconv -f utf8 -t latin1 < meinreport.cr > neuer_report.cr benutzen. Wenn das nicht funktioniert kann man alternativ auch das Programm piconv verwenden. Es ist normalerweise bei jeder Perl Installation mit enthalten.
Mac-User können eventuell mit Cyclone etwas anfangen.
11.12.2007: Von Solthar aus dem Magellan-Team stammt ein Tool extra für die UTF-8 CRs. Es ist auf sourceforge verfügbar, hier. Wähle Deinen CR oder mehere CRs, bestätige und neue CRs werden angelegt, der Dateiname automatisch um "iso" ergänzt. Verlangt java 1.4
Schritte zur Anpassung seltbstgeschriebener Clients
Die einfachste Lösung ist, in den Code der den CR einliest einen Konverter einzubauen, der bei auffinden eines "UTF-8";charset Eintrages beginnt, die eingelesenen Daten durch einen UTF-8 -> ISO-8859-1 Konverter zu schicken. Dazu kann man entweder die iconv-Bibliothek benutzen oder sich einen von zahlreichen Codeschnipseln ergooglen.
Zum Testen habe ich hier eine ZIP-Datei mit den Reporten der letzten HSE-Partie ins Netz gestellt.
Was beim Versenden von Befehlen beachtet werden muss
Ich habe da bereits eine Reihe Tests durchgeführt, um sicherzustellen dass da nichts schiefgehen sollte. Falls allerdings Probleme mit Umlauten auftauchen sollten, bitte umgehend Bugreports machen.
Oder anders gesagt: Man kann die Befehle sowohl in UTF-8, als auch ISO8859-1 senden. Zu beachten ist, dass die Angaben im (oftmals unsichtbaren) E-Mail-Header mit dem verwendeten Encoding der Befehle überein stimmen muss.
