<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>netatalkをCJKパッチ付きでインストール へのコメント</title>
	<atom:link href="http://blog.chibiegg.net/2008/03/18_23_132.htm/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.chibiegg.net/2008/03/18_23_132.htm</link>
	<description>chibiegg’s Diary</description>
	<lastBuildDate>Thu, 12 Aug 2010 14:46:45 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>HAT より</title>
		<link>http://blog.chibiegg.net/2008/03/18_23_132.htm/comment-page-1#comment-237</link>
		<dc:creator>HAT</dc:creator>
		<pubDate>Thu, 20 Mar 2008 13:02:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.chibiegg.net/2008/03/18_23_132.htm#comment-237</guid>
		<description>ついでに書くと、NFSなんかもcomposeの変換が行なわれないので問題が出ます。</description>
		<content:encoded><![CDATA[<p>ついでに書くと、NFSなんかもcomposeの変換が行なわれないので問題が出ます。</p>
]]></content:encoded>
	</item>
	<item>
		<title>HAT より</title>
		<link>http://blog.chibiegg.net/2008/03/18_23_132.htm/comment-page-1#comment-236</link>
		<dc:creator>HAT</dc:creator>
		<pubDate>Thu, 20 Mar 2008 13:01:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.chibiegg.net/2008/03/18_23_132.htm#comment-236</guid>
		<description>それはたぶんcomposeの問題でしょう。
iTunesのデータということは、曲名がそのままファイル名になっているでしょうから、non-ASCIIの文字を含んでいるんじゃないですか?
ファイル名に濁点、半濁点、アクセント付きアルファベット、ハングルとかが含まれていて、そういうファイルだけで問題が出ていませんか。
MacOSXでのdecompose/precomposeの変換はCoreFoundationなるレイヤが行なっています。GUI系ソフトを使った場合はこのCoreFoundationを使うので大抵正常に変換が行なわれます。UNIX系のソフトの場合はCoreFoundationを使わないので、特にcomposeを意識したソースになっていなければ、decompose/composeの変換が行なわれません。
たぶんrsync+sshでは変換が行なわれていないので、UNIX側にdecomposed UTF8のままファイル名が保存されているのだと思います。
パッチなしnetatalk2.0.3の場合、composeの変換が中途半端ながら実装されており、「が」のような文字は変換されるので、UNIX側でprecomposed UTF8になります。このような文字がdecomposed UTF8で保存されていると、netatalk経由で正常に扱えないことになります。パッチありnetatalk2.0.3だとcomposeの変換がほぼ完全になるのでハングルとかギリシャ拡張文字等でも正常に扱えます。
rsyncをafp経由で使う場合、パッチなしnetatalk2.0.3で問題が出るのは私のページに書いてある通りです。パッチありなら問題なく使える筈です。</description>
		<content:encoded><![CDATA[<p>それはたぶんcomposeの問題でしょう。<br />
iTunesのデータということは、曲名がそのままファイル名になっているでしょうから、non-ASCIIの文字を含んでいるんじゃないですか?<br />
ファイル名に濁点、半濁点、アクセント付きアルファベット、ハングルとかが含まれていて、そういうファイルだけで問題が出ていませんか。<br />
MacOSXでのdecompose/precomposeの変換はCoreFoundationなるレイヤが行なっています。GUI系ソフトを使った場合はこのCoreFoundationを使うので大抵正常に変換が行なわれます。UNIX系のソフトの場合はCoreFoundationを使わないので、特にcomposeを意識したソースになっていなければ、decompose/composeの変換が行なわれません。<br />
たぶんrsync+sshでは変換が行なわれていないので、UNIX側にdecomposed UTF8のままファイル名が保存されているのだと思います。<br />
パッチなしnetatalk2.0.3の場合、composeの変換が中途半端ながら実装されており、「が」のような文字は変換されるので、UNIX側でprecomposed UTF8になります。このような文字がdecomposed UTF8で保存されていると、netatalk経由で正常に扱えないことになります。パッチありnetatalk2.0.3だとcomposeの変換がほぼ完全になるのでハングルとかギリシャ拡張文字等でも正常に扱えます。<br />
rsyncをafp経由で使う場合、パッチなしnetatalk2.0.3で問題が出るのは私のページに書いてある通りです。パッチありなら問題なく使える筈です。</p>
]]></content:encoded>
	</item>
</channel>
</rss>
