/dev/null - Overig

Security.nl opmaakcode verschillen

25-11-2016, 21:50 door Anoniem, 11 reacties
Webdesign-vraagje

Al jaren is er een verschil tussen de geaccepteerde tekens bij de vooraanschouwing van een bijdrage en de uiteindelijke geplaatste tekst.
In de uiteindelijke definitieve html pagina worden veel minder tekens geaccepteerd waardoor deze uiteindelijk omgezet en weergegeven worden in vraagtekens.

Sterker nog zelfs verborgen opmaakcode kan voor dit soort opdoemende vraagtekens zorgen met als gevolg dat je tekst ineens vergeven is van de vraagtekens.

Nog sterker, soms zit er kennelijk opmaakcode in een tekst die word/teksteditors niet weergeven, hoe hard je dat ook probeert, zelfs naar plain text omzetten helpt kennelijk niet, de codes blijven erin verstopt zitten.
Met alle visuele rommel gevolgen van dien.

Een bekend voorbeeld daarvan wanneer het omzetten op een pagina niet lukt is zo'n klein blokje met 4 kriebeltjes erin, je ziet ze wel eens voorbij komen.
Maar ook witruimte of paragraafruimte kan voor de nodige visueel destructieve ongein zorgen, ziehier (reden om er een keer publiek wat over op te merken) https://www.security.nl/posting/493998/Encryptie+%26+Koppenjagers.

Nogal irritant want nooit vooraf in te schatten.
Maar ja, wat doe je eraan? *


* Behalve, ik voel hem al aankomen, account aanmaken of hele tekst in de webpage typen.
Reacties (11)
25-11-2016, 22:28 door Spiff has left the building
Door Anoniem, 21:50 uur:
[...]
Maar ja, wat doe je eraan? *
* Behalve, ik voel hem al aankomen, account aanmaken of hele tekst in de webpage typen.

Opmaken in een plain text editor, en die tekst kopiëren naar het reactieveld, heb je dat wel geprobeerd?
Mij heeft dat nog nooit problemen met niet geaccepteerde tekens gegeven, als ik het me goed herinner.

Opmaken in een ander formaat dan plain text en dan kopiëren naar een webformulier (of naar een ander formaat in een andere teksteditor) levert vrijwel gegarandeerd af en toe omzettingsprobleempjes op.
Ik heb daar geen zin in, en maak op in plain text, óf tik rechtstreeks in het doelveld.

En waar je schrijft "account aanmaken", volgens mij maakt dat geen enkel verschil.
Ook met account voorkom je evenmin het probleem dat je beschrijft, behalve wanneer je extern opmaakt in plain text, óf rechtstreeks in het doelveld typt.
En ook zonder account kun je de Preview optie gebruiken, om te zien of je tekst wel uitvalt zoals je bedoelt.
25-11-2016, 23:05 door Anoniem
Door Spiff:
Door Anoniem, 21:50 uur:
[...]
Maar ja, wat doe je eraan? *
* Behalve, ik voel hem al aankomen, account aanmaken of hele tekst in de webpage typen.

Opmaken in een plain text editor, en die tekst kopiëren naar het reactieveld, heb je dat wel geprobeerd?
Ja dat is wat ik doe en deed.

Mij heeft dat nog nooit problemen met niet geaccepteerde tekens gegeven, als ik het me goed herinner.
Het gaat o.a. mis bij bullet velden en (maar dat gebruik ik nauwelijks) tekens uit andere talen.

Opmaken in een ander formaat dan plain text en dan kopiëren naar een webformulier (of naar een ander formaat in een andere teksteditor) levert vrijwel gegarandeerd af en toe omzettingsprobleempjes op.
Nou, ja ms word is een beruchte maar die gebruikte ik niet.

En waar je schrijft "account aanmaken", volgens mij maakt dat geen enkel verschil.
Ook met account voorkom je evenmin het probleem dat je beschrijft, behalve wanneer je extern opmaakt in plain text, óf rechtstreeks in het doelveld typt.
In zoverre dat ik het ongedaan kan maken.
Als anoniem lukt dat niet.

En ook zonder account kun je de Preview optie gebruiken, om te zien of je tekst wel uitvalt zoals je bedoelt.
Ja dat weet ik maar dat werkt dus precies niet.

Wat wel werkt, het schoot me later te binnen, is om te kijken wat er te zien is in een html editor.
Die had ik ff niet op dit oude reageer-b-compuutje maar wel een browser.
Plain text document naar een leeg browserveld gesleept (geopend) gaf de 'bastard' code wel weer.

Een paragraaf code die al bij het nalopen van de vormgeving in het security.nl webformulier met preview functie ontzettend geklooi opleverde met ontbrekende witregels die ik nou juist wel zag in mijn tekst editor.
Het bleek (in dit geval) om een combinatie van drie (verborgen opmaak)tekens te gaan, pasted


, een a met een dakje, een euro teken en een trema, maar waarschijnlijk dan een ander niet geaccepteerd lettertype?
Test met mijn toetsenboardteken door de tekens handmatig te typen


