Talk:ISO/IEC 8859-1

message: Why does windows-1252 redirect to this page?  1252 is NOT the same as iso-8859-1.
Redirecting references to windows-1252 to this page (I think) reinforces the
mistaken impression that 1252 and 8859-1 are the same (and they are most
definitely not).  Perhaps this deserves an entire page, but Microsoft's
loose labeling of email with (close but not exact) MIME character sets is a BIG problem.
:You're free to make the relevant section a (linked) article of its own. The section however tries to make it clear that although both, CP1252 and Latin-1, are supersets of ISO/IEC 8859-1, they differ in 8x and 9x area. The German version takes a little different approach in emphasizing the differences.
::The advantage of keeping CP-1252 and MacRoman on the ISO-8859-1 page is that differences can be made more clear. And Windows (and IIS) misreports CP-1252 as ISO-8859-1 by default, so most people falsely assume CP-1252 *is* ISO-8859-1. Latin-1 of course is a valid implementation of ISO 8859-1, as it is nothing but an alias for ISO-8859-1. Jor 13:24, 12 Mar 2004 (UTC)
replies: text: Latin-1 of course is a valid implementation of ISO 8859-1, as it is nothing but an alias for ISO-8859-1. Wrong. ISO/IEC 8859-1 (the standard) only specifies the characters for the 20-7E and A0-FF byte ranges. The characters for bytes 00-1F and 7F-9F are left undefined. The ISO-8859-1 character map registered with the IANA fills the missing spots with the C0 and C1 control sets (defined elsewhere), thus covering 00-FF. This map's approved aliases are: ISO_8859-1:1987, iso-ir-100, ISO_8859-1, ISO-8859-1 (preferred MIME name), latin1, l1, IBM819, CP819, and csISOLatin1. - mjb 22:07, 12 Mar 2004 (UTC)
replies: text: So remove the dash. Latin1 *is* a valid alias for ISO-8859-1, which is an encoding based on ISO 8859-1. Jor 22:17, 12 Mar 2004 (UTC)
replies: text: like it or not in the internet world now ISO-8859-1 is always interpreted as windows-1252. stuff from windows-1252 was being used by editors here with no reported problems all the time before the switch to utf-8. Sometimes you just have to accept that formal standards and reality aren't the same thing. Plugwash 6 July 2005 10:53 (UTC)
"However, the draft HTML 5 specification requires that documents advertised as ISO-8859-1 actually be parsed with the Windows-1252 encoding."
The citation does not make any indication of whether or not this statement is true. 194.232.128.102 (talk) 14:47, 11 September 2009 (UTC)

text: The current HTML5 draft does mention it insection 8.2.2.2 . Of course these things are subject to change at any time. Plugwash (talk) 17:07, 30 January 2012 (UTC)

text: More than a year on, the current HTML5 draft still does not mention it. I feel it is unlikely to change back. As it stands this sentence has been promoting wrong information to everyone who did not check the references for over a year. I recommend removing or at least rewording this sentence to show that it is no longer true. Greatrsg (talk) 09:20, 3 July 2013 (UTC)
thread_title: windows-1252

message: I'm having a hard time finding what year Microsoft introduced code page 1252. I'm particularly interested in MS's support for the curved apostrophe and quotation marks ‘ ’ “ ”. The best I could find so far was "around 1986". — Hippietrail 01:41, 22 July 2005 (UTC)
replies: text: my guess is it came in with the windows concept of ansi code pages. I don't know how far back that dates though (p.s. i notice that whatever font is used for standard wikipedia text doesn't seem to differentiate between the opening and closing quotes but the font i see in the edit box does). Plugwash 02:09, 22 July 2005 (UTC)

text: Minor point of interest is that the IANA did not accept Windows-1252 in its charset registry until early 2000, based on a proposal made in December 1999. The other Windows-125x code pages were accepted by the IANA in 1996 after being proposed by someone at Microsoft's Russian branch. — mjb 03:00, 23 December 2005 (UTC)
replies: text: And windows-874 still isn't in the IANAs list despite being actively used by at least outlook 2000, i pointed this out to the iana-charsets list but they didn't seem to care. Plugwash 08:46, 7 October 2006 (UTC)
thread_title:  History of CP1252 

