This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author doerwalter
Recipients Rhamphoryncus, doerwalter, ggenellina, gvanrossum, jgsack
Date 2007-11-15.13:41:57
SpamBayes Score 0.04176378
Marked as misclassified No
Message-id <1195134117.81.0.711584209767.issue1328@psf.upfronthosting.co.za>
In-reply-to
Content
> For utf16, (arguably) a missing BOM should merely assume machian
endianess.
> For utf_16_le, utf_16_be input, both should accept & discard a BOM.
> On output, I'm not sure; maybe all should write a BOM unless passed a flag
> signifying no bom?
> Or to preserve backward compat, could have a parm write_bom defaulting to
> True for utf16 and False for utf_16_le and utf_16_be. This is a 
> modification of the originial request (for a force_bom flag).

The Unicode FAQ (http://unicode.org/faq/utf_bom.html#28) clearly states:

"""
Q: How I should deal with BOMs?
[...]
Where the precise type of the data stream is known (e.g. Unicode
big-endian or Unicode little-endian), the BOM should not be used. In
particular, whenever a data stream is declared to be UTF-16BE, UTF-16LE,
UTF-32BE or UTF-32LE a BOM *must* not be used. [...]
History
Date User Action Args
2007-11-15 13:41:57doerwaltersetspambayes_score: 0.0417638 -> 0.04176378
recipients: + doerwalter, gvanrossum, jgsack, ggenellina, Rhamphoryncus
2007-11-15 13:41:57doerwaltersetspambayes_score: 0.0417638 -> 0.0417638
messageid: <1195134117.81.0.711584209767.issue1328@psf.upfronthosting.co.za>
2007-11-15 13:41:57doerwalterlinkissue1328 messages
2007-11-15 13:41:57doerwaltercreate