Hoe browsers te vermijden Unicode-normalisatie bij het indienen van een formulier bij Unicode

Bij het weergeven van de volgende Unicode-tekst in HTML, blijkt dat de browser (Google Chrome) een bepaalde vorm van Unicode-normalisatie bij het terugplaatsen van de gegevens naar de server. (Waarschijnlijk in formulier C ).

Maar bij het gebruik van de Bijbelse Hebreeuwse tekst (בְּרִיךְ הוּא) kan dit gemakkelijk de tekst doorbreken, zoals beschreven in hier (pagina 9).

Is er een manier om de browsers normalisering van de autotekst te voorkomen?

I wrote a blog post that describe in more details the issue that I'm facing: http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text

11
@Hans nee. Waarom denk je dat?
toegevoegd de auteur Fitzchak Yitzchaki, de bron
Nee, ik heb geen algoritme om het toevoegen van het CombiningGraphemeJoiner -hulpprogramma te automatiseren, en zelfs als ik het had, wil ik de normalisatie helemaal vermijden om de karakterbetekenissen te behouden.
toegevoegd de auteur Fitzchak Yitzchaki, de bron
@ JukkaK.Korpela Op de server heb ik geprobeerd de gegevens op de server op te zoeken en er was niets overeenkomend. Het bleek dat de tekst op de een of andere manier is veranderd. Dan vergeleek ik de originele string, en degene die ik krijg van de browser na een succesvolle post-back. Dan vond ik dat dit deel uitmaakt van de HTML-specificatie, om de tekst te normaliseren, w3.org/ TR/charmod-norm .
toegevoegd de auteur Fitzchak Yitzchaki, de bron
@ JukkaK.Korpela nee, de normalisatie gebeurt door de browser. Ik schrijf een blogpost die dit laat zien, die veel meer details bevat.
toegevoegd de auteur Fitzchak Yitzchaki, de bron
Waarom denk je dat Google Chrome tekst normaliseert bij het plaatsen van formuliergegevens? Kunt u alsjeblieft een voorbeeld geven?
toegevoegd de auteur Jukka K. Korpela, de bron
@FitzchakYitzchaki, het W3C-document is een werkversie van een beleidsdocument, effectief vanaf het jaar 2005, dat nu wordt herzien (let op de tekst: "Deze versie van dit document is gepubliceerd om aan te geven dat de kernactiviteit van de Internationalization Core-werkgroep de aanbevelingen substantieel moet wijzigen of vervangen hier in de nabije toekomst gevonden met zeer verschillende aanbevelingen. "). Ik denk niet dat browsers het toepassen of opzettelijk enige normalisatie uitvoeren op formuliergegevens. Geef een voorbeeld voor analyse. Het is goed mogelijk dat normalisatie aan de serverzijde wordt uitgevoerd bij het opslaan van de gegevens.
toegevoegd de auteur Jukka K. Korpela, de bron
Kun je niet gewoon de tijdelijke oplossing toepassen die in hetzelfde document wordt beschreven?
toegevoegd de auteur jalf, de bron
En naar welke specifieke browsers vraag je? Er is geen enkele gestandaardiseerde API voor "schakel normalisatie uit bij het indienen van formulieren", voor zover ik weet. Individuele browsers hebben al dan niet een optie om dit te beheersen. En wil je een manier voor je website om normalisatie uit te schakelen, of een manier voor de gebruiker van de browser om zijn browser te configureren om niet te normaliseren?
toegevoegd de auteur jalf, de bron
Ik kwam deze hier , maar kijkend naar de bug lijkt het opgelost te zijn nu.
toegevoegd de auteur ShreevatsaR, de bron

3 antwoord

Dit lijkt een functie/bug te zijn in WebKit-browsers (Chrome, Safari); ze normaliseren formuliergegevens naar NFC, wat onder andere betekent dat opeenvolgende combinatietekens worden herordend tot een "canonieke" volgorde. Dit was nieuw voor mij en slecht nieuws in dit soort gevallen. Het ergste is dat verschillende browsers zich anders gedragen.

Een vereenvoudigde versie van uw testcase gebruiken http://blog.hibernatingrhinos.com/12449/would-it-be-possible-to-have-a-web-browser-based-editor-for-an-hebrew-text (met behulp van een server-side script dat alleen de onbewerkte gegevens weergalmt), merkte ik dat Chrome en Safari de diakritische tekens opnieuw ordenen in U + 05E9 U + 05C1 U + 05B5 (SHIN, SHIN DOT, TSERE), terwijl IE, Firefox, en Opera doen dat niet.

Ik heb ook een eenvoudige test uitgevoerd met Latijnse letter e gevolgd door het combineren van diaerese U + 0308. WebKit-browsers zetten het om naar het enkele karakter ë, volgens NFC-regels, terwijl andere browsers het karakterpaar intact houden.

Dit lijkt een opzettelijk kenmerk te zijn, sinds 2006; https://bugs.webkit.org/show_bug.cgi?id=8769 kondigt dit trots aan als onderdeel van een bugfix! Dit zou de status van het W3C-beleidsdocument kunnen verklaren; de huidige versie is WebKit-minded in dit nummer, maar andere browseraanbieders zijn niet geïnteresseerd of strijden bewust tegen het idee van 'vroege normalisatie'.