message: In the table in the section "Related character maps", at position (-4, 8-) in the table, the table links to the disambiguation page for index (It says "IND"). This shouldn't happen. However, I have abolutely no idea what kind of index it's referring to, so I didn't change it. Could somebody who knows more about this please change it to link to the specific type of index that it refers to? E946 04:59, 6 April 2006 (UTC)
thread_title:   Related character maps- link to a disambiguation page 

message: In the character chart, both the character | (value 7C) and the character ¦ (value A6) linked to the article about Pipe_(computing); but as far as I can see, that article only talks about the character | (7C).
I have changed both links to Vertical bar, which I believe gives more relevant information.
--Oz1cz 14:57, 10 November 2006 (UTC)
thread_title:  The two pipe symbols 

message: Why is there no encoding for "line feed / new line" in this standard? How does that work?
83.118.38.37 09:06, 9 February 2007 (UTC)
replies: text: There are control characters from 00 to 1F designed for functions like this. 2A01:119F:21D:7900:E56A:6E91:A341:16E1 (talk) 18:49, 29 October 2018 (UTC)
thread_title: Line Feed / Newline

message: I think someone of knowledge in this field should write a section with that name.
OK, the background: I installed a server software distro (Apache2Triad) and everything was working just fine and so I copied some folder with webpages in it I had on another server (XAMPP) and to my shock and appallment this thing was displaying letters with diacritics like all those crappy sites from 1990's, that I've noticed are not even capable of displaying apostrophes on pages in English.
And I've noticed a coincidence of pages not being able to display apostrophes (nor any diacritics) and the page having a charset like ISO 123456 or something (instead of UTF-8) in its HEAD section.
And yeah, when I changed the line specifying ISO 8859-1 to UTF-8 (in the httpd.conf file) I got all my diacritics (namely, Latvian) and nothing appears to have been broken.
So, basically, why would anyone need a charset like this when there's UTF-8, what are the inclusion criteria for languages (lol), it's not that I would have any issues with a charset not displaying Latvian diacritics, but there are carons (š) in Czech, for instance, and macrons (ā) in Japanese rōmaji script, and those are like legit languages (not to mention the apostrophes) so, basically, the article seriously lacks some rationale section as to why would anyone use this encoding.
354d 22:05, 26 September 2007 (UTC)
thread_title:  ISO 8859-1 vs. UTF-8 

message: I removed the use of a "0x" prefix on hexadecimal character codes, because it appears that typically in these character set articles the decimal values are predominantly used, and when hexadecimal values are used they are labeled as such (e.g., "hex 80"). The use of the "0x" prefix is not universally recognized as implying hexaecimal, in spite of widespread use of C-like programming languages. In ISO and RFC documents for character sets, in fact, either decimal only is used (e.g., "128"), or a "row/column" notation (e.g., "8/0") is used. — Loadmaster (talk) 04:40, 7 October 2010 (UTC)
thread_title:  Hexadecimal character codes 

message: The explanation on Dutch language support is utter nonsense. The very existence of the mentioned Ĳ/ĳ as separate symbol is barely even known to Dutch-speaking people. The symbol doesn't even appear on Dutch or Belgian keyboards. As far as I can see, ISO/IEC 8859-1 supports the Dutch language completely.  — Preceding unsigned comment added by Nyerguds (talk • contribs) 07:34, 1 July 2011 (UTC)
replies: text: It was taught to us as a separate symbol in primary school. We called it de lange ij. We all type it as I + J but we also all know that this isn't perfect and that software's ability to convert it into the proper glyph can leave a lot to be desired.  — Preceding unsigned comment added by 82.139.87.39 (talk) 23:42, 27 January 2012 (UTC)

