XCode Html ékezetes karakter probléma

Tags: #<Tag:0x00007f8a1a0d1410> #<Tag:0x00007f8a1a0d12d0>

Sziasztok!

A prog.hu-n van egy kérdés, miszerint az XCode-dal szerkesztett html fileokban elszállnak az ékezetes karakterek ftp-feltöltés után. Szerintem nem az XCode a ludas, a transferre Forkliftet használ a kérdező, ami szintén nem nyúl bele a karakter-kódolásba. Hallott már ilyenről valaki esetleg?

https://prog.hu/tudastar/200277/macbook-es-xcode-html-es-ekezetes-karakterek

A minta szoveg alapjan tuti kodlap problema lesz. Kene egy eredeti file, es egy Xcode alltal modositott filet bezipelve felraknia valahova, valamint kellene egy minta URL, mert lehet, hogy hiaba irogat mindenfele encodinngot a htmlbe, ha a server kitol egy html charset headert.

Igen, en is ezt kerdeztem most, hogy nem tesz-e bele a szerver a response Content-Type-ba egy charset-et.

Hú nah hát kísérleteztem még vele, és egyre nagyobb a káosz. :D
Menjünk sorban.
Van egy windows.html fájl, ezt windowson készítettem, ott is töltöttem fel.
http://www.bendix.hu/teszt/windows.html

Ezt a windowsos fájlt letöltöttem xcode-dal módosítottam és feltöltöttem.
Ami érdekesség, hogy ebben is jól jelenik meg az É betű, de valószínű azért, mert amikor xcode-al megnyitom a windows.html fájlt, akkor az é betű így jelenik meg: “È”, azaz balra dől az ékezet, de lefutáskor már normálisan jelenik meg. Módosítottam is ezt a fájlt, a sima é betűt nem veszi, csak ha azt másolom ami balra dől.
http://www.bendix.hu/teszt/windowsmod.html

Ezen kívül van még 2 fájl, amik megint máshogy viselkednek, már belekavarodtam vagy a macen vagy a szerverről töltöttem le…
http://www.bendix.hu/teszt/valami.html
Ez tipikusan úgy viselkedik, mint amivel írtam a probléma felvetését. Nem jelennek meg jól. Írhatok bele bármilyen ékezetet, de nem jelenik meg jól.

http://www.bendix.hu/teszt/mac.html
Ez pedig megint különös, ebbe nem is írhatok hosszú ő betűt például, mert akkor nem engedi elmenteni a fájlt.

Forráskód ügyileg mindegyik fájl ugyanaz, a szöveg eltérő.
Én már kezdem feladni… :D

Content-Type:text/html; charset=iso-8859-2

Ezt teszi bele a szerver az általa kiszolgált html-be. Vagyis, ha ezzel a kódolással mented el a html filejaidat, szerintem jónak kellene lenniük.

Egyébként webre nem az igazi az XCode. Vannak sokkal jobb szoftverek, esetleg kukkants át ebbe a topicba:

Hát de hogyan tudom azzal a kódolással menteni? Xcode-ba megpróbáltam mást beállítani, de semmi.
Mindenesetre annyira nem ragaszkodok az xcode-hoz, szóval storeból letöltöttem most a TextWrangler-t, amivel elmentettem, nem változott, de egyszerűbb a kezelhetősége mert alul rögtön látom, milyen karakterkódolással van, UTF-8, de nem volt jó, utána kiválasztottam UTF-8 with BOM, azt nem tudom mit jelent, de működik. :D
Szóval most jól jelenik meg.
Fogalmam sincs mit kell változtatni, hogy xcodeon jó legyen, de annyi baj legyen, annyira nem ragaszkodok hozzá, eddig windowson sima jegyzettömbböt használtam, szóval tökéletes ez a textwrangler :D Köszönöm szépen!

Érdekes. Nekem a múltkor egy halom videót kellett feliratoznom, akkor szívtam a méreteset a kódlapokkal, 8859-2-ben jött egy része, ami persze szerkesztés közben már keveredett a gépen használt utf billentyűzet karaktereivel, a lényeg, hogy végül vettem egy nagy levegőt, és átkonvertáltam mindent utf8-ra, de mac-en nem sikerült, sem text wrangler, sem jublerrel, windows és notepad lett a megoldás, ott ami nem stimmelt, azt case sensitive keres/cseréllel kicseréltem, majd save as utf8.

“Egyes windowsos programok a fájl elejére írt 0xEF,0xBB,0xBF bájtsorozattal jelzik, hogy UTF-8 kódolású fájlról van szó; ezt néha UTF-8 BOM kódolásnak hívják. Ez a bájtsorozat ugyanis az U+FEFF Unicode-azonosítójú bájtsorrend-jel (angolul byte order mark, röviden BOM) UTF-8 kódja; a BOM karakter normális esetben UTF-16 kódolás elején állva azt jelzi, hogy a kétbájtos számok kisebb vagy nagyobb helyiértékű bájtja van-e elöl. (UTF-16-ban ugyanis az U+FEFF karakter kódja 0xFE,0xFF, a két bájt felcserélésével kapott 0xFF,0xFE pedig nem érvényes UTF-16 kód.) UTF-8-ban ennek a karakternek elméletileg nincs jelentése, így használható a kódolás jelzésére, azonban ez megtöri az ASCII-kompatibilitást, így nem javasolt. Az így kódolt PHP fájlok például a weboldal elején megjelenő  karaktersorozatot eredményeznek.”

Egyes windowsos?! Ezt neha BOM-nak hivjuk?! Nem csak a windows vilagaban hasznalt, hanem kb barhol hasznalhato. Teljesen szabvanyos es elfogadott dolog. Segitsegevel jelezheto, hogy milyen tipusu kodolast hasznal pl az adott bytestream. A PHP-nak ehhez semmi koze, mivel a BOM a php tageken kivul all, igy ha ebbe beleszolna a php interpreter, akkor az nagyon nagy hiba lenne. Ezzel az informacioval maximum a bongeszonek kellene kezdenie valamit, de azok meg nem szoktak.

Akkor van gebasz, ha include-olsz egy fájlt amin van BOM.
Jártunk már úgy, hogy valahogy odakerült, és ki kellett venni…

De ekkor is fuggetlen az egesz hibajelenseg a php-tol, mert a BOM a php tagen kivul van, tehat nem csinalhat vele semmit sem az interpreter, ennek megfeleloen megjelenik a kimenetben. Itt inkabb maga a php mukodesenek a koncepcioja hibas, azert okoz ez problemat.