Neu Empfohlene Zeichenkodierung und Line-Endings für einen Editor unter Windows

[JohnnyMcDoogle]

Hallo,

ich möchte gern ein Template verändern und habe vor, als Vorlage Evo zu benutzen. Ich würde gern von Euch wissen, welche Einstellungen zu

• Line-Endings (LF vs. CRLF)
• Zeichenkodierung (UTF-8 vs. ISO-8859-1 vs. Windows)
• git core.autocrlf (true vs. false vs. input)

ich unter Windows (10 Pro) für einen Texteditor (in meinem Fall VS Code) für die Entwicklung von Templates (vielleicht auch Plugins) einstellen soll, bzw. wie was empfohlen wird.
Ich habe die Forumssuche, den Guide und die Docs bemüht, aber genau dazu nichts gefunden: falls ich etwas übersehen habe, würde ich mich über einen "Fingerzeig" freuen.

Vielen Dank im Voraus,
Johnny

 

[FPrüfer]

Hallo,
im Shop-Core sind alle Dateien in UTF-8 mit LF als Line-Ending angelegt. core.autocrlf hängt davon ab, wie deine IDE Line-Endings behandelt und wie das ggfs. bei deinen Mitstreitern eingestellt ist.

 

[JohnnyMcDoogle]

Hallo FPrüfer,

vielen Dank für Deine zügige Antwort. Ich habe einen Mitstreiter, wir haben beide die selbe IDE unter Windows und die gleichen Settings. Unter localhost haben wir, wahrscheinlich durch falsche Line-Endings (CRLF war eingestellt), laut "Shopdateien-Check" modifizierte Dateien. Das wollen wir so natürlich nicht. Die Dateien sollen dann per SSH und git "nach oben" (Unixoide Umgebung mit Apache) übertragen werden. So weit zum Hintergrund. Hast Du da eine Empfehlung zu "core.autocrlf"?


Gruß,
Johnny

 

[fibergirl]

Dazu auch mal eine Frage.
Ich habe Importdateien für die Ameise, z.B. Artikeltexte, die über die Wawi in den JTL- Shop sollen.
Mittelfristig ist da der JTL-Shop 5 mit Nova-Template angestrebt, soweit ich weiß verwendet der durchgehend UTF8.
Beim JTL-Shop 4 ist es mir unklar.

Die Importdateien haben Umlaute u.ä. teils in ANSI (eigentlich Windows), teils als HTML-Entities (wie ä )
Ich grüble darüber nach, ob und wohin ich diese umwandeln sollte.
Ich könnte auch alle Umlaut-HTML-Entities in ANSI wandeln und dann reines ANSI importieren, aber was ist mit dem Shop?
Oder alles gleich in UTF8 umcodieren für den Shop, aber was macht die WAWI dann damit?

Line-Endings bei den Templates sind natürlich eine andere Sache.
Aber Templates und Core-PHP in UTF8 und Artikeldaten in ANSI, kann das sein?

 

[FPrüfer]

Hast Du da eine Empfehlung zu "core.autocrlf"?

Wenn eure Windows-IDE ganz normal LF als Zeilenende speichert und nicht still und heimlich überall ein CR/LF draus macht oder beim Öffnen von LF-Dateien alles in einer Zeile darstellt, dann braucht ihr für git kein explizites core.autocrlf setzen. Ansonsten sollte es auf "true" stehen. Siehe dazu auch: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_code_core_autocrlf_code

 

[FPrüfer]

Dazu auch mal eine Frage.
Ich habe Importdateien für die Ameise, z.B. Artikeltexte, die über die Wawi in den JTL- Shop sollen.
Mittelfristig ist da der JTL-Shop 5 mit Nova-Template angestrebt, soweit ich weiß verwendet der durchgehend UTF8.
Beim JTL-Shop 4 ist es mir unklar.

Die Wawi verwendet unabhängig vom Shop eine ISO-8859-x Kodierung. Das wird wohl auch noch mit Shop5 so sein, so dass alle Daten die von der Wawi zum Shop kommen bzw. vom Shop zur Wawi gesendet werden immer daran gebunden sind und entsprechend umkodiert werden müssen.

Die Importdateien haben Umlaute u.ä. teils in ANSI (eigentlich Windows), teils als HTML-Entities (wie ä )
Ich grüble darüber nach, ob und wohin ich diese umwandeln sollte.
Ich könnte auch alle Umlaut-HTML-Entities in ANSI wandeln und dann reines ANSI importieren, aber was ist mit dem Shop?
Oder alles gleich in UTF8 umcodieren für den Shop, aber was macht die WAWI dann damit?

Da in der ISO-8859-1 Kodierung, mit der Shop und Wawi kommunizieren, auch deutsche Umlaute darstellbar sind, würde ich dafür die native Darstellung empfehlen. Für alle anderen Sonderzeichen sollte nach Möglichkeit die Darstellung in HTML-Entities gewählt werden.

