Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は下記のtweetから始まるスレッドに触発され、@qnighyや@na4zagin3からアイディアを拝借して書いた。 i18n力が最強の国は国内に複数の言語があり、そのうちいくつかは他国でも使われている言語の方言で、1バイト文字での代替表記が困難で、歴史的にISO-2022ベースの文字コードとUnicodeと独自エンコーディングが混在していて、フリガナなどの特殊な組版規則があり、右書き左書き縦書きを併用し、 — Masaki Hara (@qnighy) 2018年8月6日 皆さんのおかげで最強のi18n国家が建設されつつある。一
Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
前回からの続き。 改行コードの違いを体感してみる - ザリガニが見ていた...。 文字エンコードとロケールを体感する - ザリガニが見ていた...。 改行コードの違いも知った。文字コードとロケール、ターミナルの言語環境との関係も知った。これで文字にまつわる悩みとはおさらばできると思ったら、まだダメだった...。 実験環境 OSX 10.8 Mountain Lion以前((OSX 10.9 Mavericksでは、Mac仕様なNFDのUTF-8を表示しようとするとエラーになってしまったため、10.8以前の環境で実験した。Assertion failed: (width > 0), function conv_c, file /SourceCache/shell_cmds/shell_cmds-175/hexdump/conv.c, line 137. ** ** Abort trap: 6
長らく更新の止まっている「いいから俺文字コード」シリーズですが、 このたび、Java Advent Calendarの一環として復活させました！ Java Advent Calendarって？ 本エントリーはJava Advent Calendarの5日目です。 Java Advent Calendarについては、以下のサイトをご覧ください。 http://atnd.org/events/22434 前の4日目は @akirakoyasu さんの「SDKで身近になるAmazon Web Service」 http://www.akirakoyasu.net/2011/12/04/easily-use-aws-through-sdk/ S3、SimpleDB、SESの使い方をサンプルコードつきで紹介しています。 次の6日目は @shuji_w6e さんの「JUnit のセカイ」 http:/
情報交換でよく問題になる「厄介な漢字」は、流行のスマートフォンではどのように表示されるのだろう？ これを明らかにするため、公募による実験を試みた。具体的には、実施者が問題になる文字を選定、 ツイッターにて送出、そのツィートのスクリーンショットをスマートフォンのオーナーに送ってくれるよう呼びかけた。 スマートフォン以外からの応募もあったので併せて掲載する。当日の詳細なやり取りは 「文字化けの饗宴：スマートフォンにおける厄介な文字の表示実験」を参照されたい。 実施日は2011年6月21日、実施者は小形克宏である。 送出した漢字の内訳 0面以外にある常用漢字…… 𠮟（U+20B9F） その他の0面以外の文字…… 𠮷（U+20BB7） UnicodeにあるがJIS X 0213にない字…… 髙（U+9AD9） IBM拡張文字…… 神（U+FA19） IBM拡張文字ではないJIS X
「プログラマのための文字コード技術入門」を読んで自分なりに理解した点をザックリとまとめてみる。 それほど正確性を求めて書いているわけではないので、間違ってる可能性大です。 間違いなどあればコメントなど頂けるとありがたいです。 それぞれの文字コードはどう違うのか？ 日本語の文字コードは大きく以下の２つに分けられる JIS X 0208 文字集合をベースにしたもの Unicode文字集合をベースにしたもの JIS X 0208 文字集合をベースにした文字コードには、EUC-JP, Shift_JIS, ISO-2022-JP がある。 Unicode文字集合をベースにした文字コードには、UTF-8, UTF-16 などがある。 上で挙げた「文字コード」とは正確には「エンコーディング（文字符号化方式）」の事を指す。 文字符号化方式 文字集合って？ 読んでそのまんま”文字の種類の集まり”。「キャラ
はじめに Windows VistaのJIS2004対応により、WindowsのUnicode環境で使用できる日本語漢字の数が増えました。従来、12238字（Windows XP）だったのが13145字（Windows Vista）になり、907字追加されることになりました。これによって、JIS第3水準、JIS第4水準の漢字がすべてサポートされることになったのです（Windows XPまでは一部サポート）。 またWindows XPでも、パッチさえ当てれば、Windows Vistaと同じように追加907字を加えた13145字の漢字が使用できるようになりました。 ところが、この追加された907字の中には「サロゲートペア」という特殊な文字が304字あり、これらは今までのUnicodeの文字とは扱いが少し違います。この点について解説していきたいと思います。 対象読者 Unicodeでデータ処理
Pythonにはじめて触って、いつのまにか1年が過ぎたのですが、一番はまったのは、やっぱりunicodeの扱いだったと思います。 特に、 UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-12: ordinal not in range(128) のようなエラーにはさんざん悩まされました。ここがたとえばrubyなど他の言語と比べてわかりにくいために、Pythonが取っつきにくい言語になっているのではないか、と個人的には思います。 そこで、このエラーに関係するはまりどころとTipsをいくつか列挙してみました。これからPythonに触れられる方の参考になればと思います。 なお、環境はUNIX上のPython 2.4, 2.5を想定しています。 u1はunicode型で、s1はstr型です。s1にどのよ
_ 円まーく https://bugs.webkit.org/show_bug.cgi?id=24906 これが一見ややこしそうだけど一見以上にややこしくて困る。 たまに頭がおかしくなるのでまとめておこうと思う。 表示 バックスラッシュは Windows でかつ EUC-JP や Shift_JIS など、要は日本語エンコーディングのサイトだと、日本語フォントが使われるため、バックスラッシュが円マークに見えている。あと、日本語フォントが明示的に指定されていればやはり当然円マークに見える。 Apple の人はそれらは円マークとして表示したいと主張している。 僕の個人的な感覚ではこんなことはやらんでいいと思う。がまぁ理解はできる。 ここを認めるせいでややこしくなるわけだけど。 表示する文字列は RenderText とかいうクラスの中に変換された状態で保存されてて、まぁオリジナルの文字列は D
struct FSSpec { short vRefNum; long parID; StrFileName name; /* 63ビット文字列 */ }; struct FSRef { UInt8 hidden[80]; /* File Manager のプライベート変数 */ }; おそらく、コードに最も大きな影響を与える相違点としては、FSRef は存在しない項目を表現できないことと、80 バイトの配列として定義されていますが、その内容が明文化されていない不透過なデータ構造体であるということです。特に FSRef は、それが参照している項目の名前を保持していません。Mac OS X が最大 255 文字の UniChar からなる、Unicode 文字のファイル名を使用できることを考えれば、不思議なことではありません（詳しくは「FSRef と Unicode のロングファイル名」を参
Unicode の文字列をソースコードに埋め込む方法 Unicode の文字列をソースコードに埋め込む場合、直接 UTF-8 などで文字列を書く方法と、\uXXXX などのようにエスケープして表記する方法があります。後者の方法についてまとめてみました。 \uXXXX 形式の場合 Java, JavaScript, Python, C++, C (C99から) などの多くの言語では \uXXXX という表記 (universal character names) でUnicode の文字を文字列の中に埋め込めます。たとえば、「あいう」は "\u3042\u3044\u3046" となります。 \uXXXX で埋め込んだ文字がどのように解釈されるかは言語や処理系によって異なります。 gcc/g++ の場合、 -fexec-charset オプションで、実際に使う文字セット・エンコーディングを指
Unicode（ユニコード）は、符号化文字集合や文字符号化方式などを定めた、文字コードの業界標準規格。文字集合（文字セット）が単一の大規模文字セットであること（「Uni」という名はそれに由来する）などが特徴である。 従来、各国の標準化団体あるいは各コンピュータメーカーによって独自に開発されていた個々の文字コードの間には互換性がなかった[1]。ISO/IEC 2022のように複数の文字コードを共存させる方法も考案されたが、例えば日本語の漢字と中国語の漢字のように、文字が重複する短所がある。一方Unicodeは、微細な差異はあっても本質的に同じ文字であれば一つの番号を当てる方針で各国・各社の文字コードの統合を図った規格である[1]。1980年代に、Starワークステーションの日本語化（J-Star）などを行ったゼロックスが提唱し、マイクロソフト、Apple、IBM、サン・マイクロシステムズ、ヒ
波ダッシュ（なみダッシュ、wave dash[注釈 1]）とは、日本語表記における約物のひとつで、波線「」（はせん、なみせん）を指している。ダッシュ記号（—）の波形であることからそう呼ばれる[注釈 2]。 日本語における用法の多くは範囲を示すenダッシュ記号としての用法と長音符としての用法がある。範囲を示す場合、「から」という日本語の約物であり、純然たる日本語である。日本以外ではこのように使用されることはない。なお中国語でもenダッシュの代用又は長音符などとして使われることがある。 Windows XP等における日本語環境下では、表示字形が「」ではなく、波形の反転した「」に変わってしまう問題が発生していた[注釈 3]。これに付随して、波ダッシュの代用として音声記号等として用いられる全角チルダが不適切に使われることがあるため、混乱の元となっている[1][注釈 4]。 日本語において範囲を表す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く