Arabischer Permalink nicht gefunden

Ich arbeite an der arabischen WordPress-Website und ich habe ein Problem, wenn arabischer Titel für den Beitrag verwendet wird. Die einzelne Post-Seite wird immer auf 404-Seite umgeleitet, aber mit englischen Permalinks funktioniert es perfekt

als ich versucht habe, the_permalink(); zu benutzen the_permalink(); es gibt zurück:

 http://a3lamy.com/%d8%aa%d8%ac%d8%b1%d8%a8%d8%a9/ 

während in WordPress Admin Dashboard, wenn bearbeiten Post der Permalink sieht wie folgt aus:

 http://a3lamy.com/تجربة/ 

Die Sortierung der Datebank-Server lautet utf8_general_ci

wenn ich die wp-posts-tabelle öffne, habe ich den nachnamen gefunden:

 %d8%aa%d8%ac%d8%b1%d8%a8%d8%a9 

und wenn ich es manuell ändere, wird es zu تجربة in der database, aber immer noch leitet der Permalink zur 404 not found page!

Meine web.config

                  

Jede Hilfe wird geschätzt.

Solutions Collecting From Web of "Arabischer Permalink nicht gefunden"

Das ist, weil was Sie wollen, ist nicht möglich, der RFC sagt URLs müssen eine Untermenge von ANSI-Zeichen, die eine Untermenge von lateinischen aZ Zeichen, Zahlen und Symbole umfasst. Es gibt keine Unicode-URL, und es hat nichts mit Ihrer databasecodierung zu tun, WordPress macht seine Arbeit und das ist das erwartete Verhalten.

http://www.blooberry.com/indexdot/html/topics/urlencoding.htm

“… nur alphanumerische Zeichen [0-9a-zA-Z], die Sonderzeichen” $ -_. +! * ‘(), “[Ohne die Anführungszeichen – ed] und reservierte Zeichen, die für ihre reservierten Zwecke verwendet werden innerhalb einer URL uncodiert verwendet werden. ”

Allerdings spricht nicht jedes Land US-Englisch, so haben wir RFC3986: http://www.faqs.org/rfcs/rfc3986.html

Wikipedia sagt:

Während URIs auf eine Teilmenge des ASCII-Zeichensatzes beschränkt sind, können IRIs Zeichen aus dem universellen Zeichensatz (Unicode / ISO 10646) enthalten, darunter chinesische oder japanische Kanji, koreanische, kyrillische Zeichen und so weiter.

Syntax

IRI erstreckt sich auf URIs unter Verwendung des universellen Zeichensatzes, während URIs auf das ASCII mit viel weniger Zeichen beschränkt waren. IRIs können durch eine Folge von Oktetten dargestellt werden, sind jedoch definitionsgemäß als eine Folge von Zeichen definiert, da IRIs von Hand gesprochen oder geschrieben werden können. 2 So arbeiten URLs mit fremden Nicht-ANSI-Zeichen. Da URLs nur eine Untergruppe von ANSI unterstützen, müssen nicht lateinische Zeichen codiert werden.

Es ist nicht großartig, aber die ursprüngliche HTTP-Spezifikation kann nicht mit nicht-englischen Zeichen umgehen, und das ist der Hack, mit dem sie das umgehen konnten. Das Gleiche wird mit Kanji, Emoji und anderen nicht-englischen Buchstaben passieren

Ein Experiment

Wenn ich also eine Testseite namens تجربة erstelle:

Bildschirm bearbeiten

Dann besuche die Seite:

Die Seite

Alles sieht korrekt aus, aber wenn ich die URL kopiere, bekomme ich folgendes:

 https://tomjn.com/%D8%AA%D8%AC%D8%B1%D8%A8%D8%A9/ 

Welches ist die https://tomjn.com/ تجربة / als URL kodiert ?

% D8% AA% D8% AC% D8% B1% D8% A8% D8% A9 ist eine Menge arabischer Zeichen, wobei jedes% codierte Oktett den Zeichencode im universellen Zeichensatz darstellt

Dies ist das erwartete Verhalten und wie es funktionieren soll und ist in allen Browsern und HTTP-sprechenden Anwendungen implementiert, die internationalisierte URLs und Domains unterstützen

Der Grund dafür ist, dass esc_url die URL über esc_url und urlencode , aber wenn Sie diesen entfernen und ihn so ausgeben, wie er auf der Seite ist, würde er die Dinge nicht ändern, da der Browser dies dann automatisch am Ende des Benutzers tun würde. Wenn dies nicht der Fall wäre, würden Sie eine errorshafte HTTP-Anfrage erhalten, die nicht korrekt funktioniert.

Woher kommen die 404er?

Wenn du in die database gehst und den Slug manuell in تجربة wird WordPress ihn nie finden können. Der Browser ändert es in %d8%aa%d8%ac%d8%b1%d8%a8%d8%a9 , und WP sucht dann in der database danach. Es wird es jedoch nicht finden, da es in تجربة geändert wurde