Text 16569, 69 rader
Skriven 2013-05-23 14:34:53 av mark lewis (1:3634/12.71)
  Kommentar till text 16515 av Maurice Kinal (1:261/38.9)
Ärende: curiousity level waning, suspicion level increasing
===========================================================
On Thu, 23 May 2013, Maurice Kinal wrote to mark lewis:

 ml> this is not a fidonet problem

 MK> Not in this specific example but it is indicative of a problem that
 MK> exists with misidentification which will have a detrimental effect
 MK> on the ftn chrs kludge.  I assume that if web authors can't get it
 MK> right then my confidence level - speaking of 'levels' :::snicker:::
 MK> - isn't going to be any higher for the ftn standard crowd given
 MK> their attraction to bogus parameters that have little to nothing to
 MK> do with real world standards, plus the fact that most of them can't
 MK> seem to get their own bogus standards correct, nevermind all the
 MK> obsolenence (IBMPC comes to mind for some strange reason).  ;-)

what it really comes down to is the web page stuff and it needs to be
converting the ftn postings to their stated character set OR they need to be
spitting out their web page in the same character set that the current ftn
message is written...

i've run into the same problem in the past when doing a quickie page for
someone using templates that were hardcoded... there was nothing like a backend
to check the character set content of the server-side included files... it
worked for making the included files available while keeping their desired
theme and that's all that they cared about... just making it work whether it
was technically correct or not was something else altogether...

 ml> it is directly a problem of the coding of the serving system

 MK> In this case I was using it locally.  No web server was harmed in
 MK> this test. 

i thought you showed us something from a russian web server?

 MK> However, now that you bring it up, the resulting successful
 MK> conversion didn't display properly in the local browser until I
 MK> editted the charset to reflect the actual charset.  I also tried a
 MK> simular stategy with a different web page that reported iso-8859-1
 MK> (German) and that one worked without any jiggery-pokery.  The
 MK> misidentified koi8-r when the proper charset was deployed (cp1251)
 MK> had no issues after that and could easily be converted and
 MK> displayed without any issues.

i've run into something similar recently... i pulled some source code for a
project and it had cryllic comments in it... the programming environment i used
to do the conversion from one language dialect to another had no way of
displaying the files with another character set... at least none that i've
found yet... so the cryllic was raw two-byte character sequences... i used
another editor to open those same files... it was telling me the file was in
"UTF-8 without BOM" format but that may have been like your stuff in that if
there is anything over 128 in the file, it assumes UTF-8...

so anyway, i told the second editor to "convert" the file to "ANSI" (the only
logical choice of the offerings" which kept the characters the same... then i
told it to display the file using the "Cryllic Windows-1251" character set...
NOW i could see the proper cryllic characters! i copy'n'pasted them into
google's translator and got them translated to english... at that point, i took
the english and copy'n'pasted it back into the source code comment in place of
the cryllic... when i was finished doing all that, i told the editor to convert
the file back to UTF-8 without BOM like it was when i started... i didn't want
to scrrew anything up in case the original editor was operating in that mode...
saved the file to disk and switched back to the first editor... the first
editor notified me that the file had changed on disk and asked if i wanted to
reload it... yup! now i had the english translated comments and i could move on
to trying to compile the project ;)

)\/(ark

--- FMail/Win32 1.60
 * Origin:  (1:3634/12.71)