Beide zijn gelijk in de preview maar ik verwacht dat bovenste dadelijk naplaatsing vraagtekens oplevert.

Hoe het ook zij, erg irritant (in het verleden wel lange teksten volledig visueel naar de haaien geholpen hier. Voortaan maar geen 'bullet' e.a. lists en vreemde tekens gebruiken) en maar een blanco browser window openen en daar mijn plain text in voorbekijken.

Toch jeukt het nog, wat zou je nog meer aan onzichtbare code kunnen verbergen onder (zelfs) plain text of in een word document?
Malware code, zou dat lukken?

Vast niet, maar wie het zeker weet mag het zeggen.
Dank voor je reactie.
Groet
26-11-2016, 11:44 door Spiff has left the building
@ Anoniem, vr.25-11, 23:05 uur,

Dank je, duidelijk.
Ik ben zelf zelden tegen die problemen aangelopen, doordat ik geen bullet velden gebruik, en maar relatief weinig tekens uit andere talen, of andere vreemde tekens.
Doordat ik geen bullet velden gebruik, was ik vergeten dat bullet weergave hier inderdaad problematisch is.

Accenten, cedille, umlaut, µ, €, en meer dat ik zelf wel eens nodig heb, worden wel correct weergegeven.
Maar bullets zijn veel lastiger. Ik weet niet of bepaalde types bullets hier weergegeven kunnen worden, of helemaal niet.
Ikzelf voorkom problemen door simpelweg maar streepjes te gebruiken voor bullets.
De BBcode optie voor het creëren van rijtjes met bullets, die ontbreekt in ieder geval op Security.NL.

En je hebt gelijk, de preview optie is niet zaligmakend.
Onder meer met bullets kun je daarbij de mist ingaan, dat was ik vergeten.
Copy/paste tekst met bullets kan in de preview correct zijn, maar na het posten ontbreken dan de bullets.
En als de weergave na posten onverhoopt anders uitvalt dan de weergave bij preview, dan kun je dat zonder account niet meer corrigeren. Ik kan me voorstellen dat dat mateloos irritant is, als je je best hebt gedaan met het perfect opmaken van een bijdrage.

Ik hoop dat je ideetje om je tekst eerst te tonen in een html editor, of een leeg browserveld, je voldoende kan helpen om weergavefouten in het reactieveld te kunnen voorkomen.
Maar het zou natuurlijk prettig zijn als dat niet nodig zou zijn. Het zou prettig zijn als de preview werkelijk overeen zou komen met het resultaat na plaatsing.
Ik moet je daar beslist gelijk in geven.
26-11-2016, 13:17 door Briolet - Bijgewerkt: 26-11-2016, 13:22
Ik ken wel meer sites waar de preview wel tekens accepteert, maar je tekst na plaatsing verminkt is. Inderdaad irritant als je heel bewust in de preview kijkt of een accent of speciaal unicode teken door die site geaccepteerd gaat worden.

• ? È <-- die tekens zien er in de preview inderdaad correct uit.

Edit: alleen het tweede teken is verminkt na plaatsing. Ik zie de bullet wel correct. (U+2022 BULLET)
26-11-2016, 13:45 door [Account Verwijderd]
[Verwijderd]
26-11-2016, 15:04 door mcb
Het zou ook handig zijn als de meerdere spaties niet zouden verwijderen.
Erg lastig om iets in tabelvorm weer te geven of idd als bulleted list daar waar extra spaties nodig zijn.
26-11-2016, 16:10 door Anoniem
Apple lijst-opmaak code in TextEdit

Het lijkt erop dat het een probleem is dat zich voordoet bij het gebruik van Apple's tekst editor Textedit.
In de standaard weergave van RTF heb je een aantal opmaak mogelijkheden waaronder het aanmaken van een aantal soorten 'bullet' (neem het niet te letterlijk) lijsten.
Wanneer deze tekst wordt omgezet naar een plain text document (met extensie .txt) blijft toch een deel van de opmaak code aanwezig.

Deze stukjes code zijn nogal resistent, in sommige wysiwyg en andere editors wordt de code niet weergegeven, in andere weer wel, wordt het verschillend weergegeven van lettercombinaties tot Spaanse vraagtekens maar is niet te achterhalen om wat voor code het gaat en is eveneens niet altijd de code te vervangen met een zoek en vervang functie.

Browsers geven de code wel weer maar in een browser window kan je niet editen. Een browser waarin je wel kan editen (Seamonkey gevonden) geeft de code weer niet weer.

Uiteindelijk blijkt een functie in Libre Office het beste te werken.
Te vinden onder "Format", "Clear direct formatting" weet de resistente Apple lijst-opmaak-code te verwijderen.
Er doet zich wel weer een omgekeerd probleem daarna voor.
De opmaak is wel goed te zien in Libre Office maar de opmaak wordt met kopiëren naar het webveld weer niet meegenomen.
Oplossing is na een clear format in Libre Office het document als rtf op te slaan en opnieuw te openen in TextEdit om de tekst vanuit daar te pasten in het webveld.

