Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

ÅÄÖ i php filer

Tråden skapades och har fått 22 svar. Det senaste inlägget skrevs .
1
Skriv svar
#1
  • Medlem ●
  • 2004-03-10 21:01

Håller på och skrotar lite med en phpbb forum lösning. Så syker ett problem upp.
Om man använder BBEdit (som jag gör) så blir å,ä och ö felaktiga tecken påwebbsidan. Visst jag kan skriva in å men i flera av de översatta php languag e filer jag har så står åä & ö i "klartext". Undrar pm det kan ha med BBE att göra?

Tips?

php är iofs inte så värst macigt men PC nissar begriper inte vad problemet är tycks det...

Erik

Anmäl Ändra Svara
#2
  • Medlem ●
  • Stockholm
  • 2004-03-10 22:33

Det har att göra med att BBEdit liksom de flesta mac-program använder teckenkodningen Mac-roman, medan PHP utgår från att du kör med ISO Latin 1. Dreamweaver använder ISO Latin 1 vilket också är kompatibelt med Windows och Linux/Unix. Textredigeraren i OS X har också möjlighet att öppna och spara i olika teckenkodningar.

Anmäl Ändra Svara
#3
  • Medlem ●
  • 2004-03-10 23:08

Tack för ditt snabba svar!
Dessvärre sitter jag hemma på min gamla Imac och pysslar med detta. På en 400MHz G3 vill jag inte köra X. Skall testa med Dreamweaver och se, tack för tipset.

Erik

Anmäl Ändra Svara
#4
  • Oregistrerad ●
  • 2004-03-11 08:03

Du kan också bara slå över BBEdit till den önskade encodingen. I preferences styr du dessa defaults via "Text files: opening" och "Text files: Saving".

(Regel no 1. Det finns ingenting BBEdit inte kan... )

Anmäl Ändra Svara
#5
  • Oregistrerad ●
  • 2004-10-08 09:06

Jag har byggt hela min php-sajt med filer kodade i UTF-8, det kändes mer "universellt" och lite plattformsoberoende. Lite problem dock eftersom många antar att sidorna är i mer standard ISO Latin 1. Hur fungerar denna encoding, man kan väl skriva å ä ö rakt av istället för html entitets-tjofräset (fackspråk)?

Är det alltså bättre med ISO Latin 1 än UTF-8? Och vad hände med ISO 8859-1 eller vad den heter?

Anmäl Ändra Svara
#6
Ursprungligen av torbjorn2000:

Jag har byggt hela min php-sajt med filer kodade i UTF-8, det kändes mer "universellt" och lite plattformsoberoende. Lite problem dock eftersom många antar att sidorna är i mer standard ISO Latin 1. Hur fungerar denna encoding, man kan väl skriva å ä ö rakt av istället för html entitets-tjofräset (fackspråk)?

Är det alltså bättre med ISO Latin 1 än UTF-8? Och vad hände med ISO 8859-1 eller vad den heter?

ISO Latin 1 är ett annat namn för iso-8859-1.

När det gäller UTF-8 vs ISO Latin 1 så funkar båda bra, förutsatt att man är nogrann med att tala om vilken teckenkodning man använder överallt, d.v.s. i PHP-filerna, i HTML-koden samt i databasen (om man använder en sån).

"Fördelen" med ISO Latin 1 är att den ofta är default, d.v.s. om man inte anger vad man använder för teckenkodning så antas det att det är den man använder. Så funkar bl.a. MySQL och de flesta webbläsare. Som regel ska man dock alltid ange vad man använder.

Fördelen med UTF-8 är givetvis att den har stöd för fler tecken än ISO Latin 1.

Anmäl Ändra Svara
#7
  • Oregistrerad ●
  • 2004-10-08 09:20
Ursprungligen av capojava:

När det gäller UTF-8 vs ISO Latin 1 så funkar båda bra, förutsatt att man är nogrann med att tala om vilken teckenkodning man använder överallt, d.v.s. i PHP-filerna, i HTML-koden samt i databasen (om man använder en sån).

Hur anger man encoding i php-filer? Dvs rena phpfiler utan HTML, t ex klasser, funktionsbibliotek mm?

Ursprungligen av capojava:

"Fördelen" med ISO Latin 1 är att den ofta är default, d.v.s. om man inte anger vad man använder för teckenkodning så antas det att det är den man använder. Så funkar bl.a. MySQL och de flesta webbläsare. Som regel ska man dock alltid ange vad man använder.

