Dotaz: PHP - konce řádků DOS nebo UNIX?

[pavele]

Převáděl jsem webovou aplikaci napsanou v PHP (WAMP) z Windows do linuxu (LAMP).

Všechno funguje, jen přenesené soubory mají UTF-8.DOS konce řádků.

Nechat nebo změnit na UTF-8.UNIX?

Odpovědi

[Kit]

PHP je to docela jedno. Doporučuje se nechat defaultní nastavení Gitu. Pak budou ve Windows dosovské konce řádků a v Linuxu unixové. V repozitáři to však bude jednotně. Git automaticky zajistí obousměrnou konverzi.

[Sten]

Git ve výchozím nastavení konce řádků nemění:

While Git normally leaves file contents alone, it can be configured to normalize line endings to LF in the repository and, optionally, to convert them to CRLF when files are checked out.

Je potřeba to zapnout pomocí core.autocrlf.

[Kit]

Je potřeba to zapnout pomocí core.autocrlf.

Což je podle mne výchozí konfigurace po instalaci, alespoň ve většině distribucí.

[Sten]

Ve kterých?

Debian: ne
CentOS: ne
RHEL: ne
Ubuntu: ne

Docela bych se divil, kdyby to někde bylo výchozí, protože to je problematické a potenciálně nebezpečné nastavení. Jako výchozí to měl jednu dobu nastavené Git for Windows (msysgit), ale ten to zrušil.

[pavlix]

+1

Navíc to vyžaduje rozlišováné binárních a textových souborů, což git vnitřně za normálních okolností nerozlišuje.

Jako výchozí to měl jednu dobu nastavené Git for Windows (msysgit), ale ten to zrušil.

Tak ono to stačí mít nastavené jen na zkripleném systému, to měl asi namysli, když psal o výchozím nastavení. Ale jestli už to neplatí, tak je to věc jiná.

[pavlix]

Druhá věc je, že v dotazu nepadla o Gitu ani zmínka.

[pavele]

Já o koncích řádků PHP LAMP v linuxu, oni o gitu.

[Kit]

Myslím si, že by ti mohla stačit hned první věta, kterou jsem napsal: PHP je to jedno.

Zbytek můžeš v klidu ignorovat.

[pavlix]

PHP jsou sice jedno konce řádků, ale zase si tak úplně neporadí s windowsovskou variantou UTF-8. Na což narazil každý, komu se někde zdánlivě náhodně ve stránce objevila trojice paznaků. :)

[Kit]

Zřejmě máš na mysli BOM. To je slušná pohroma. Je to ještě před symbolem <?php, takže to má beze změny zkopírovat na výstup. Co na tom, že to znemožní následné odeslání hlaviček? To je spíš nedostatkem použitého textového editoru. PHP je v tom nevinně.

[pavlix]

Je to jak jsem psal, na windows je standardem BOM dávat, přestože UTF-8 žádný byte order nemá a tudíž neplní účel, na unixech je standardem BOM nedávat. Textový editor za to nemůže, ten se jen drží de facto standardu daného systému. Navíc na windows je zvykem podle BOM rozlišovat UTF-8 a legacy kódování, takže se dá říct, že je v rámci windows platformy chyba BOM ve výchozí konfiguraci nevložit. Jsem tak rád, že mezi unixáři a linuxáky zůstala ještě trocha toho rozumu. :)

[Sten]

IMO to chyba PHP je, protože to je součást standardu UTF-8, který prý PHP umí. Řešit to mělo PHP6, and to umřelo.

[pavlix]

A co přesně z toho standardu PHP porušuje?

[pavlix]

Odpovím si sám. Je to napsáno dost zmatečně a ne úplně podle zvyklostí, ale nějak to tam je...

Such stripping is necessary in some cases (e.g., when concatenating two strings, because otherwise the resulting string may contain an unintended "ZERO WIDTH NO-BREAK SPACE" at the connection point), but might affect an external process at a different layer (such as a digital signature or a count of the characters) that is relying on the presence of all characters in the stream.

Každopádně je to naprostý shit a do toho standardu se to nemělo nikdy dostat ani takto volitelné. UTF-8 bez BOM je naprosto geniální kódování, které je 100% kompatibilní s ASCII a na které fungují všechny standardní operace s řetězci, které nevyžadují počet skutečně zahrnutých znaků či pozic.

[Kit]

Čtu to stále dokola a nechápu. Se stringem mohu pracovat jako s posloupností znaků nebo jako s posloupností bajtů. Pokud někdo tyto přístupy míchá jak ho napadne, tak ať se nediví.

[pavlix]

Pokud jde o výše popsanou teorii, souhlasím. Ale teď zpět do praxe.

ASCII je kódování, které mapuje jeden znak na jeden bajt s nulovým bitem nejvyššího řádu a naopak. Bajty s jedničkovým bitem nejvyššího řádu zůstávají volné a většina software, co pracuje s ASCII s nimi dokáže pracovat jako s neznámými znaky. Operace nad znaky a bajty jsou zcela totožné. Unixové ASCII navíc vyjadřuje konec řádku vždy jen jedním znakem LF. Jedinou jeho nevýhodou je malý repertoár znaků.

UTF-8 (v jeho nezkriplené podobě) je kódování, které zachovává všechny vlastnosti ASCII s výjimkou počítání a indexování znaků. Je 100% kompatibilní s ASCII. Pro non-ASCII znaky využívá výhradně bajty s jedničkovým bitem nejvyššího řádu. Od jiných rozšíření ASCII se liší pouze tím, že jeden non-ASCII znak vyjadřuje více takovými bajty.

Důsledkem je to, že prakticky veškerý software pracující s ASCII s možností rozšířených znakových sad je beze změny plně funkční i s nezkripleným UTF-8, což je taky hlavní důvod, proč je UTF-8 mezi vývojáři tak populární. Snad jedinou výjimkou je zobrazovací software, který potřebuje znaky napočítat a umístit.

Rozšíření UTF-8 o jakékoli vlastnosti UTF-16 považuju za šlápnutí vedle, s výjimkou explicitního použití UTF-8 pro zakódování šestnáctibitových hodnot (například UTF-16 s chybami).

[Kit]

Kromě posledního odstavce je mi vše jasné. To rozšíření mám chápat jako dynamické přepínání znakové sady pomocí BOMu uvnitř textu dle libosti? Asi by to šlo, ale připadá mi to hodně fuj.

[pavlix]

Ale vůbec ne. Mám namysli například to rozšíření UTF-8 o možnost identifikace pomocí byte order mark původně určené pro rozlišení pořadí oktetů (bajtů) v šestnáctibitovém slově UTF-16, případně dvaatřicetibitovém slově UTF-32. Dneska to standard připouští jako možnost označení textového dokumentu UTF-8. Ale dělají se i další věci jako kódování unicode code pointů pomocí sekvence UTF-16 slov zakódovaných pomocí UTF-8 nebo dokonce chybných šestnáctibitových sekvencí korektně zakódovaných do UTF-8. Něco z toho je kodifikováno jako více či méně volitelná součást standardu, něco není.

[Filip Jirsák]

To není Windowsovská varianta UTF-8, to je UTF-8 s BOM na začátku souboru a je to součástí Unicode standardu.

[petr]

PSR-2:

All PHP files MUST use the Unix LF (linefeed) line ending.

[pavele]

Díky za odkaz, pěkný popis.