WEBのコーディングでよく使いそうな、html特殊文字の数値参照(10進数、16進数)と文字参照をまとめました。 フォントに依存する部分があるため、指定のフォントによっては見た目が違ったり出ない場合がありますのでご注意ください。 文字参照についてはW3Cの仕様書(こちら)を参考に作成しました。
実装方法には3種類(および代用表記)がある。 各々の囲み文字に、通常の文字と同様に専用の符号点を割り当てる。 囲まれる文字と書式情報で、1つの囲み文字を表す。 囲まれる文字と合成用文字の2文字で、1つの囲み文字を表す。 丸囲み文字は丸括弧、四角囲み文字は角括弧で囲って表記する(例: (A)・[A])。 通常の文字のように符号点が割り当てられれば、アプリケーションレベルでの対応は必要なく、フォントにさえ入っていれば表示することができる。 1バイトコードでは、7ビットコードの ISO/IEC 646 には囲み文字はなかったが、欧文用8ビットコードの ISO/IEC 8859-1 (Latin-1) では©と®(マルCとマルR)が採用された。 日本語の2バイト文字コード規格である JIS X 0208 には囲み文字はない。一方で、実際に使用する用途は多いため、各メーカでは独自の拡張を行い外字とし
出雲大社までヒッチハイク旅したら自己発見できた[出雲大社ヒッチハイク体験記/前編] ふとした思いつきから内省と思索の旅へ。神奈川から出雲大社までのヒッチハイクで、予期せぬ自己発見を経験した4泊5日の記録。 はじめに - 旅の動機 - 10年友達関係が続いて、昨年頭から1年間付き合った恋人と年末に別れた。 失恋の詳細はどうでもいいので省く。付き合…
使用しているWinMergeのバージョンによってはUTF-8のファイルを比較する場合は基本的にS-JISで表示するため、日本語の箇所が文字化けして表示される場合があります。 そういう場合はデフォルトの文字コードを変更する事で解消する事が出来ます。 環境 WinMerge Version 2.14.0.37+-jp-37 文字コードの設定手順 今回はデフォルトコードページをUTF-8に変更する手順をご紹介します。 メニューから「編集」⇒「設定」を選択します。 オプション画面で「コードページ」を選択し、デフォルトコードページで「カスタムコードページ」を選択し、「65001 – Unicode(UTF-8)」を選択して「OK」ボタンを選択します。 補足 上記で指定した「65001」というのは文字コード番号を表します。 一般的に使用されるコードは以下の通りです。 文字コード番号文字コード
技術ドキュメント目次 -> UNIX の C言語 -> iconv()で文字コード変換 本技術ドキュメントは、2002~2004年頃に作成したものが多いです。 内容が古くなっていることもあるかと思いますが、ご了承ください。 【低価格SSL証明書】弊社運営の低価格SSL証明書販売サイト、翌月末払いなど請求書払いも可能。 ◆ iconv()で文字コード変換 iconv() 関数を用いるとことで、 UNIXのC言語のプログラム内から文字コードの変換を行うことができます。 ◆ iconv()サンプルプログラム 文字列をEUCからSJISに変換する簡単なサンプルを次に記載しますので、 よろしければ参考にされてください。 ※RedHat Linux 7.3 と FreeBSD 5.3 でコンパイルが通ることを確認しました。 ただし、FreeBSD ではデフォルトで iconv が入っていないことも多い
Git for WindowsがUTF-8に対応したおかげで、ほとんど日本語ということを意識せずに使うことができるようになりました。 ただ、まだまだShift-JISのファイルを扱うことも多く、現在のGit for Windowsではgit diffが文字化けしてしまっていました。 この現象を解消するためには、次のような手順が必要です。 nkf.exe nkf32.dll Windows用の詳細情報 : Vector ソフトを探す!などからnkf.exeをダウンロードする。 nkf.exeを~/bin(%UserProfile%\bin)など、Git Bash起動時にパスが通った場所にコピーする。 git diffを|(パイプ)でnkfに流す。 nkfには-sオプションでShift-JISを指定する。 生のgit diffと違って色分けはされませんが、正しく日本語が表示されることがわかりま
androidアプリ開発時に、volleyを使ってjson形式のapiを取得する処理を書いていたのですが、jsonに日本語が入っていると文字化けする現象に遭遇しました。 調べてみるとapiのレスポンスヘッダーにContent-Typeが正しく指定されていない模様。 自前で用意したapiだったのでnginxの設定を変えて、正しくContent-Typeを指定するように修正したところ、文字化けが直りました。 /etc/nginx/mime.types にjsonを追加# sudo vi /etc/nginx/mime.types types { text/html html htm shtml; # ・・・・ application/json json; }jsonの文字コードがutf-8になるように指定server { listen 80; # ・・・・ include /etc/nginx
Home Subscribe UTF-8? utf-8? UTF8? utf8? 気になったので調べてみました。 結論 公式名称は "UTF-8" である。 UTF-8, a transformation format of ISO 10646 大文字小文字は区別されない。 UTF-8でもutf-8でもどちらでもいいようです。 " HTTP character sets are identified by case-insensitive tokens. " Hypertext Transfer Protocol -- HTTP/1.1 したがって、 Shift_JIS/shift_jis EUC-JP/euc-jp どちらでもOKということになります。 気になるあのサイトでは? 世の中的にはこうなっていました。(2011/8/17現在)
先に結論 CP932 は、Shift_JIS の独自実装 符号化文字集合がいろいろ拡張されている 拡張文字の有無で、Shift_JIS と判別可能 CP932ってなあに? 実はいろいろある Microsoftコードページ932 IBMコードページ932 PC-9800仕様OEMコードページ932 Windows-31J(MS932) Microsoftコードページ932 Microsoftが、MS-DOS 用に作った Shift_JIS の実装 IBMコードページ932PC-9800仕様OEMコードページ932 IBM、NECが作った、Microsoftコードページ932 の拡張 Windows-31J(MS932) Microsoftが互換性確保の為に、IBM、NECの拡張を吸収した、Windows 用の CP932 CP932 といったらほぼほぼこれを指す MS932 は、Java で
※本記事はアフィリエイトプログラムによる収益を得ています Android端末で、「ハンバーガー」の絵文字のチーズの位置がおかしい重大な問題が発覚しました。この問題は全米のネット上を駆け巡り、ついにはGoogleのCEO(最高経営責任者)であるスンダー・ピチャイ(Sundar Pichai)さんが「最優先で修正する」と明言するほどの事態に発展しています。さすがは本場米国、ハンバーガーに対して妥協がありません。 この問題を提起したのは、アナリストのトーマス・ベイクダル(Thomas Baekdal)さん。自身のTwitterで、「Googleのハンバーガーの絵文字でチーズが下になっている件について議論をしたほうが良いと思う」とツイートしました。 件の絵文字を見てみると上からバンズ、レタス、トマト、パティ、チーズ、そして下のバンズの順になっています。これは確かにおかしい。チーズはもっとこう、肉の
Linux/UNIXで、指定したファイルの文字コード(UTF-8とか、EUC-JPとか)を調べる場合は、以下のような方法がある。 1.fileコマンドで調べる UTF-8か、EUC-JPなのか、それともShift_JISなのか… 日本語のファイルだとはわかっていて、その違いを調べるだけであれば、fileコマンドで事足りる。 以下のように、「-i」オプションを付与してfileコマンドを実行することで、文字コードを調べることができる(Shift_JISのみ、「unknown-8bit」として出力される)。 file -i ファイルPATH blacknon@BS-PUB-UBUNTU-01:~$ file -i /tmp/ascii.txt /tmp/ascii.txt: text/plain; charset=us-ascii blacknon@BS-PUB-UBUNTU-01:~$ fil
A classic, five-point gold star. Commonly used for various metaphorical senses of star (e.g., for fame, success, excellence, reviews). Also used for emphasis or flair. Occasionally used for astronomical stars. Not to be confused with 💫 Dizzy, 🌟 Glowing Star, 🌠 Shooting Star, or ✨ Sparkles, though their applications may overlap. Samsung and Facebook’s stars were once silver. See the glossary for
Section: Linux User Manual (1) Updated: 2020-06-09 Index JM Home Page roff page 名前 iconv - テキストをある文字符号化から別の文字符号化に変換する 書式 iconv [options] [-f from-encoding] [-t to-encoding] [inputfile]... 説明 iconv プログラムはある符号化 (encoding) からテキストを読み出し、 別の符号化でそのテキストを出力する。 入力が指定されなかった場合、 もしくは入力ファイルとしてダッシュ (-) が指定された場合、 iconv は標準入力から入力を行う。 出力が指定されなかった場合、 iconv は標準出力に出力する。 from-encoding が指定されなかった場合、 デフォルトは現在のロケールの文字符号化から
指定暴力団神戸山口組(本拠地・兵庫県淡路市)から4月に離脱を表明した「任●(にんきょう)団体山口組」が9日付で組織名を変更するとの通達を関係者らに流していたことが分かった。新名称を「任侠(きょう)山口組」とし、理由については、この呼び名が短期間で広く世間に浸透したため、などとしている。 【動画】新組織は「任●団体山口組」 神戸山口組から離脱 関係者らによると、通達はメールなどでまかれたといい、同組が「暴力団ではなく任侠団体であるという趣旨を発信するという第一段階の目的は達した」ことを機に改名したとの内容が記されているという。 「任●」の表記も「任侠」へと変更。捜査関係者らによると、同組側は4月30日の結成会見で旧字体の「●」へのこだわりを表明したが、一部のインターネット配信記事などで正しく表記されなかったり、「『侠』の右が『夾』」と注釈が付いたりすることなどへの不満を示していたという。
ISO/IEC 8859-15:1999 は、ISO/IEC 8859 の第15部である。ISO/IEC 8859-1と同様、西ヨーロッパ諸言語のためのラテンアルファベットの文字コードの標準である。1999年に初版が制定された。公式の名称ではないが、Latin-9 と呼ばれることがある。 ISO/IEC 8859-15 は ISO/IEC 8859-1 に似ているが、ユーロ記号、および 8859-1 の対象言語で使用される文字のうち 8859-1 で定義されていなかった文字を追加し、かわりに一部の記号を除いている。もともと 8859-1 を置きかえるものとして作られたが、あまり普及はしていない。 概要[編集] 8859-1 と 8859-15 は、以下の8か所が異なっている。 符号位置 A4(16進) A6(16進) A8(16進) B4(16進) B8(16進) BC(16進) BD(1
GNU Project下で開発が進められているコンソール向けテキストエディタ「Moe Editor」プロジェクトは6月28日、最新版となる「GNU Moe 1.9」を公開した。 Moeは「My Own Editor(MOE)」の略で、ISO-8859およびASCII文字コードという「8ビット文字コード」向けのコンソールテキストエディタ。モードレス、使いやすいユーザーインターフェイス、オンラインヘルプ、複数のウィンドウ表示、無制限のundo/redoや無制限のファイルサイズ/バッファ、グローバル検索/置換、自動インデントといった機能を備える。 UTF-8と比較して8ビット文字コードの方が日常のコンピューティングやコミュニケーション作業には適しているという見解から、UTF-8ではなくISO-8859-15をサポートするとしている。8ビット文字セットは、安全性と効率性に優れるとも記している。 G
シフトJISの1バイトコード(半角文字)のエリア 0x00~0x1f、0x7f は制御コードです 0x20~0x7e はASCII文字です 0xa1~0xdf は半角カタカナです シフトJISの2バイトコード(全角文字)のエリア(JIS X 0208の漢字エリア) 上位1バイト 0x81~0x9f、 0xe0~0xef 下位1バイト 0x40~0x7e、 0x80~0xfc ですが機種に依存しない観点より、HTMLで以下の水色エリアは使用しないのが無難です 水色エリアはJIS X 0208 (1990) to Unicode 漢字コード表に存在しないコードです 0x8540~ 0x889e は機種依存文字の主なエリアです 0xeb40~ 0xeffc はMacOS では縦書用文字、Windows では特殊な外字エリアです 0xf040~ は外字エリアです(記載していません) perlで
a-blogというブログ作成パッケージを使って、 友人のブログを構築している時のこと。 カスタマイズするモジュールがいくつか公開されていて、 そのモジュールを処理していると思われるときに、 不正な文字があるというメッセージが表示される。 a-blogの他の部分のソースは非公開なので、 (どこかに出力されているかもしれない)ログをたよりにプログラムを追いかける という外科的な診断はできない。 カスタマイズの状況をかえながら、発生する現象を観察する という内科的な方法を試みた。 カスタマイズ用のモジュールの文字化けが原因とのベンダからのアドバイスをうけて、 そのモジュールを Java 5.0 で読み込みコンソールに表示してみた。 エディタ(秀丸エディタ 4.14)では普通に表示されている全角マイナスが、 コンソールには、? と表示されているではないか。 そういえば、 Unicode と コード
Lotus Domino サーバーを R5 から Lotus Domino 6.x 以降にアップグレード後、以下の EBCDIC の文字が正しく変換されません(カッコ内はMS932(Shift-JIS)での文字コードです)。 (0x817C) (0x8160) (0x8161) (0x815C) (0xFA55) これは IBM i / z プラットフォーム等で使用されているデータを Windows プラットフォーム上のクライアントやサーバーに転送したり、アプリケーションで処理する部分や Lotus Notes クライアントでこれらの文字コードを表示する際などに発生します。 この問題は、問題報告番号 HNAA6JW7SJ / YSAI6Z4BGQ として Lotus Quality Engineering に報告され、Lotus Domino 8.5.2 で修正されています。 Lotus
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く