Det är det jag har anat, det är en klar fördel. Att UTF-8 stödjer fler tecken blir nog inget problem eftersom jag använder endast västeuropeiska tecken (å, ä,é, £ osv)

Anmäl Ändra Svara
#8
Ursprungligen av torbjorn2000:

Hur anger man encoding i php-filer? Dvs rena phpfiler utan HTML, t ex klasser, funktionsbibliotek mm?

Där anger man det inte med text i själva filen, utan det gäller bara att se till att editorn är inställd på rätt teckenkodning.

Anmäl Ändra Svara
#9
  • Medlem ●
  • Bollnäs
  • 2004-10-08 09:20

Använder man XHTML i för sidbeskrivningen så är standardval där UTF-8 (XML-standard). Man kan använda andra, men jag tycker nog att UTF-8 är det man bör använda alltid. Blir framtidssäkert, innehåller ALLA tecken (65 535 st) och är garanterat plattformsoberoende.

Gammalt skrot som MacRoman och ISO 8859-x hör inte hemma på webben.

Anmäl Ändra Svara
#10
  • Oregistrerad ●
  • 2004-10-08 10:26

Precis, det går att ange i html/xhtml-filerna men inte i rena php-kod-filer. Lite dumt egentligen att det inte skrivs i filens metadata eller något så inte programmet som öppnar den behöver gissa...

Anmäl Ändra Svara
#11

Sitter man med BBEdit 8 (vilket kräver senaste versionen av OS X) kan man "återöppna" ett dokument med en annan teckenkodning, det är rätt smidigt.

Använder man Fetch för att överföra textfilerna kan man låta Fetch automatiskt konvertera ISO Latin 1 rätt mellan mac och pc (det gäller dock att hålla tungan rätt i munnen så man gör det rätt båda vägarna).

Anmäl Ändra Svara
#12
  • Oregistrerad ●
  • 2004-10-08 12:27

I BBEdit kan man ju jobba direkt mot filer på ftp-servern. Hur blir det med enocdingen där? Någon som har någon erfarenhet att den kan bli fel vid överföringen? Jag har varit med några gånger där det har blivit helt uppfuckat, men om man öppnade det igen och sparade om det kan det bli bättre..

Anmäl Ändra Svara
#13
  • Oregistrerad ●
  • 2004-12-03 09:34

Funkar det bara inte att använda det underaba pluginet MiDex? Dvs att konvertar om allt innan du skickar upp det? Kär jag jämt med och det funkar klockrent. Men jag kanske missförstod frågan

Anmäl Ändra Svara
#14
Ursprungligen av torbjorn2000:

I BBEdit kan man ju jobba direkt mot filer på ftp-servern. Hur blir det med enocdingen där? Någon som har någon erfarenhet att den kan bli fel vid överföringen? Jag har varit med några gånger där det har blivit helt uppfuckat, men om man öppnade det igen och sparade om det kan det bli bättre..

Behöver du inte oroa dig för; BBEdit arbetar inte _på_ servern, utan mellanlagrar datan i en gömd temp-fil. Så det ska funka som det gör annars.

Anmäl Ändra Svara
#15
  • Medlem ●
  • 2004-12-03 12:45

Ska du koda "protokoll-korrekt" så är det &;-koder för html och %-koder för URL:er som gäller. Det finns palletter för dessa i BBEdit om man har svårt att komma ihåg saker.

När jag själv gör sidor med mycket text brukar jag skriva vanligt och sedan köra en massiv serach&replace på ÅÄÖ på hela siten.

På alla modernare webbläsare fungerar detta i <head> för att ange vilken encoding som används;
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

I PHPn kan du titta på funktionen htmlentities(), som konvererar strängar till html-tecken.

(Edit; stavfel)

Anmäl Ändra Svara
#16
Ursprungligen av SirN:

När jag själv gör sidor med mycket text brukar jag skriva vanligt och sedan köra en massiv serach&replace på ÅÄÖ på hela siten.

Jag brukar köra Translate (Markup -> Utilities -> Translate...) för att enkelt konvertera text om det bara är på en sida, det är lite smidigare.

Anmäl Ändra Svara
#17
  • Oregistrerad ●
  • 2004-12-03 12:47

Men om man kör med UTF-8 så behöver man väl inte dravla med html-enteties?

Anmäl Ändra Svara
#18
  • Medlem ●
  • Bollnäs
  • 2004-12-03 13:16
