802 2004-06-16 13:54:38 +0000 double utf-8 bom yields in encoding errors in Validation result 2005-08-18 03:19:59 +0000 1 1 1 Unclassified Validator check 0.6.7 Other other RESOLVED FIXED http://validator.w3.org/check?uri=http%3A%2F%2Fwww.websitedev.de%2Fmarkup%2Fvalidator%2Ftests%2Fdouble-utf-8-bom.html P2 normal --- 1 bjoern link www-validator-cvs oldest_to_newest 2023 0 bjoern 2004-06-16 13:54:38 +0000 http://validator.w3.org/check?uri=http%3A%2F%2Fwww.websitedev.de%2Fmarkup% 2Fvalidator%2Ftests%2Fdouble-utf-8-bom.html Is invalid, http://validator.w3.org/check?uri=http%3A%2F%2Fvalidator.w3.org%2Fcheck%3Furi% 3Dhttp%253A%252F%252Fwww.websitedev.de%252Fmarkup%252Fvalidator%252Ftests% 252Fdouble-utf-8-bom.html Sorry, I am unable to validate this document because on line 172 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication. 2250 1 bjoern 2004-09-06 21:13:12 +0000 This is probably a duplicate of the bug that deals with using the UTF-8 flag for truncate_line() etc. 2255 2 ville.skytta 2004-09-06 21:33:14 +0000 Offtopic, but BOM related: this might be interesting sometime: http://search.cpan.org/dist/File-BOM/ 2328 3 link 2004-09-11 13:15:29 +0000 One way to deal with this is to pass our complete output data through the UTF-8 checker (charlint), possibly modified to tag illegal byte sequences and continue instead of croaking. BTW, cf. Comment #1, I can't seem to find this bug you're refering to; care to provide a bug number? 2334 4 bjoern 2004-09-11 23:08:39 +0000 See the relevant comment in the source about Perl 5.8.x --- and I am not sure how your suggestion would help. The problem here is that the string is considered a byte string and thus substr etc. do not work as expected. 5432 5 bjoern 2005-08-18 03:19:59 +0000 Fixed in HEAD.