Closed (works as designed)
Project:
Import HTML
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
23 Jul 2012 at 02:01 UTC
Updated:
31 Jul 2012 at 23:04 UTC
i will debug this a bit further to see what is breaking down but thought i would mention now in case anyone knows the answer already.
i have a lot of H1s with the odd apostrophe character in them (’) - i am not even sure how to get that from my keyboard; so i simply copied/pasted from the html doc i am trying to import. when it get's imported it shows as � (my browser shows this as a black diamond with a ? inside it).
i use the import_html search/replace feature and tried to replace the ’ with a ' and it does not find anything.
Comments
Comment #1
liquidcms commentedwindows character map seem to think it is a U+02BC: Modifier Letter Apostrophe
i have tried using regex but not sure how to specify this so no luck so far.
Comment #2
liquidcms commenteda little digging in to unicode and seems this should work: /\x{02BC}/u
but fails silently giving:
Processing 1 files for import. Using default configuration settings.
Imported 0 items
Comment #3
liquidcms commentedin the end i simply hacked in this line:
i am sure there is an easier way or else possibly should be a hook here to allow custom precleaning functions?
Comment #4
liquidcms commentedoops, my bad.. there is a hook for this already
Comment #5
dman commentedFunny characters were the bane of my life.
Swithing between 'unknown' encoding then trying to standardize on UTF8 or XML character encoding and then doing it again every time I passed it in and out of the XML DOM and foreign scripts and then trying to make the eventual HTML not horrible to work with in plaintext editors later (with like everything doubtful char-encoded) was a terrible balance to keep.
My tendency was towards html character entity encoding everywhere (which was at least consistent) though I certainly would agree that we can replace ’ with ' rather than its html-entity equivalent. Though type purists disagree strongly.
There is probably a catch-all preprocess routine somewhere with a very small list of obvious replacements that this one (?) could probably be added to. A bunch of common-sense stuff like this is in the heuristics somewhere - though I preferred to expose hooks - like you found - than make best-calls about what is probably expected.
Comment #6
dman commentedThe preprocess hook is indeed the one to use.