Ik denk niet dat er een manier is om dit te voorkomen. U kunt gebruikers echter waarschuwen voor het gebruik van Chrome en Safari. U zou zelfs een verborgen veld kunnen gebruiken dat een eenvoudig probleemgeval bevat, controleer dan aan de kant van de server of het werd verzonden zoals het is, en vertel de gebruiker om de browser te wijzigen als dit niet het geval is.

Het is niet eenvoudig om de server-kant te repareren, omdat gemeenschappelijke normalisatieroutines klaarblijkelijk de benodigde bestelling niet ondersteunen. U kunt normaliseren tot volledig gedecomposeerde vorm (NFD) en vervolgens opnieuw ordenen met het combineren van markeringen met uw eigen code voor het doel. Misschien eenvoudiger en veiliger, zou u gewoon een ad-hoc vervangingsroutine kunnen uitvoeren die reeksen combinatietekens met andere reeksen vervangt. Dit zou veiliger zijn omdat het geen andere personages zou beïnvloeden dan die je wilt beïnvloeden, terwijl NFD onder andere Latijnse letters met diakritische tekens ontleedt.

Volgens Unicode-principes zijn canoniek equivalente reeksen (die bijvoorbeeld alleen verschillen in de volgorde van opeenvolgende diakritische tekens) verschillende weergaven van dezelfde gegevens maar onderscheiden zich als reeksen Unicode-tekens (codepunten); er wordt niet van hen verwacht dat ze verschillen qua presentatie, maar ze kunnen en zullen dat ook vaak doen. Over het algemeen mag u niet verwachten programma's om canoniek equivalente reeksen als verschillend te behandelen, hoewel programma's kunnen een verschil maken. Zie de Veelgestelde vragen over Unicode-normalisatie .

In de FAQ-vermelding wordt beweerd dat de problemen van bijbels Hebreeuws zijn opgelost door de introductie van COMBINING GRAPHEME JOINER. Hoewel het het opnieuw ordenen in Chrome voorkomt, is het een onhandige methode en kan het de weergave verknoeien (dit doet het in webbrowsers, diakritische tekens kunnen erg misplaatst raken).

10
toegevoegd
Ik denk dat dit meer een bug is dan een functie, omdat de normalisatie niet voorkomt bij het renderen van tekst, maar bij het indienen van formulieren. Op dit moment moeten normalisatiebeslissingen de server één zijn en niet de browser.
toegevoegd de auteur Fitzchak Yitzchaki, de bron
Ik heb hier een probleem voor gemaakt, code.google.com/p/chroom/issues/& hellip;
toegevoegd de auteur Fitzchak Yitzchaki, de bron
+1: "Maar u kunt gebruikers waarschuwen voor het gebruik van Chrome en Safari." Meestal wordt de gebruiker gewaarschuwd voor het gebruik van ie6-8.
toegevoegd de auteur Timo Kähkönen, de bron
Is het niet beter om alle strings in de database op te slaan in een bepaalde vastgestelde normalisatie? Browsers weten UTF8 te renderen/bewerken in elke normalisatie die u ze geeft. Stuur UTF-8 naar binnen (zeg NFC), laat ze bewerken, enz. En normaliseer vervolgens bij opslag op NFC. Afrekenen met een normalisatie staat zoeken toe, niet doen gaat terug op het retourneren van hetzelfde byte-patroon dat de gebruiker heeft ingevoerd. Het is uw keuze. We slaan meestal woordelijk op en gebruiken bij het zoeken speciale niet-ascii old school zoekalgoritmen.
toegevoegd de auteur Tom Andersen, de bron
Ik ben Los tegenover hetzelfde (Bug?). code.google.com/p/chromium/issues/detail hier geplaatst ? id = 117128 # . Dus wat is de oplossing? Personages aan serverzijde wijzigen? Ik heb daar ook een rel voor geschreven.
toegevoegd de auteur Shiplu Mokaddim, de bron
Tom Andersen, het probleem was hier dat een bepaald niet-NFC-formulier, ingevoerd door de gebruiker, nodig was voor een correcte weergave (van bijbelse Hebreeuwse tekst). Dus het ging erom de volgorde te bewaren zoals geschreven, en browserinterventie (vroege normalisatie) maakt dat onmogelijk.
toegevoegd de auteur Jukka K. Korpela, de bron

Het is mogelijk om de normalisatie van de reeks te vermijden door een Uint8Array te verzenden in plaats van een tekenreeks. Verkrijg eerst de UTF-8-gegevens van je string als een Uint8Array zoals beschreven hier door @Moshev:

function utf8AbFromStr(str) {
    var strUtf8 = unescape(encodeURIComponent(str));
    var ab = new Uint8Array(strUtf8.length);
    for (var i = 0; i < strUtf8.length; i++) {
        ab[i] = strUtf8.charCodeAt(i);
    }
    return ab;
}

Dan kunt u POST die Uint8Array POST met plain XHR of uw favoriete Ajax-bibliotheek. Als u jQuery gebruikt, moet u er rekening mee houden dat u processData: false moet opgeven om te voorkomen dat jQuery dit stringent en al uw harde werken ongedaan maakt.

1
toegevoegd

U kunt de tekst aan de clientzijde manipuleren voordat u deze verzendt. Als u een combinatie van Grapheme Joiner invoegt, kunt u deze invoegen via JavaScript.

As a staring point, but here's a JSFiddle that gets the characters letter by letter (tested in Safari and it doesn't normalize text): http://jsfiddle.net/TmtnA/

0
toegevoegd