Extra opmerking
In het genoemde topic was geen bullet code gebruikt maar een lijst code variant van streepjes met een inspringing waarvan de inspringing weer was verwijderd.

Als test hieronder drie opmaak lijst varianten gepasted.
1 vanuit een rtf document, 1 vanuit een plain text document met opmaak afkomstig uit een voormalig rtf document en de laatste serie afkomstig uit een Libre Office Document waarop de "Clear direct formatting" functie is toegepast.


We zullen zien na plaatsing wat het wordt.
Dus waar de ongewenste vraagteken zullen verschijnen.
Hopelijk hebben Mac gebruikers er wat aan.


RTF document lijsten opmaak
________________________________________________

Deze tekst is aangemaakt in een RTF file

Streepjes - (van origine)

? test 1
? test 2
? test 3

Bullets 1 klein • (van origine)

• test 1
• test 2
• test 3

Bullets 2 Groot ? (van origine)

? test 1
? test 2
? test 3

Vinkje ? (van origine)

? test 1
? test 2
? test 3


TXT document lijsten opmaak
________________________________________________

Deze tekst is aangemaakt in een RTF file en daarna gepasted in een plain text document van TextEdit

Streepjes - (van origine)

? test 1
? test 2
? test 3

Bullets 1 klein • (van origine)

• test 1
• test 2
• test 3

Bullets 2 Groot ? (van origine)

? test 1
? test 2
? test 3

Vinkje ? (van origine)

? test 1
? test 2
? test 3


Libre Office document lijsten opmaak met "Clear Direct Formatting Functie" toegepast
________________________________________________

Deze tekst is aangemaakt in een RTF file, gepasted in Libre Office met daarna een 'clear format' eroverheen, opgeslagen als rtf file en weer geopend in TextEdit om vanuit daar in dit veld te pasten (direct vanuit Libre Office na een clear format hier pasten neemt de opmaak niet mee ook al laat het die opmaak wel zien in Libre Office)

Streepjes - (van origine)

? test 1
? test 2
? test 3

Bullets 1 klein • (van origine)

• test 1
• test 2
• test 3

Bullets 2 Groot ? (van origine)

? test 1
? test 2
? test 3

Vinkje ? (van origine)

? test 1
? test 2
? test 3


____________________________________________________________________________


We zullen zien waar het vraagtekenfeest zich gaat manifesteren.

Groet
26-11-2016, 16:53 door Spiff has left the building
Door mcb, 15:04 uur:
Het zou ook handig zijn als de meerdere spaties niet zouden verwijderen.
Erg lastig om iets in tabelvorm weer te geven of idd als bulleted list daar waar extra spaties nodig zijn.
Misschien is het wat off-topic bij de startpost en bij de rest van de thread, maar ik kan je wel wat aanreiken dat je zou kunnen gebruiken:
Non-breaking space, no-break space, non-breakable space (NBSP)
Onder Windows gebruik je daarvoor Alt+255.
Met Apple of Linux gebruik je een andere invoer.
https://en.wikipedia.org/wiki/Non-breaking_space

Simpele weergave van wat je ermee kunt doen:
 één non-breaking space,
  twee,
   drie,
    vier,
     vijf,
enfin, je ziet het.
26-11-2016, 17:02 door Anoniem
nav post van Vandaag, 16:10

TextEdit (Van Apple) in RTF modus zorgt dus desgewenst voor problemen.
Zelfs in combinatie met LibreOffice tussenkomst (maar goed je kan ook direct in Libre Office werken, iets minder licht en minipietsie langzamer dan een licht progje als TextEdit).
Of natuurlijk gewoon zelf je lijstjes opmaken.

Van de diverse programma's die ik nu getest heb om de code uit het tekstdocument te krijgen blijkt een gratis wysiwyg editorretje als Kompozer (beschikbaar voor Win Lin Mac) te werken.
Ze geeft de ongewenste code weer zoals die ook bij een preview in een browser te zien is en laat de code met een zoek vervang functie verwijderen.
Ook de export naar txt werkt goed.

"Kompozer", ziet er aardig uit en is vast ook (zoals bedoeld natuurlijk) handig bij het editen van wat html stuff, mocht je een keer wat te knutselen hebben.

Groet
26-11-2016, 18:08 door [Account Verwijderd] - Bijgewerkt: 26-11-2016, 18:08
[Verwijderd]
26-11-2016, 23:02 door mcb
Door Rinjani: Met \[ code \] tekst \[ /code \] kan je ook misschien iets ......
Dat had ik al eens geprobeerd een tijdje terug. Werkte toen niet.
Nu ook niet trouwens.

Door Spiff:
Non-breaking space, no-break space, non-breakable space (NBSP)
Onder Windows gebruik je daarvoor Alt+255.
... <knip> ...
Simpele weergave van wat je ermee kunt doen:
 één non-breaking space,
  twee,
   drie,
    vier,
     vijf,
enfin, je ziet het.

Even proberen:
  1 spatie
      meerdere spaties

Top    :-)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.