使用不同编辑器保存时的不同解析行为
标题描述了我的问题。 我用 php 解析一个文本文件。 此文件包含 Google 日历供稿的网址
http://www .google.com/calendar/feeds/example%40googlemail.com/public/full
当我使用 mac textedit 保存此文件时，我会像这样访问提要信息
$doc = new DOMDocument();
$doc->load( $feed );
，然后一切都很好。 但是当我在linux或mac上用vim保存它时，加载的url是
http://www.google.com/calendar/feeds/example%2540googlemail.com/public/full%0A
请注意，百分号已转换为： % ->; %25 和带有此 url 的 %0A 行尾
，我在访问提要信息时收到错误，因为 url 错误。 用vim保存文本文件有什么问题？编码？
问候， 彼得
the title describes my problem.
i parse a text file with php.
this file contains an url to a google calendar feed
http://www.google.com/calendar/feeds/example%40googlemail.com/public/full
i access the feed information like this
$doc = new DOMDocument();
$doc->load( $feed );
when i save this file with the mac textedit, then everthing is fine.
but when i save it with vim on linux or mac, then the url which gets loaded is
http://www.google.com/calendar/feeds/example%2540googlemail.com/public/full%0A
note that the percentage sign gets transformed to: % -> %25 and a lineending to %0A
with this url i get an error when accessing the feed information, because the url is wrong.
what is the problem with saving a text file with vim? encoding?
regards,
peter
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
%0A是换行符的编码。换句话说，不同编辑器中的行结尾是不同的（TextEdit 的回车符，vim 的换行符）。如果你想让 vim 写出 CR 行结尾，请使用以下命令：
%0Ais the encoding of a linefeed character. In other words, your line endings are different in different editors (carriage return for TextEdit, linefeed for vim).If you want vim to write out CR line endings, use the following command:
php.ini 中应该有一个参数“auto_detect_line_endings”，通常设置为“Off”。改一下，应该就可以解决问题了。
如果这对您来说不可行，那么您可以在加载输入文档后清除任何不需要的字符。 php 函数 str_replace() 比正则表达式执行此操作要快一些，因此我会针对您的情况推荐它：
我确信 DOM/LIBXML 库中的某处有更有效的解决方案，但我还没有研究过它。
There should be a parameter "auto_detect_line_endings" in your php.ini which is normally set to "Off". Changing it, should solve the problem in place.
If this is not feasible for you, then you could clean-up any unwanted characters after loading you input doc. The php function str_replace() does this a bit faster than a regular expression, so I'd recommend it for your case:
I'm sure there is a more efficient solution somewhere in the DOM/LIBXML library, but I haven't investigated it.