[TYPO3-german] Codierung im eid script

[Stephan Schuler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo zusammen.

In aller Kürze: Absatz 2.5 hiervon:
http://www.ietf.org/rfc/rfc4627.txt
Dein "\u00e4" ist das Zeichen "ä" in utf-8.

Der String "Täglich" wäre in JSON erlaubt, vollkommen ohne Codierung des ä.
Einen zwingenden Grund das nicht so zu machen seh ich nicht, jedenfalls nicht rein auf Basis des Formats. Die Erklärung steht unter 3: Dass es sich um UTF-8 handelt sollte ein Consumer an den ersten vier Bytes des Strings erkennen können.

Allerdings stellt die Verwendung dieser Schreibweise sicher, dass der String auch dort transportiert weren kann wo sonst nur ASCII erlaubt ist.
Man stelle sich die MySQL-Datenbank in latin vor die utf-8 bekommt. Meines Wissens schneidet MySQL dann einfach stillschweigend den String beim Schreibvorgang am ersten Nicht-Latin-Zeichen ab.

Diese Codierung hat also nichts damit zu tun dass der Consumer dieser Datei gerade kein utf-8 anzeigen möchte. Es spielt also keine Rolle ob man die Ausgabe des Scripts im Browser betrachtet, ob man dort ein Content-Encoding mitsendet, ob man die Ausgabe dieses Scripts in der Bash von curl auf stdout legt oder im vi öffnet. Der Producer der Datei hat sich lediglich entschieden, aus Sicherheitsgründen das utf-8-Zeichen zu Maskieren.
Damit steht das zunächst mal exakt so im JSON-String.

Das Vorgehen ist aber keineswegs speziell sondern im JSON-RFC exakt so vorgegeben. Dementsprechend kann man davon ausgehen, dass jeder Consumer der "json_encode" ordentlich umsetzt daraus wieder einen ordentlichen utf-8-String rekonstruieren kann.

Aber: Was genau hast Du denn eigentlich vor?

Irgend wie bekomme ich deine Werkzeuge nicht unter einen Hut.
Ein eID ist erst mal ein minimaler Web-Bootstrap. Der kann zwar Daten liefern, wird aber in der Regel nicht via Cronjob aufgerufen. Und die Betonung liegt auf "minimal".
Ein Cronjob ruft eher ein CLI auf. Wenn es etwas mächtiger sein darf: Gerine einen Extbase CommandController.

Dein eID ist an dieser Stelle übrigens schon grob falsch.

Bei dem gigantischen TSFE das Du da lädst (fe_user, Language, TypoScript) hast Du im günstigsten Fall ein vollständiges Frontend, hättest Dir das eID also sparen können. Im schlimmsten Fall läufst Du in ein Cachingproblem, im weniger schlimmen Fall verhält sich alles nur anders als erwartet. Und das "no_cache" sorgt dafür, dass der Request sehr teuer ist weil mindestens das TypoScript neu berechnet werden muss.

Lass das eID bleiben und verwende stattdessen einen PageType. Dann hast du cachbares TypoScript und mit etwas Hirn vollständig cachebare Inhalte. Wenn Du -- die Tabelle lässt mich das vermuten -- ohnehin Extbase-Daten exportieren möchtest würde ich an Deiner Stelle einen JsonView in einem ExportController verwenden. Kein Query gegen die Datenbank sonern ein schönes Repository, Argument-Mapping mit Frameworkunterstützung und das Model gibt die Datenstruktur vor.

Wie Du Daten von extern aktualisierst hängt sehr von der Komplexität der Daten ab. Bei sehr flachen Daten ist das einfach, bei tiefen Daten nicht mehr.

Im günstigsten Fall hast Du auf beiden Seiten die gleiche Datenstruktur und kannst ggf. die Zieldaten einfach in den Property-Mapper werfen. Schau Dir dazu vielleicht an was der Extbase Mvc ActionController macht wenn er Request-Arguments mappt. Im Idealfall kannst Du deine Daten in exakt die Datenstruktur bringen die der Mapper erwartet und dann da rein werfen. Es könnte bereits genügen, wenn Du die UID als "__identity" übergibst und alle anderen Properties exakt so wie sie im Model heißen.

Es gibt (das sind jetzt die Internas) da z.B. den "PersistentObjectConverter".

Aufruf etwa so:
$persistentObjectConverter->convertFrom(array('__identity' => 5, 'title' => 'neuer Titel', 'Dummy\\Extension\\Domain\\Model\\MyModel');

Raus kommt ein Objekt der angegebenen Model-Klasse das sich von dem in der Datenbank durch den hier neuen Titel unterscheidet. Wenn man das dann ins MyModelRepository->update() wirft ist die Magie schon vorbei. PersistAll nicht vergessen, fertig.

Gruß,


Stephan Schuler
Web-Entwickler | netlogix Web Solutions

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Web: websolutions.netlogix.de




netlogix GmbH & Co. KG
IT-Services | IT-Training | Web Solutions
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: info at netlogix.de | Web: http://www.netlogix.de

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt



________________________________________
Von: typo3-german-bounces at lists.typo3.org <typo3-german-bounces at lists.typo3.org> im Auftrag von Ralf-Rene Schröder <ralf.rene at online.de>
Gesendet: Dienstag, 8. Dezember 2015 16:31
An: typo3-german at lists.typo3.org
Betreff: Re: [TYPO3-german] Codierung im eid script

Am 08.12.2015 um 15:44 schrieb Bernd Wilke:
>> {"key":"text","value":"T\u00e4glich ge\u00f6ffnet von 9.00-19.00
>> wie könnte ich die Codierung der Umlaute und Steuerzeichen vermeiden ???
>
> das ist doch eigentlich nur eine Frage der Anzeige bzw. interpretation
> der Daten. sieht eigentlich nach UTF8 aus.
ist es auch... in der DB ist es sauberes utf-8

> das wird dein Browser mit der JSon ausgabe aber nicht unbedingt default
> anzeigen. wechsle die Anzeige-Kodierung!
Da ist der Knoten geplatzt... danke...

> wenn du dort UTF-8 Zeivchen erwartest sollte das schon passen.
thanks... genau das brauche ich dann

- --
image[FORMAT] - Ralf-René Schröder
http://www.image-format.eu ... Wir geben Ihrem Image das richtige Format
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.3.2 (Build 15917)
Charset: utf-8

wpUDBQFWZ28Fpp0IwsibV8MBCPxWA/9oZOzBKgs8O+dCG92OV1+pzbb7d+gOLfJf
/viiM/rBK1bqO/AkLmrXUNkWP9L99WJAlM67PyNCLRmDj64iQ94jNSfmTtHu0AwL
H1wzjyRpghPgmKnr2u/oWhm2Iz11KZ9d+pdBEB+9dL8j1DJoMrTiDh/MsaF4hO9v
ljnWRyk/jg==
=Gl40
-----END PGP SIGNATURE-----