Posted on 01/15/2016 6:41:54 AM PST by reaganaut1
Well, I just screwed up making a post. I was going to eliminate those characters, but out of habit I did not. So, my copy of a posters (just left out the ‘ in “poster’s”) comment looks like this:
âTheyââ¬â¢re not my committee members because Iââ¬â¢m not a republican.â
Habits are hard to change but I will do it.
The truly odd thing is that the issue doesn’t occur on the front page excerpts, only in the actual thread itself. The King of Siam says, “It’s a puzzlement”.
Ok, my mistake. This site is infested with them.
Is FreeRepublic not capable of fixing it? I could fix it for them if they would ask. It’s just a matter - I think - of encoding/decoding characters between database storage and retrieval. I do understand their engine predates PHP which might make it a little more challenging...
It does not matter what OS you have on your PC, laptop, tablet, smartphone; the problem is not on your/our devices it is a translation to html text problem on the FR server for these smart symbols.
That’s what I thought. I was told the FR servers don’t use Windows 10. But it is odd it went nuts when Win10 rolled out.
The website that needs to fix this problem is freerepublic.com. If Jim R. can’t afford a fulltime webmaster, he could at least hire a developer for a couple of hours to fix it.
Volunteer your time. Right?
FR is built on proprietary software, and was well ahead of what Microsoft provided when FR was founded.
But the problem being discussed is an encoding issue that requires some level of software engineering — yet another issue that demands financial support. Times are tough. The quarterly FReepathons are going long. And I’m not complaining, but I’m having a hard time making my quarterly obligations.
Despite the encoding issue, We must keep in mind that there have been no recent performance issues. If I’m not mistaken, FR made a recent capital investment in new equipment to support the demand.
It needn't affect you, either.
The server is broken. That's the root of the problem. But, in the meantime, client-side fixes are possible!
Click my name to get yours!
Nope. Windoze 10 is MS garbage, but it is not responsible for this problem!
There is one and only one true character encoding. That is UTF-8.
But it must be observed end-to-end, religiously.
It's not the smartness of the quotes, (which smart quotes you posted, whether you realized it or not), but the stupidity of a server that second-guesses UTF-8.
As you can see, curly quotes work perfectly well! As long as the server is not configured to interfere with UTF-8.
For a hopefully temporary solution, click my name.
>> There is one and only one true character encoding. That is UTF-8.
Agreed. TCL adopted it early on, and therefore UTF-8 is truth!
But it’s worth pointing out that UTF-8 isn’t necessarily obvious within the byte data excluding the BOM. UTF-16/32 is less ambiguous. But another nice thing about UTF-8 is its intrinsic byte-order independence.
UTF-8 doesn't need a BOM! It's just bytes! The beauty of it is, you can just send bytes, and the result will be perfectly fine ASCII, as long as you don't send anything outside 7-bit ASCII (IOW, confine yourself to straight quotes and hyphens). But, if you want curly quotes and em-dashes, and umlauts and Cyrillic and Chinese and Korean, it all fits into UTF-8. The advanced characters are just sequences of bytes in the 80-FF range. And today's browsers handle UTF-8 just fine! As long as they are not second-guessed by a broken server!
FR pages are all declared to be UTF-8 in their response headers. No need for a BOM (stupid MS concept). Characters are eight bits, except when they are not. That's the beauty of UTF-8! A megabyte of US ASCII is a megabyte long. A megabyte of Cyrillic is two megabytes (hey! they lost the Cold War!). A megabyte of curly quotes and em-dashes is three megabytes of FR teeth gnashing, LOL!
You’re right, I lapsed. The BOM helps to designate byte order — duh...
Still yet, how does one know if the stream is ANSI or UTF-8 until things get weird? At least with UTF-16+, the ANSI stream dies after the first character.
The server informs the browser how the page is encoded via the Content-Type header, e.g.,
Cache-Control:private Connection:close Content-Type:text/html; charset=utf-8 Date:Tue, 19 Jan 2016 16:45:16 GMT Server:nginx/1.2.4 Transfer-Encoding:chunked
There are other possible values for the charset, but UTF-8 is taking over, because it just works.
Agreed. I’m done for the night ;)
The level of software engineering required to fix this is about two (2) hours’ worth of work. You could hire an American developer to do this for a couple hundred bucks, or a foreign freelancer on Upwork to do it for $50.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.