Aber Templates und Core-PHP in UTF8 und Artikeldaten in ANSI, kann das sein?

Alle Ausgaben die direkt über den Shop-Core erfolgen (z.B. Meldungen im Backend) sind im Shop4 in HTML-Entities kodiert, so dass es keine Kollisionen zwischen der Code-Kodierung (UTF-8) und der Ausgabe im HTML (ISO-8859-1) gibt. Deutsche Umlaute die von der Wawi in ISO-8859-1 gesendet werden, werden über eine Latin1-Kodierung in die DB geschrieben und auf dem gleichen Weg wieder ausgegeben, so dass hier Umlaute in Artikeltexten direkt möglich sind. Ab Shop5 ist dann innerhalb des Shops alles in UTF-8 und nur die Schnittstelle zur Wawi macht eine passende Umkodierung.
@JohnnyMcDoogle In Bezug auf Shop4 muss ich mich korrigieren. Die deutschen Mailtemplates (unter admin/mailtemplates/ger) sind nicht in UTF-8, sondern in ISO-8859-1 kodiert, sonst könnten dort keine Texte mit Umlauten hinterlegt und korrekt verschickt werden.

 

[fibergirl]

Herzlichen Dank @FPrüfer !

Dann werde ich mal voll auf ISO-8859-1 setzen und die Umlaute und einige Sonderzeichen (z.B. ß, µ) nativ darstellen, allein schon damit sie von der Suche gefunden werden können.
(Was ist mit dem Euro-Zeichen?).

Wenn der Shop dann irgendwann UTF-8 braucht, wird er es sich selbst umwandeln bzw. generieren.

Sorry fürs Kapern des Threads, aber vielleicht war es gar nicht so schlecht fürs allgemeine Verständnis ...

 

[Xantiva]

Wenn eure Windows-IDE ganz normal LF als Zeilenende speichert und nicht still und heimlich überall ein CR/LF draus macht oder beim Öffnen von LF-Dateien alles in einer Zeile darstellt, dann braucht ihr für git kein explizites core.autocrlf setzen. Ansonsten sollte es auf "true" stehen. Siehe dazu auch: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#_code_core_autocrlf_code

Da möchte ich mal einhaken ...

Eine wichtige Frage dabei ist: Wie kommen die Daten auf den Webserver?

core.autocrlf = true bedeutet, dass die Dateien auf Windows-Systemen automatisch mit CrLf vorliegen. Werden diese Dateien auf den Linux-Server hochgeladen, sind sie "modifiziert".

Umgekehrt ist ein "Deployment" per git push in Produktivsysteme ist nicht zu empfehlen. Nicht nur die letzten Hacks von Github und Gitlab-Repositories basierten darauf, dass User so gearbeitet haben. Im Webroot sollte kein .git-Verzeichnis existieren!

Kleiner Auszug aus einem access_log:

xx.xx.xx.xx - - [02/Feb/2019:12:01:44 +0100] "GET /.git/HEAD HTTP/1.1" 404 162 "-" "Python-urllib/3.6"
xx.xx.xx.xx - - [03/Feb/2019:00:36:46 +0100] "GET /.git/HEAD HTTP/1.1" 404 162 "-" "Python-urllib/3.6"
xx.xx.xx.xx - - [09/Feb/2019:00:44:53 +0100] "GET /.git/HEAD HTTP/1.1" 404 162 "-" "Python-urllib/3.5"
xx.xx.xx.xx - - [23/Mar/2019:18:11:35 +0100] "HEAD /.git/config HTTP/1.1" 301 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

Webseiten werden nach Git-Repositories gescannt!

Wenn die Dateien über ein CI/CD-System per "Dateikopie" in den Webroot übertragen werden und das CI/CD-System mit "LF" arbeitet ist das ok, wenn aber auch mal die Dateien per FTP/SSH vom Windows-Rechner in den Webroot übertragen werden sollen, dann würde ich explizit mit

* text eol=lf

arbeiten!

 

[FPrüfer]

Was ist mit dem Euro-Zeichen?

Gute Frage! ISO-8859-1 kennt de facto kein Euro-Zeichen (als dieser Standard entwickelt wurde gab es noch keinen Euro). Irgendwie wurde es aber reingewurschtelt und einfach das Zeichen 128 durch das Euro-Zeichen ersetzt. Deshalb müsste eine native Darstellung in Shop4 (ISO-8859-1 -> latin1 -> ISO-8859-1) funktionieren. Spätestens jedoch wenn das Ganze in Zeichensätze konvertiert werden muss, die das Euro-Zeichen grundlegend unterstützen (ISO-8859-15, UTF-8) wird es problematisch... Umkodierungsfunktionen sind meist Krümelkacker und beharren darauf, dass ISO-8859-1 kein Euro-Zeichen kennt. Hier muss also das € immer als Ausnahme behandelt werden.
Wenn man dem Ärger aus dem Weg gehen will, dann schreibt man es also am Besten in HTML-Entities.

 

