#right(){(&counter())} *MacでのUTF-8-MAC問題を解決する方法 このページでは、MacでSubversionを使用するときにぶち当たる問題「[[UTF-8-MAC問題>http://www.google.com/search?client=safari&rls=ja-jp&q=UTF-8-MAC%E5%95%8F%E9%A1%8C&ie=UTF-8&oe=UTF-8]]」を解決する方法について記します。 |BGCOLOR(lightgray):&bold(){NEWS!!} 2009/04/27| |hayatoさんのコメントによると、この問題に対処するパッチが、ついに[[MacPortsでのvariantとして取り込まれた>http://d.hatena.ne.jp/fujisan3776/20081231/1230700127]]とのことです!&br()
過去に、Linuxサーバでファイル共有をしていたときに、Mac側からはNFSで、 Windows側からはSambaでアクセスしていたことがあって、そのときにファイル名の エンコーディングはUTF-8にしていたんですが、どうもファイル名の表示がおかしい、 濁点などが入ると変だということに気づき、調査していたのです。 調査でわかったことは下記のとおり。 MacOSXはUTF-8のファイル名といっても、Normalization Form Dという文字とコードポイントの対応方法をとっている。これにより、濁点のついた文字は2つのコードポイントに分解される。(例:バ→ハ+濁点コードポイント) MacOSXは分解されていない文字列も正しくデコードできる。 WindowsはMacOSXのような変換を行わずにそのまま1文字が1コードポイントに対応するようなUTF-8で保存している。(例:バ→バのま
マルチプラットフォーム&多言語対応したアプリケーションを作る場合に考えないと行けないのが、文字コードです。 で、UTF-8でやろうということになったのですが・・・。 一通り、プロトタイプを作って、いざ、WindowsとMacで動作確認してみると、Macで作った日本語を含むUTF-8をWindowsで使おうとすると・・・。 なんか変。 文字化けしてます。 で、検索してみると、割と有名な話みたいでした。 UTF-8には何種類か符号化の方法があって、一般的にはNormalization Form C(NFC)というものが使われていますが、Mac OSXではNormalization Form D(NFD) が使われています。 ということで、MacのUTF-8な文字データをそのままWindowsへ渡すと、うまく扱う事ができません。 普段は、そもそもWindowsとMacでファイルのやり取りする時は
Q: Unicode 文字列を合成済みの文字の形式に変換する方法はありますか? A: Mac OS X 10.2 で導入された API を使用して、文字列を合成済みの Unicode に変換できます。以下に、合成済みの Unicode と分解された Unicode の違い、なぜ合成済みの Unicode に変換する必要があるのか、および変換方法について説明します。 合成済みの文字と分解された文字 特定の Unicode 文字は、複数の方法でエンコードできます。たとえば、Á(A アキュート)は、U+00C1 (LATIN CAPITAL LETTER A WITH ACUTE) のような合成済みの文字、または U+0041 U+0301(LATIN CAPITAL LETTER A に続く COMBINING ACUTE ACCENT)のような分解された文字のいずれかをエンコードできます。W
eoblogは 2017年3月31日(金)15:00 をもってサービスを終了いたしました。 長年にわたりご愛顧いただき誠にありがとうございました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く