我们有一个应用程序,它将用户输入的文本字符串转换为Web表单并将其打包为XML.只是为了混淆一点,XML就作为Outlook电子邮件的主体发送.
由于用户可以将几乎任何内容粘贴到Web表单中(通常来自Word),因此文本字符串可以包含非ASCII(7位)字符,例如用于打开和关闭双引号的字符.
字符串通过电子邮件完整地传播,但是当我们使用Microsoft XML解析器时,它(非常正确地)抱怨XML包含无效字符.
快速解决方法是在头文件中放置encoding ="iso-8859-1".但是,我想知道在开始时是否更好地以真正的UTF-8格式编码XML文件,因为我读过的文章表明,如果每个XML文档都是用UTF-8编码的,那么对于一个更加和谐的世界会更好. ？
但是......因为XML文档实际上是通过电子邮件正文传输的,所以我们会遇到麻烦吗？我知道UTF-8是一个可变字节长度编码系统,我假设使用7位ASCII和escapte字符来表示"有更多数据".
另一种选择是设置为UTF-8,但用&#nnn;替换非ASCII字符.格式.
对这个相当复杂的领域的任何建议表示赞赏.
干杯,罗布.
这里来自英语以外的地方{1}我可以确认UTF-8在任何地方都可以正常工作,而且已经很多年了.我很难记住,因为当任何MTA通过剥离第8位来削弱电子邮件(导致像QP这样的"发明" (基本上是修复症状而不是解决问题)).这种情况在90年代中期肯定发生,尽管UTF-8迅速普及并取代了iso-8859-1.我不记得我何时换班,但我想至少在2000年之前.
说到iso-8859-1,它将无法涵盖用户的所有可能输入.根据语言的不同,可能需要其他iso-8859变体(例如芬兰语和威尔士语),即便如此,8859系列也不支持中文等语言.另一方面UTF-8应该涵盖一切,所以我强烈建议使用iso-8859-1.
{1}这可能会影响我的经验,因为任何不完全支持UTF-8的程序都会被视为垃圾,而且往往不会在这里使用.
我可能会尝试尽可能使用UTF-8 - 它只是覆盖了更多的地面,并且比ISO-8859-1更灵活,它将扼杀例如东欧角色(尝试在ISO-8859中编写Jiři或类似的东西) 1 - 它会悲惨地失败).
所以,如果你真的想尝试改变(我鼓掌!),那么我会选择UTF-8,如果你真的不能使UTF-8工作,只能回到ISO-8859-1.
渣
| 归档时间： |
|
| 查看次数： |
27920 次 |
| 最近记录： |