タグ

Unicodeに関するaufhebenのブックマーク (8)

  • IVS本へのツッコミ・まとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ

    『Unicode IVS/IVD入門』(田丸健三郎、小林龍生)の非公式正誤表のようなもの*1。第1章と第2章はWindows 8の話なので、見ていない箇所もある。間違いの量に興味がある方は、最初から読まずに、第4章(時系列的にはこれが最初のエントリ)あたりからどうぞ。 IVSへのツッコミ 第2章までへのツッコミ 第2章番外編「先生怒らないからリュウミンは手を挙げなさい」 第3章へのツッコミ 第4章へのツッコミ 第5章へのツッコミ 第5章番外編「この「邉」を作ったのは誰だぁ!!」 巻末付録の文字コード表へのツッコミ 関連するかもしれないエントリ セミナーでMicrosoftの人に質問するためのアンチョコ IVSアドインをインストールしてみたよ *1:さまざまな人からの情報をベースにしています。個々にお名前を挙げることはしませんが、皆さんありがとうございます!

    IVS本へのツッコミ・まとめ - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
  • IVS本に容赦なく突っ込みまくるNAOIさん

    発行されたばかりの「Unicode IVS/IVD入門(日経BP社)」に突っ込むNAOIさん。誤植どころか「これ校正校閲してないんじゃないの?」と疑われるような間違いが続々と…

    IVS本に容赦なく突っ込みまくるNAOIさん
  • 西村賢さんのPython内部文字コードの話題から端を発するUnicodeの話

    K.Takata @k_takata 「Unicode文字列型が複数の内部表現をサポート」ってどういうこと?「Python 2系からの移植を容易にするため…Unicodeリテラルシンタックスも復活」これは良い。 http://t.co/LxkUP45x 2012-03-06 21:44:00

    西村賢さんのPython内部文字コードの話題から端を発するUnicodeの話
  • やっかいな漢字 – CJK部首補助/康煕部首 – ものかの

    DTP制作向けのテキスト整形の話です(楽しい文字沼)。 CJK部首補助や康煕部首の漢字は、とてもやっかいです。なにがやっかいかというと、見た目では通常の漢字と区別ができないことです。 文字コードが違うのにどうして見た目がこれほど同じなのかというと、フォントの同じグリフが表示されているからです。 クライアントから支給された文字原稿に、もしかするとこのやっかいな漢字が混入しているかもしれません。なぜかというと、PDFから文字をコピーすると、通常の漢字だったはずなのに、なぜかやっかいな漢字に変わってしまうことがあるからです。このごろは文字原稿の作成にPDFから文字をコピー&ペーストすることが普通に行われているので、やっかいな漢字の混入は日常茶飯事といってよいかもしれません。 クライアントからPDFを支給されたときも、DTP制作者がPDFから文字をコピー&ペーストして、気づかずにやっかいな漢字を混

    やっかいな漢字 – CJK部首補助/康煕部首 – ものかの
  • yasuokaの日記: WAVE DASH問題縁起

    Encode - 規格のバグまでは直せませんにコメントしながら思ったのだが、JIS X 0208の1区33点「波ダッシュ」をUnicodeに変換する際、U+FF5EのFULLWIDTH TILDEに変換するのは明らかに間違いだ。この件に関して、私が知る限りのことを、ここに記しておこうと思う。 平成5年度のUCS調査研究委員会WG1において問題となったものの一つが、既存のJISの文字コードとISO/IEC 10646との対応をどうするかだった。JIS X 0208-1990の1区33点「波ダッシュ」に対しては、U+223C、U+223D、U+223E、U+223F、U+301Cが候補となったが、結局U+301Cと対応させることとなった。U+301Cの名前がWAVE DASHだったからである。ただし、ISO/IEC 10646-1:1993のU+301Cの例示字形は、JIS X 0208の「波

    aufheben
    aufheben 2021/06/28
    波ダッシュ問題
  • BOMなしUTF-8によってWindowsでもたらされる困惑 (1/2)

    かつてWindowsでテキストファイルといえばシフトJIS形式のものが大半だった。しかし最近では、UTF-8形式のテキストファイルも普通に見かけるようになってきた。世の中はUTF-8が主流になりつつあると言っていいだろう。 しかし、WindowsUTF-8を使うと、ちょっと困ったことがある。それは、エクスプローラーの検索欄などで用いるWindows Searchが、UTF-8にはしっかり対応していないのである。正確に言うと、Windows Searchはファイル先頭に「BOM」のあるUTF-8は認識して正確にインデックス化し、ファイルの全文検索が可能になるが、BOMのないUTF-8では正しくインデックス化できず、ファイルの全文検索はASCIIコードのみ可能で、日語などの非ASCII文字では全文検索ができない。 同じ内容のテキストをUTF-8UTF-8 BOM付き、UTF-16ビッグエ

    BOMなしUTF-8によってWindowsでもたらされる困惑 (1/2)
  • 使いこなそうユニコード

    UCSとUTFとは? [2003-11-11] Unicode正規化とは [2008-01-14] Unicodeに関するメモ [2002-06-15] JIS X 0213とUCS/Unicodeとの対応について [2006-12-30] JIS/SHIFTJISとWINDOWS/CP932との相違 [2001-07-08] JIS X 0208とUnicodeとの対応表/ZIP版 [2002-06-01] Shift_JIS-2004 (JIS X 0213:2004)とUnicode 3.2.0の対応表/ZIP版 [2007-01-03] ・JIS X 0213:2000 + 正誤票:2001 + 追補1:2004 + 正誤票:2004より作成。 この節は、Unicode Consortium が公開している文書等へのポインタです。そのリンク先の内容は、Unicode Consort

  • Unicode正規化 用語の混乱について 第4.2版 – ものかの

    初版 2010/4/5 第2版 2013/5/10 誤解を修正。全面的に書き直し。 第3版 2014/7/13 なるべく分かりやすく全面的に書き直し。 第4版 2015/5/20 さらに分かりやすく全面的に書き直し。 第4.1版 2015/5/27 まだ分かりにくいと不評なので書き直し。 第4.2版 2015/5/27 さらに分かりやすく調整。 Unicode正規化の考え方自体はとてもシンプルです。でも、よく知ろうとしていろいろ調べると、用語がハイコンテキストすぎて、混乱してワケがわからなくなります。日で一般的に見られる用語を図にしてみましょう。 混乱するのはどこだと思いますか? “合成済み文字” と “合成文字” の2か所です。どちらも言葉として同じ意味です。それなのに、異なった状態を表す用語として無理矢理に使い分けようとしています。ここから、以下のような奇妙な文章ができあがります。

    Unicode正規化 用語の混乱について 第4.2版 – ものかの
  • 1