[sladaloose]

Hallo,

Kennt ihr bestimmt. Leerzeichen werden in URI's als %20 angegeben, die kaufmännischen Unds (&) werden als %26 angegeben.

Was ich jetzt nicht weiß, aber wissen muss: Manche Webseiten (wie z.B. google.de) wandeln manche Sonderzeichen (z.B. Leerzeichen) in %20 um. Sprich, ich gebe manuell einen Suchparameter für google mit einem Leerzeichen an und der Internet Explorer (oder auch Firefox) wandeln das in %20 um. Jetzt weiß ich nicht, wer das macht.
3 Möglichkeiten:
A) Browser
B) Webserver
C) Applikation auf dem Webserver

Aber das muss ich wissen. Um A) auszuschließen, wäre einfach meine Bitte, ob ihr mal versuchen könnt (ihr habt bestimmt exotischere Browser als ich ), welche Sonderzeichen alles automatisch codiert werden, wenn man bei google den Suchstring manuell bearbeitet (in der Adressleiste).

Wenn wir hier einen Webserver-Guru hier haben, der sagen kann, dass das eine Webserver-Einstellung ist, dann wäre das Super. Ebenso natürlich die Applikations-Gurus (PHP, ASP, etc.), die sagen können in welche ini-Datei man was verstellen kann.

Weiß wer mehr?

Gruß,
sladaloose

Dieser Beitrag wurde von sladaloose bearbeitet: 19. April 2006 - 10:17

[Rika]

Eigentlich kannst du alles escapen, aber notwendigerweise escapen musst du nur '?','%','&','/','\',':','@' sowie alle Sonderzeichen und nichtdruckbare Zeichen.

[sladaloose]

Öhm, nö, nicht die String-Sonderzeichen in einer spez. Programmiersprache.

Ich meine die Codierung für die URL's.

Also weder ä noch \\ sondern %20 (hierzu mal die Adressleiste des Browsers beobachten).

[Graumagier]

Lies mal [url="http://www.ietf.org/rfc/rfc3986.txt"]RFC 3986[/url] bzw. [url="http://www.ietf.org/rfc/rfc1630.txt"]RFC 1630[/url], darin solltest du alle Informationen finden.

[quote name='http://www.ietf.org/rfc/rfc3986.txt']When to Encode or Decode

Under normal circumstances, the only time when octets within a URI
are percent-encoded is during the process of producing the URI from
its component parts. This is when an implementation determines which
of the reserved characters are to be used as subcomponent delimiters
and which can be safely used as data. Once produced, a URI is always
in its percent-encoded form.

When a URI is dereferenced, the components and subcomponents
significant to the scheme-specific dereferencing process (if any)
must be parsed and separated before the percent-encoded octets within
those components can be safely decoded, as otherwise the data may be
mistaken for component delimiters. The only exception is for
percent-encoded octets corresponding to characters in the unreserved
set, which can be decoded at any time. For example, the octet
corresponding to the tilde ("~") character is often encoded as "%7E"
by older URI processing implementations; the "%7E" can be replaced by
"~" without changing its interpretation.

Because the percent ("%") character serves as the indicator for
percent-encoded octets, it must be percent-encoded as "%25" for that
octet to be used as data within a URI. Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string.[/quote]

Dieser Beitrag wurde von Graumagier bearbeitet: 19. April 2006 - 21:03

[Rika]

Und ja, genau das meinte ich.

http%3A//www.winfuture-forum.de/index.php%3Fshowtopic%3D69906

vs.

%68%74%74%70%3A%2F%2F%77%77%77%2E%77%69%6E%66%75%74%75%72%65%2D%66%6F%72%75%6D%2E%64%65%2F%69%6E%64%65%78%2E%70%68%70%3F%73%68%6F%77%74%6F%70%69%63%3D%36%39%39%30%36

vs.

h%74%74%70%3A%2F%2F%77%77%77%2E%77%69%6E%66%75%74%75%72%65%2D%66%6F%72%75%6D%2E%64%65%2F%69%6E%64%65%78%2E%70%68%70%3F%73%68%6F%77%74%6F%70%69%63%3D%36%39%39%30%36

Alles sind escapet, die zweitere ist vollständig escapet, die erstere minimal. Und escapet werden muss genau mindestens das, was ich benannt habe.

Dieser Beitrag wurde von Rika bearbeitet: 21. April 2006 - 13:29

[sladaloose]

Hm, achso meinst du das. Ja, für Internet Explorer nutzer^^

Ich arbeite mit chinesischen Zeichen. Die müssen auch codiert werden, direkte Übergabe funktioniert nicht. Nur beim Internet Explorer. Beim Firefox werden die automatisch umkodiert.

Letztendlich erfolgt die Umwandlung dieser Zeichen in der Applikation auf dem Server. Also in dem Fall Java. Java hat da einen Bug mit 2-Byte Unicode Zeichen, was ja fast alle chinesischen sind.
Da haben wir jetzt eine spezielle Routine geschrieben, die das Problem umgeht.

Aber sonst, ist klar

Danke!

[flo]

@ Rika

Könntest du dir angewöhnen mit

[ codebox ][ / codebox ]

zu Arbeiten, das zerhaut nicht immer das Design

Dieser Beitrag wurde von Flo bearbeitet: 21. April 2006 - 13:19

[Rika]

@sladaloose:

Zitat

Ja, für Internet Explorer nutzer^^

Nein, überall.

Zitat

direkte Übergabe funktioniert nicht. Nur beim Internet Explorer. Beim Firefox werden die automatisch umkodiert.

Der IE kodiert per Default alles in UTF-8, was leider vollkommen falsch ist und auf zu riesigien Problemen führen kann. URI-Escaping ist der richtige Weg.

Zitat

Java hat da einen Bug mit 2-Byte Unicode Zeichen, was ja fast alle chinesischen sind.

Ich glaube vielmehr daß du die Unicode-Geschichte in Java nicht verstanden hast. :-)

Zitat

Da haben wir jetzt eine spezielle Routine geschrieben, die das Problem umgeht.

Es ist kein Problem, du musst nur entsprechend unescape()n. Und das sollte eigentlich schon der Server machen.

@Flo: Sorry, dank der Link Wrap Extension merke ich das nicht.