Ursprungligen av torbjorn2000:

Men om man kör med UTF-8 så behöver man väl inte dravla med html-enteties?

Inte helt och hållet. Ett utmärkt exempel är & (et-tecken) som måste anges som html-kod. Den är ju själv en del av html-koden så det är inte så himla konstigt.

Det kan också bli problem med vissa tecken utanför basic-latin om man använder ett OT-typsnitt som kanske på vissa datorer förekommer som TT/PS1 istället. Om man då anger en decimalkodning av tecknet i unicodetabellen istället (eller html-kod) så ersätts just det tecknet med ett annat typsnitt där tecknet förekommer. Annars kommer tecknet inte att synas.

Vi snackade om sånt här tidigare, och jag har skrivit en liten notis om det hela på min sajt.

Anmäl Ändra Svara
#19
  • Medlem ●
  • 2004-12-03 13:03

Vet webbläsaren vilken kodning som används, exempelvis med en meta-content-type tag, så slipper man alltid html-koderna.

Anmäl Ändra Svara
#20
  • Oregistrerad ●
  • 2004-12-03 13:06

OK, men enligt ISO-8859-1-standarden så måste man alltid skriva html-entetis för alla konstiga tecken såsom ÅÄÖ?

I sånt fall, varför används den öht när det det är enklare att slippa skriva om specialtecken?? Isf borde UTF-8 vara allenarådande!

Anmäl Ändra Svara
#21
Ursprungligen av torbjorn2000:

OK, men enligt ISO-8859-1-standarden så måste man alltid skriva html-entetis för alla konstiga tecken såsom ÅÄÖ?

I sånt fall, varför används den öht när det det är enklare att slippa skriva om specialtecken?? Isf borde UTF-8 vara allenarådande!

Nej - iso-8859-1 har inget att göra med HTML-entities. Anledningen till att man använder entities är att inte webbläsarna förstår åäö annars. Om inte encoding är satt på samtliga relevanta platser

Anmäl Ändra Svara
#22

Jo, men det blir ju ett bök att läsa och redigera sen. Till exempel slutar ju alt att fungera när man vill alt-stega ord-vis, och går istället till första entity...

Senast redigerat 2004-12-06 01:04
Anmäl Ändra Svara
#23
Ursprungligen av scooterbabe:

Jo, men det blir ju ett bök att läsa och redigera sen. Till exempel slutar ju alt att fungera när man vill stega ord-vis, och går istället till första entity...

Ja, nuförtiden brukar det fungera rätt bra att spara sidan med svenska tecken om man ser till att teckenkodningen är ISO-Latin-1 och inte Mac OS Roman (som det är som default). Eller om man arbetar med UTF-8 förstås.

Anmäl Ändra Svara
1
Bevaka tråden
Nytt i forumet
Debatterade nyheter
Senaste nytt
2 Hur ser ditt julpynt ut hemma?
0 3 ljusa tips för att hålla inbrottstjuvarna borta – använd smart belysning!
12 Slutet på något gammalt - början på något nytt
5 Rykte: Apple väntas lansera en uppdaterad 27" iMac i början av 2022
22 99mac blir Macradion på en helt ny plattform
1 Macradion: Vi släpper lös kraften tillsammans
0 Apple backar på den nya designen av Safari i macOS Monterey
24 Apple släpper macOS Monterey den 25 oktober
0 HomePod mini kommer i fler färger
91 Apple presenterar MacBook Pro, M1 Pro och M1 Max
4 Apple presenterar tredje generationens AirPods
2 Så här ser du Apples event ikväll
1 Apple Watch Series 7 - är det värt att uppgradera?
0 Macradion: Unleash the MF appstore
7 Detta tror vi att Apple visar upp på eventet
1 Apple förlänger sitt serviceprogram för AirPods Pro
0 Rykte: MacBook Pro har samma leverantör av miniLED-paneler som iPad Pro
3 Apple bjuder in till event den 18 oktober
1 BaseLynx: Modulär laddstation utan gränser
1 Tile håller koll på allt från plånbok till nycklar men saknar en nyckelfunktion
0 Apple överklagar domen för betalning genom tredjepartsutvecklare i App Store
Copyright © 2024. Allt innehåll tillhör Svenska Tekniknyheter AB. Citering är tillåten om källan anges. Vi reserverar oss för eventuella informationsfel.
Om 99, RSS, Kontakta oss, Feedback, Trivselregler, Teknisk information och cookies