[fibergirl]

Gute Frage! ISO-8859-1 kennt de facto kein Euro-Zeichen (als dieser Standard entwickelt wurde gab es noch keinen Euro). Irgendwie wurde es aber reingewurschtelt und einfach das Zeichen 128 durch das Euro-Zeichen ersetzt. Deshalb müsste eine native Darstellung in Shop4 (ISO-8859-1 -> latin1 -> ISO-8859-1) funktionieren. Spätestens jedoch wenn das Ganze in Zeichensätze konvertiert werden muss, die das Euro-Zeichen grundlegend unterstützen (ISO-8859-15, UTF-8) wird es problematisch... Umkodierungsfunktionen sind meist Krümelkacker und beharren darauf, dass ISO-8859-1 kein Euro-Zeichen kennt. Hier muss also das € immer als Ausnahme behandelt werden.

Genau, darauf war ich auch gestoßen.

Wenn man dem Ärger aus dem Weg gehen will, dann schreibt man es also am Besten in HTML-Entities.

Das löst das Problem für mich, aber nicht für euch.
Ihr werdet immer damit rechnen müssen, dass irgendeine JTL-Wawi dem JTL- Shop 5 in irgendeinem Text ein ISO-8859-1 Euro-Zeichen einflößt.
Entwerder Ihr müsst alles vorab filtern und die Euro-Zeichen schon mal durch HTML-Entities ersetzen, oder ...

Was ist, wenn Ihr die Texte iconv als ISO-8859-15 verkauft? Vorher vielleicht auch alle 0x80 (Windows-1252 Euro) zu 0xA4 (ISO-8859-15 Euro) wandeln.
Dann wäre das Zeichen an 0xA4 gültig.
Allerdings gibt es noch ein paar weitere Unterschiede: https://matthias.wimmer.name/tables/latin1-9
Die Frage ist, ob diese Zeichen unter Windows in der JTL-Wawi überhaupt benutzt wurden/benutzbar sind.

 

[JohnnyMcDoogle]

Umgekehrt ist ein "Deployment" per git push in Produktivsysteme ist nicht zu empfehlen. Nicht nur die letzten Hacks von Github und Gitlab-Repositories basierten darauf, dass User so gearbeitet haben. Im Webroot sollte kein .git-Verzeichnis existieren!

Vielen Dank für Deinen Hinweis. Siehst Du denn auch ein Problem, wenn neben dem ".git"- ein "www"-Verzeichnis liegt, auf das die Domain zeigt? Das ".git"-Verzeichnis sollte doch so nicht erreichbar sein, nicht?

@FPrüfer vielen Dank für Deine Antwort.

 

[Xantiva]

Wenn das .git nicht öffentlich zu erreichen ist, sollte das kein großes Problem sein. Alternativ würde ich mir aber mal CI/CD-Systeme anschauen. Dann muss auf dem Produktivsystem auch kein Git laufen.

 

[JohnnyMcDoogle]

Hallo,

Alternativ würde ich mir aber mal CI/CD-Systeme anschauen. Dann muss auf dem Produktivsystem auch kein Git laufen.

Das eine schließt das andere doch nicht aus: ich will auf dem Produktivsystem "pullen", angestoßen via CI/CD.


Gruß,
Johnny

 

[Mirko.Schmidt User deaktiviert]

Per Gitlab CI/CD kann in der .gitlab-ci.yml der Build, Test und Deploy Prozess durchlaufen werden. Dabei kann auch ein manuelles deployen eingestellt werden, welches nur für spezielle Branches gilt. Am besten wäre es dann mit rsync zuarbeiten und --exclude bzw --exclude-from bestimmte Dateien und Ordner auszuschließen. Als Lektüre kann sich https://docs.gitlab.com/ce/ci/ und https://docs.gitlab.com/ce/ci/variables/ angesehen werden.

 

[JohnnyMcDoogle]

Am besten wäre es dann mit rsync zuarbeiten und --exclude bzw --exclude-from bestimmte Dateien und Ordner auszuschließen.

Das habe ich ja alles schon in der ".gitignore" definiert, ich möchte das nicht redundant pflegen.

 

[Mirko.Schmidt User deaktiviert]

Dann kann einfach im "rsync --exclude-from=.gitignore" genutzt werden. Dann wird alles aus der .gitignore Datei nicht berücksichtigt. z.B. so:
rsync -rltog --exclude-from=.gitignore --exclude=.gitignore --exclude=.gitlab-ci.yml

 

[JohnnyMcDoogle]

Dann kann einfach im "rsync --exclude-from=.gitignore" genutzt werden. Dann wird alles aus der .gitignore Datei nicht berücksichtigt. z.B. so:
rsync -rltog --exclude-from=.gitignore --exclude=.gitignore --exclude=.gitlab-ci.yml

Das ist cool, vielleicht schwenke ich doch um. Mal schauen, vielen Danke für Deine Antwort.