[php/html] Unicode forms

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Banpei
  • Registratie: Juli 2001
  • Laatst online: 25-10-2022

Banpei

Hachiroku on this touge?

Topicstarter
Geen id of dit 100% in de P&W past, maar vond het qua onderwerp niet in de W&G passen.

Het probleem is dat ik bezig ben met een multi-lingual applicatie waarbij de verschillende talen opgeslagen worden in de database. Nu is het probleem bij talen met niet-ascii characters (Japans, Chinees e.d.) deze dus multi-byte terug komen. Dat gaat dmv of een multi-byte string of via de html-character-encoded entities. (弊 of &#<nummer>; ) Dit verschilt redelijk random, afhankelijk van welke instellingen je hebt bij de browser en welke talen je eventueel geinstalleerd hebt op de computer.

Nu is dit geen enkel probleem, maar vanwege dat deze talen vervolgens via pdflib weer in een pdf gezet moeten worden heb ik deze eenduidig nodig en vanwege het gemak natuurlijk het liefst als de &# variant.

Nu heb ik ik alle pagina's waarin invoer plaats vindt dus aangegeven dat alles unicoded weergegeven moet worden op de pagina en zoals bij een van mijn zoektochten met de search via de accept-encoding property van een form aangegeven dat ik dus alles utf encoded terug wil hebben.

Dit leek allemaal prima te werken: ware het niet dat het dus bij de ene interface nu concequent allemaal als &# terug komt en bij de andere interface als &#<nummer>;.

Het is de bedoeling dat het dus iig gaat werken met IE 5.5 of hoger, dus het is niet een probleem als het niet op alle browsers werkt.

Iemand enig idee hoe ik Apache / PHP / Browser zo kan forcen dat deze dus altijd of de ene of de andere variant geeft?

AE86 gevonden! | So what I thought I'd do was, I'd pretend to be one of those deaf-mutes.


Acties:
  • 0 Henk 'm!

  • Skaah
  • Registratie: Juni 2001
  • Laatst online: 16-09 18:38
Wat komt er precies terug? Alleen &#; en geen nummertjes?

Acties:
  • 0 Henk 'm!

  • darkrain
  • Registratie: Augustus 2001
  • Laatst online: 21:56

darkrain

Moderator Discord

Geniet

Skaah lees de TS nog eens zou ik zeggen

Tweakers Discord


Acties:
  • 0 Henk 'm!

  • BetuweKees
  • Registratie: Januari 2003
  • Laatst online: 15-07 20:53

BetuweKees

Flipje uit Tiel

snap niet precies wat je bedoelt maar als je je form verstuurd als form data (ENCTYPE="multipart/form-data") weet je iig zeker dat alles goed bij je php scriptje aankomt.
daarna zou je eventueel kunnen omzetten dmv html_entities met UTF8 als charset, volgens mij krijg je dan alles in &#int; entities terug

Through meditation I program my heart to beat breakbeats and hum basslines on exhalation -Blackalicious || *BetuweKees was AFK; op de fiets richting China en verder


Acties:
  • 0 Henk 'm!

  • Banpei
  • Registratie: Juli 2001
  • Laatst online: 25-10-2022

Banpei

Hachiroku on this touge?

Topicstarter
BetuweKees schreef op 14 januari 2004 @ 16:47:
snap niet precies wat je bedoelt maar als je je form verstuurd als form data (ENCTYPE="multipart/form-data") weet je iig zeker dat alles goed bij je php scriptje aankomt.
daarna zou je eventueel kunnen omzetten dmv html_entities met UTF8 als charset, volgens mij krijg je dan alles in &#int; entities terug
Helaas werkt het dus niet, dit is de output van html_entities:
code:
1
2
3
&aring;&reg;&sup1;&aelig;&#732;"&atilde;&laquo;&aring;
-&atilde;&#8218;Œ&atilde;&frac34;&atilde;
&#8482;&atilde;&#8249;


Met andere woorden: hij vindt dat sommige characters geescaped moeten worden en laat dus de rest staan... :'(

Ik ben ondertussen al wel een stukje verder: het lijkt er dus op dat als ik wat aan de form inhoud wijzig (lees: eigenlijk alleen maar integerwaarden en utf-encoded zut) het form dus wel prima opslaat. Helaas ging dat bij een andere form niet op. Het rare is dus ook dat de twee interfaces allebei gebruik maken van dezelfde classes en methode van opslag. Ik kan natuurlijk wel zelf een utf -> &#int; functie schrijven die het wel kan, maar dan blijft nog altijd de vraag of al het andere wel goed gaat.

Daarnaast valt mij dus ook op dat bij het gesubmitte form qua inhoud de velden die dus verkeerd gaan iig geen utf-16 start-character (&# 65279 ; ) hebben wat natuurlijk erg vreemd is aangezien alles wel op utf-16 staat. :/

[ Voor 18% gewijzigd door Banpei op 14-01-2004 18:25 . Reden: Aaaargh! Met al die encoded zut... :'( ]

AE86 gevonden! | So what I thought I'd do was, I'd pretend to be one of those deaf-mutes.


Acties:
  • 0 Henk 'm!

  • Banpei
  • Registratie: Juli 2001
  • Laatst online: 25-10-2022

Banpei

Hachiroku on this touge?

Topicstarter
Het lijkt er op dat het nu werkt!

Wat het dus uiteindelijk is:
Content type in html zetten als utf (geen utf-16 of utf-8)
code:
1
<meta http-equiv="content-type" content="text/html;charset=utf">


en in het form wel utf-16 zetten:
code:
1
<form accept-charset='UTF-16' action='edit.php' name='edit_form' method='post'>


Met andere woorden: met utf als character encoding komt het dus altijd op dezelfde manier terug en bij utf-16 de ene keer wel als multi-byte string en de andere keer als html-entities. Zal er wel misschien aan liggen dat bij een copy-paste actie het als utf-8 string gekopieerd wordt en de browser er de ene keer wel een utf-8 -> utf-16 conversie overheen kan doen en de andere keer niet, maar dat blijft natuurlijk giswerk. Het vreemde is dat ik exact hetzelfde probleem heb als ik utf-8 encoding instel. :/

Of de accept-charset nu nog invloed heeft moet ik nog bekijken, maar in alle gevallen lijkt nu alle ge-copy-paste tekst in html-entities terug te komen. :)

Edit: Zover ik kan zien maakt dus de accept-charset idd niet uit, maar voor de volledigheid zal ik die er maar wel in laten staan (je weet maar nooit)

[ Voor 45% gewijzigd door Banpei op 15-01-2004 11:02 ]

AE86 gevonden! | So what I thought I'd do was, I'd pretend to be one of those deaf-mutes.

Pagina: 1