RSA密钥之C#格式与Java格式转换

前言 最近由于项目需求,服务端由c#编写,客户端由java编写。通信数据使用RSA非对称加密。但是java和c#生成的密钥格式是不一样的,所以需要转换格式才可以正常使用。网上搜到使用java进行格式转换的代码(如:http://blog.csdn.net/road2010/article/details/40071881 ),本文将给出一种c#的实现方法。 密钥格式 java密钥格式如下: 私钥: MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBAKSZSSEdPhv77O5ocnLNGXeQ21qJDArC1+yId+9/pY5bXkZk5vCB49EpfMwNukLv6AJqofThZPNOs1t015fdEYIUnkIc2QVxRwa0xTeFP6N8D4WQXRWs4fNG27JK5kP45s+9KlJtx5hs7G97aMczehIWpHaO6j9inOmjlU8l62KZAgMBAAECgYEAmK3TRtMwRJb33OGnn9OeFumYfy92qxi3X6Hq1o6qDBW2qkd4bImfv+ni6AinyOVuaadt2Y+lq4dKGcCVJzoZvPm1VKxD2y7xKa8/vEbPRiRTt0qnPq9T7UJkpDsiXf/zOMfWdjc3uA1bPnQ65RWHSJ7zAE+Gd7xnyCE5MEyijLECQQDVYqQWDqOVLZ5lJUuIfUIrhv26GvuoTX8v60+opCz4/Mdfh6JlefICVD6SAaYvufXBHVFY26JicNlR62ZOiBoNAkEAxXhsuEnNJNQcQHEVTPZoulbMbTV1VZIDQ1zjG8fvu8sv6IBYcR5+EsC8n3/6RkW8/iCJDzxE++VHzhoSQSoDvQJBAM6/63J/rpndAIrJ7vyJOPLJsc9/U3SH2gMJAT7KC9UXvuldlsixtf3xuEpplKbLjEUXbfklnZm586a+6XqPvoUCQDFotltOLARBBmihYuEE7qNhQHk63QbyJ9rdDP5Qgo2Mg4o7QuXa6VSr4QZPsUGQBX/YiDLFs8ULU3IgV9zyNEkCQADAYR8DctYzg0eBGdcOrDA5Szc62pYrS2wk89wUxyL4FyDL3omkVMKvtu5tccy7Xht2ikJZRqefZ3dS7ASm8/4= 公钥: MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCkmUkhHT4b++zuaHJyzRl3kNtaiQwKwtfsiHfvf6WOW15GZObwgePRKXzMDbpC7+gCaqH04WTzTrNbdNeX3RGCFJ5CHNkFcUcGtMU3hT+jfA+FkF0VrOHzRtuySuZD+ObPvSpSbceYbOxve2jHM3oSFqR2juo/Ypzpo5VPJetimQIDAQAB   .NET密钥格式如下: 私钥:

公钥:

  转换实现代码(c#) 格式转换要用到一个开源加密库Bouncy Castle Crypto APIs,官网地址: http://www.bouncycastle.org/csharp/ 具体实现代码如下:

  from:https://www.cnblogs.com/datous/p/RSAKeyConvert.html

龙生   16 May 2019
View Details

Rsa加解密Java、C#、php通用代码 密钥转换工具

之前发了一篇"TripleDes的加解密Java、C#、php通用代码",后面又有项目用到了Rsa加解密,还是在不同系统之间进行交互,Rsa在不同语言的密钥格式不一样,所以过程中主要还是密钥转换问题,为方便密钥转换,写了一个XML和PEM格式的密钥转换工具,文章后面会提供密钥转换工具的下载地址,通过搜索参考和研究终于搞定了在Java、C#和Php都可以通用的加解密代码,整理了Rsa的加解密代码做个记录,以后可以参考,大家应该都知道Rsa算法,这里就不说明了,直接看代码(代码主要是公钥加密私钥解密,密文统一进行base64编码,密钥长度为2048): Java版本:

  C#版本:

  PHP版本:

Rsa加解密C#和Java、php使用的密钥格式不一样,这里提供一个密钥转换工具:Rsa密钥转换工具v2.0   参考 https://www.cnblogs.com/jaamy/p/6118814.html

龙生   16 May 2019
View Details

接口与抽象类的区别

一个类可以实现多个接口,但却只能继承最多一个抽象类。 抽象类可以包含具体的方法;接口的所有方法都是抽象的。 抽象类可以声明和使用字段;接口则不能,但可以创建静态的final常量。 抽象类中的方法可以是public、protected、private或者默认的pagckage;接口的方法都是public。 抽象类可以定义构造函数;接口不能。

龙生   10 May 2019
View Details

CSS3 @media 查询

定义和使用 使用 @media 查询,你可以针对不同的媒体类型定义不同的样式。 @media 可以针对不同的屏幕尺寸设置不同的样式,特别是如果你需要设置设计响应式的页面,@media 是非常有用的。 当你重置浏览器大小的过程中,页面也会根据浏览器的宽度和高度重新渲染页面。 浏览器支持 表格中的数字表示支持 @media 规则的第一个浏览器的版本号。 Rule Chrome IE FireFox Safari Opera @media 21 9 3.5 4.0 9 CSS 语法 @media mediatype and|not|only (media feature) { CSS-Code; } 你也可以针对不同的媒体使用不同 stylesheets : <link rel="stylesheet" media="mediatype and|not|only (media feature)" href="mystylesheet.css"> 媒体类型 值 描述 all 用于所有设备 aural 已废弃。用于语音和声音合成器 braille 已废弃。 应用于盲文触摸式反馈设备 embossed 已废弃。 用于打印的盲人印刷设备 handheld 已废弃。 用于掌上设备或更小的装置,如PDA和小型电话 print 用于打印机和打印预览 projection 已废弃。 用于投影设备 screen 用于电脑屏幕,平板电脑,智能手机等。 speech 应用于屏幕阅读器等发声设备 tty 已废弃。 用于固定的字符网格,如电报、终端设备和对字符有限制的便携设备 tv 已废弃。 用于电视和网络电视 媒体功能 值 描述 aspect-ratio 定义输出设备中的页面可见区域宽度与高度的比率 color 定义输出设备每一组彩色原件的个数。如果不是彩色设备,则值等于0 color-index 定义在输出设备的彩色查询表中的条目数。如果没有使用彩色查询表,则值等于0 device-aspect-ratio 定义输出设备的屏幕可见宽度与高度的比率。 device-height 定义输出设备的屏幕可见高度。 device-width 定义输出设备的屏幕可见宽度。 grid 用来查询输出设备是否使用栅格或点阵。 height 定义输出设备中的页面可见区域高度。 […]

龙生   10 May 2019
View Details

html禁止手机页面放大缩小

<meta name="viewport" content="width=device-width,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no" /> html手机页面 <meta name="viewport" content="width=device-width, initial-scale=1" /> js正则: /<ul.*(?=breadline)(.|\n)*?<\/ul>/gi; 匹配以ul开始 class="breadline"结束外加中间任意内容</ul> ——————— 作者:huang100qi 来源:CSDN 原文:https://blog.csdn.net/huang100qi/article/details/36186573 版权声明:本文为博主原创文章,转载请附上博文链接!

龙生   08 May 2019
View Details

谈谈微服务中的 API 网关(API Gateway)

前言 又是很久没写博客了,最近一段时间换了新工作,比较忙,所以没有抽出来太多的时间写给关注我的粉丝写一些干货了,就有人问我怎么最近没有更新博客了,在这里给大家抱歉。 那么,在本篇文章中,我们就一起来探讨一下 API 网关在整个微服务分布式架构中的一个作用。 背景 我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中,举个例子。 在一个电商系统中,查看一个商品详情页,这个商品详情页包含商品的标题,价格,库存,评论等,这些数据对于后端来说可能是位于不同的微服务系统之中,可能我后台的系统是这样来拆分我的服务的: 产品服务 – 负责提供商品的标题,描述,规格等。 价格服务 – 负责对产品进行定价,价格策略计算,促销价等。 库存服务 – 负责产品库存。 评价服务 – 负责用户对商品的评论,回复等。 现在,商品详情页需要从这些微服务中拉取相应的信息,问题来了? 问题 由于我们使用的服务系统架构,所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果,那么如何才能访问各个服务呢? 按照微服务设计的指导原则,我们的微服务可能存在下面的问题: 服务使用了多种协议,因为不同的协议有不同的应场景用,比如可能同时使用 HTTP, AMQP, gRPC 等。 服务的划分可能随着时间而变化。 服务的实例或者Host+端口可能会动态的变化。 那么,对于前端的UI需求也可能会有以下几种: 粗粒度的API,而微服务通常提供的细粒度的API,对于UI来说如果要调用细粒度的api可能需要调用很多次,这是个不小的问题。 不同的客户端设备可能需要不同的数据。Web,H5,APP 不同设备的网络性能,对于多个api来说,这个访问需要转移的服务端会快得多 以上,就是我们构建微服务的过程中可能会遇到的问题。那么如何解决呢? 这种情况下,我们就需要一个今天要讲的这个东西, API 网关(API Gataway)。 API 网关 下面是百度上针对于 API 网关的介绍: API网关是一个服务器,是系统的唯一入口。从面向对象设计的角度看,它与外观模式类似。API网关封装了系统内部架构,为每个客户端提供一个定制的API。它可能还具有其它职责,如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。 API网关方式的核心要点是,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理所有的非业务功能。通常,网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。 Chris Richardson 在他的博客中把 API 网关划分为以下两种: 单节点 API 网关 Backends for frontends 网关 单节点网关 单节点的 API网关为每个客户端提供不同的API,而不是提供一种万能风格的API。 这个网关和微软在 eShop 项目中推荐的网关是一致的。 更多详细信息我会在下文进行说明。 Backends for frontends 网关 这种模式是针对不同的客户端来实现一个不同的API网关。 落地方案 我一直在寻思一种最佳的 API 网关的落地方案,以上两种 API 网关有什么问题呢? 通常情况下, […]

龙生   07 May 2019
View Details

念佛、念经正确的回向方法

不论念经念佛,念完后都要念一遍“回向偈”或“回向文”。即使做完一件善事也要念“回向偈”或“回向文”。要回向到西方极乐世界去。回向的功德越多,往生的希望就越大。“回向偈”和“回向文”有很多,可任选适合自己的一个即可。(每句字数相等叫“回向偈”,句子长短不一,叫“回向文”。)第一个最常见,其目的是求生西方极乐净土。 另外补充说明一点:如若以诵经念佛来超度自己的冤亲债主时,应该用“传地藏法门(见下面说明)”的专用回向文。(超度幽冥界众生时最好诵读《地藏经》,可以起到很好的开示作用,净空法师在有关超度问答中已经提及:幽冥界众生最喜欢听的就是《地藏经》。对于法界众生、仙众等冤亲债主也可以诵《金刚经》。) 若向佛菩萨许愿,例如求自己父母身体健康,疾病早日痊愈等愿时,也无需再用上面的回向偈,只要酌情向佛菩萨陈述,表达清楚用意即可。例如:“愿将此诵经(念佛)的功德回向给我的母亲,愿她能早日康复,不再受疾病之苦……”,并没有固定的行文,只要诚心,无论你怎么说,怎么回向,佛菩萨都会感应的。 回向文 愿以此功德,庄严佛净土。 上报四重恩,下济三途苦。 若有见闻者,悉发菩提心。 尽此一报身,同生极乐国。 愿以此功德 庄严佛净土 愿将一切善功德,回向庄严佛净土。真正的庄严,是在念佛时以至诚恳切的心,无一丝妄念,念到一心不乱,此时心即是佛,佛即是心。修行最重要是修心,将过去一切妄念渐渐收摄起来,变成与佛相同,心如此庄严才是真正的庄严,将此心的庄严回向阿弥陀佛的极乐世界,此即「回事向理」。 上报四重恩 下济三途苦 这二句属「回自向他」,他指四重恩、父母恩、众生恩、政治领袖恩及三宝恩。又将一切功德回向三恶道的众生:畜生、饿鬼、地狱,使他们能速速远离痛苦。 若有见闻者 悉发菩提心 这二句属「回小向大」,是指如有亲耳听闻的一切众生,全数都发出菩提心,上求下化,最后成就佛道。 尽此一报身 同生极乐国 希望尽此世的业报身后,与其他九法界的众生,同生西方极乐世界,这是「回因向果」。 十方三世一切佛 一切菩萨摩诃萨 摩诃般若波罗蜜 这是末了结归皈敬三宝,三句分别为佛宝、僧宝与法宝。须知,一切佛家的法事,皆因三宝加持力而得成就;例如受戒时,即在皈依三宝的羯磨中得戒,可见其重要性。有些人不懂这个道理,为了标新立异,故意将这三句省略,那是不大好的。以上简单介绍回向文的意义,希望大家都能以至诚恳切的心念回向文,期能真正得到回向的利益。 回向文汇集 回向偈一 愿以此功德。庄严佛净土。 上报四重恩。下济三途苦。 若有见闻者。悉发菩提心。 尽此一报身。同生极乐国。 回向偈二 愿生西方净土中,九品莲花为父母。 花开见佛悟无生,不退菩萨为伴侣。 回向偈三 大慈菩萨回向偈 十方三世佛,阿弥陀第一; 九品度众生,威德无穷极。 我今大皈依,忏悔三业罪; 凡有诸福善,至心用回向。 愿同念佛人,感应随时现; 临终西方境,分明在目前。 见闻皆精进,同生极乐国; 见佛了生死,如佛度一切。 无边烦恼断,无量法门修; 誓愿度众生,总愿成佛道。 虚空有尽,我愿无穷。 虚空有尽,我愿无穷。 回向偈四 普贤菩萨发愿偈 愿我临欲命终时,尽除一切诸障碍, 面见彼佛阿弥陀,即得往生安乐刹。 回向偈五 文殊菩萨发愿偈 愿我命终时,尽除诸障碍, 面见阿弥陀,往生安乐刹。 回向偈六 愿以此功德。庄严佛净土。 上报四重恩。下济三途苦。 普愿尽法界。沉溺诸有情。 若有见闻者。悉发菩提心。 尽此一报身。同生极乐国。 愿消三障诸烦恼,愿得智慧真明了, 普愿罪障悉消除,世世常行菩萨道。 回向偈七 愿以此功德,普及于一切。 我等与众生,皆共成佛道。 回向偈八 世界和平,人民安乐。 正法久住,法轮常转。 灾障消灭,祸患不生。 法界有情,同生极乐。 回向偈九 我今称念阿弥陀,真实功德佛名号, 唯愿慈悲哀摄受,证知忏悔及所愿。 我昔所造诸恶业,皆由无始贪瞋痴, 从身语意之所生,一切我今皆忏悔。 愿我临欲命终时,尽除一切诸障碍, 面见我佛阿弥陀,即得往生安乐刹。 我既往生彼国已,现前成就此大愿, 普愿沉溺诸众生,速往无量光佛刹。 回向偈十 西方发愿文 稽首西方安乐国,接引众生大导师。 我今发愿愿往生,唯愿慈悲哀摄受。 回向文十一 佛光注照。本命元辰。灾星退度福星临。 九曜保长生。运限和平。福寿永康宁。 传地藏法门 […]

龙生   06 May 2019
View Details

upstream timed out

报错信息:

  解决办法: server { listen       80; server_name  *.xywy.com ;         large_client_header_buffers 4 16k; #客户请求头缓冲大小 nginx默认会用client_header_buffer_size这个buffer来读取header值,如果header过大,它会使用large_client_header_buffers来读取如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request求行如果超过buffer,就会报HTTP 414错误(URI Too Long)nginx接受最长的HTTP头部大小必须比其中一个buffer大,否则就会报400的HTTP错误(Bad Request)。         client_max_body_size 300m; #指令指定允许客户端连接的最大请求实体大小,它出现在请求头部的Content-Length字段. 如果请求大于指定的值,客户端将收到一个"Request Entity Too Large" (413)错误. 记住,浏览器并不知道怎样显示这个错误.         client_body_buffer_size 128k; 这个指令可以指定连接请求实体的缓冲区大小。 如果连接请求超过缓存区指定的值,那么这些请求实体的整体或部分将尝试写入一个临时文件。 默认值为两个内存分页大小值,根据平台的不同,可能是8k或16k。 当请求头中的Content-Length字段小于指定的buffer size,那么Nginx将使用较小的一个,所以nginx并不总是为每一个请求分配这个buffer size大小的buffer。         proxy_connect_timeout 600; 说明 该指令设置与upstream server的连接超时时间,有必要记住,这个超时不能超过75秒。 这个不是等待后端返回页面的时间,那是由proxy_read_timeout声明的。如果你的upstream服务器起来了,但是hanging住了(例如,没有足够的线程处理请求,所以把你的请求放到请求池里稍后处理),那么这个声明是没有用的,由于与upstream服务器的连接已经建立了。         proxy_read_timeout 600; 说明 该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间,而是两次reading操作的时间。         proxy_send_timeout 600; 说明 这个指定设置了发送请求给upstream服务器的超时时间。超时设置不是为了整个发送期间,而是在两次write操作期间。如果超时后,upstream没有收到新的数据,nginx会关闭连接         proxy_buffer_size 64k; 该指令设置缓冲区大小,从代理后端服务器取得的第一部分的响应内容,会放到这里. 小的响应header通常位于这部分响应内容里边. 默认来说,该缓冲区大小等于指令 proxy_buffers所设置的;但是,你可以把它设置得更小.         proxy_buffers   4 32k; 该指令设置缓冲区的大小和数量,从被代理的后端服务器取得的响应内容,会放置到这里.         proxy_busy_buffers_size 64k; 默认值: proxy_busy_buffers_size proxy_buffer_size * 2; 上下文: http, server, location, if TODO: Description. buffer工作原理 首先第一个概念是所有的这些proxy buffer参数是作用到每一个请求的。每一个请求会安按照参数的配置获得自己的buffer。proxy buffer不是global而是per request的。 proxy_buffering 是为了开启response buffering of the proxied […]

龙生   05 May 2019
View Details

springboot测试的时候status(),content()方法报错

  是因为静态导入的原因,只要导入:

然后就OK了。   from:https://blog.csdn.net/qq_21549989/article/details/78873229

龙生   30 Apr 2019
View Details
1 150 151 152 432