text: The same goes for Czech (and Slovak) ch. It is one character for purposes of sorting for example (between H and I), but it is written by two letters. Ceplm (talk) 14:41, 9 January 2014 (UTC)
replies: text: You can't even see the difference between ĳ and ij. You have to select it to see the difference, and you barely save memory if you use it. Maybe there are some fonts in which ij would look better as a separate symbol, but otherwise it's useless. 80.101.107.21 (talk) 16:03, 23 April 2012 (UTC)
replies: text: FWIW (if anything, now many years later), I could clearly see the difference between ĳ and ij in your sentence above, even before selecting them. It was a surprise, though, that the former was the ligature (if that's the correct term?), because the visual distance between its parts was longer than in the following ij digraph. I would have assumed the single-character version would bring them closer together -- that this was pretty much the whole purpose of its existence -- but at least the default font my browser displays Wikipedia in has tighter kerning between the separate characters than the combined one. Life is full of little surprises... (And yes, given the discussion in some sections higher up on this page, the irony of my double hyphens for em-dash here is not lost on me.)--CRConrad (talk) 16:12, 11 August 2021 (UTC)

text: Whether it saves memory or looks better is completely beside the point. There is a world of difference between what we commonly type and what would be "correct" if computers only supported it. Example: Today most people use a single "-" to mean either figure dash, en dash, em dash and so on, because all that ASCII / ISO-8859 supports is "-". That doesn't make it "right", and I seriously doubt a typographic system like TeX would drop "all those useless dashes" any time soon. -- DevSolar (talk) 10:03, 22 June 2012 (UTC)

text: As a dutch person, I concur for OP. We're only taught to write the 'lange ij' in one space for writing in 'blokletters', and as mentioned, because it sometimes looks better. The latter can also be argued by the ligature ﬁ which looks better than fi when looked close-up in times-new-roman-style fonts, yet I've only seen real typesetting software (like LaTeX) actually converting fi to ﬁ when printing/exporting. The ligature ĳ is only of historical interest and for vertical writing. The only places I encounter it in daily life is where it's incorporated in logos or markings which are vector-designed (like http://www.jacktummers.nl/wp-content/uploads/200907/lijnbus.jpg or http://www.wingene.be/_STUDIOEMMA_WWW/uploads/Image/DuurzaamheidGisEnMobiliteit/DeLijn_kleur_logo.jpg). Furthermore we have many other digraphs/Diphthongues, (ou, ei, ie, oe, ui, au) and they aren't written with a ligature or in a single space, because, what do you know, it just happens those can't be placed inside each other. --Zom-B (talk) 10:28, 6 August 2013 (UTC)
thread_title:  Dutch language support 

message: It looks like the article doesn't mention Polish language: not in the section on fully supported languages, and not in the section on languages with partial support.165.225.72.120 (talk) 11:18, 15 December 2017 (UTC)
thread_title:  Polish language support 

message: I don't know Romanian very well so I won't edit it, but a work-around for ș (S-comma) is "sh" in ASCII and a work-around for ț (T-comma) is "ts" in ASCII. The Romanians I know live in an English-speaking country, and this is a very English-influenced work-around, so it may be horrific inside Romania, I don't know. Fluoborate (talk) 11:26, 22 December 2017 (UTC)
thread_title:  Romanian language support / work-arounds 

message: Page " ISO/IEC_8859-1 "
Hi,
i am sorry for my bad english language skills.
 
The colors shown for F6 is not
the same in the chart and the legend box
because that is a typo in Color Code string, i think.
"FFEFAF" (Colored Square) is used when with "Graphic character" and i read
it wrong when moving to the Chart through misleading, maybe it's is a failure.
Cya  — Preceding unsigned comment added by 93.82.108.221 (talk) 10:16, 6 July 2018 (UTC)
thread_title:  Wrong Color in chset-color-intl - F6 

message: I removed the claim: "It is also commonly used in most standard romanizations of East-Asian languages."  It is not true in any obvious reasonable sense: first, "it" refers to the encoding scheme used for data transfer, and the amount of data transfer occurring in Romanised East-Asian languages must be truly negligible. If it meant to refer to the IEC's selection of roman letters, whatever they call it, then it is false, because for example Japanese needs macronned vowels, which are not included. Imaginatorium (talk) 02:15, 31 December 2020 (UTC)
thread_title:  "Romanised East-Asian languages" 

message: The redirect IsO-8859-1 has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached.  Utopes (talk / cont) 08:34, 6 December 2023 (UTC)
thread_title:  "[[:IsO-8859-1]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]]